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.
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 is still fast & efficient because if we detect that the buffer hasn't been
changed (by examining b:changedtick), the parse doesn't proceed.
In effect, we now make sure we parse the file after every change to the buffer
as soon as that change happens. This means that compilation error feedback will
now be much, MUCH quicker.
Depending on the user, the PrepareClangFlags rewrite of a few commits ago could
break users with an extra "clang: 'linker' input not used" (or similar) error
message because the compiler executable string was not removed from flags
upstream if the user prepended some flags to the output of PrepareClangFlags
before returning it to the caller of FlagsForFile.
Since the rewrite was supposed to be backwards compatible, this needs
to be handled.
It was possible to get a traceback if results[ 'flags' ] was a StringVec; the
code would try to perform results[ 'flags' ] += self.special_clang_flags and
this would then fail because the clang flags would be a Python list.
