Now, every FileReadyToParse event returns diagnostics, if any. This is instead
of the previous system where the diagnostics were being fetched in a different
request (this caused race conditions).
There appear to be timing issues for the diag requests. Somehow, we're sending
out-of-date diagnostics and then not updating the UI when things change.
That needs to be fixed.
Reparse would take the clang lock and then possibly call Destroy while still
holding the lock. Destroy would try to take that same lock, and the mutex is not
recursive. Unpleasantness ensues.
I _think_ this is the root cause of #218, but I can't be sure. Such is life with
threads.
Fixes#218.
The issue was that the user could open a C-family file and have it start
compiling in the background. While it is still compiling, he could trigger the
completion system with a member dot operator. Because the file was still
compiling for the very first time, the TranslationUnit object was yet not
created. Sadly, this meant that UpdatingTranslationUnit would return false, and
a new query request would be created, the GUI would hang until it was done
aaaaand terrible lag until the file was compiled.
This was a very rare edge case that could also only be triggered if it takes a
considerable amount of time to compile the file.
One more thing needs to be done though: the clang_completer.py file needs to not
trigger at all when YCM has been compiled without cpp support. FIX THAT!
