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).
The server is multi-threaded and will spawn a new thread for each new request.
Thus, the completers need not manage their own threads or even provide async
APIs; we _want_ them to block because now were implementing the request-response
networking API.
The client gets the async API through the network (i.e., it can do something
else while the request is pending).
This fixes a Visual Studio problem when it cant correctly select
bind and make_shared boost methods due to Argument-dependent name lookup.
Relevant to #19
The answer was to use boost::move() on the functors, but since there is AFAIK no
move emulation support for Boost.Function, the fix may only work on C++11
compilers. That needs to be looked into.
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!
