ycmd would sometimes crash on startup with a coredump and a message from glibc
on how free() was called for an invalid pointer. A gdb session pointed out that
the problem was with static initialization order.
This means we can now load just ycm_client_support (which is a much smaller
library) into Vim and ycm_core into ycmd. Since ycm_client_support never depends
on libclang.so, we never have to load that into Vim which makes things much,
much easier.
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).
"Dev" flags are -Werror, -Wextra, -Wall and -Wc++98-compat. People who are
compiling YCM as users and not developers (99.99999% of all YCM compilations)
don't care about those flags and were just burdened by their inclusion by
default.
Fixes#502.
Previously, "Foo" would match "Foo" but not "FOO". Now it matches both. Bottom
line, an uppercase char matches only uppercase chars but lowercase chars can
match either. We used to insist that lowercase chars in the query match
lowercase chars in the candidate strings IF the query also had uppercase
letters; this was dumb and a poor user experience.
Fixes#501.
- compile both libs with /UNICODE and /MP
- moved shared flags & defines to root CMakeLists.txt
- fixed resolving EXTERNAL_LIBCLANG_PATH on Windows
- postbuild copy of libclang.dll
- change PATH_TO_LLVM_ROOT & EXTERNAL_LIBCLANG_PATH to PATH variables instead of BOOL options (for cmake-gui)
Everything that needs access to filetype_map_ has been split into a new class
called IdentifierDatabase. This class is thread-safe. Previously, multiple
threads could access filetype_map_ at the same time, some reading things from
it, others writing to it. WTF was I doing? My best guess is that I introduced
this vile stupidity when I added the second thread to IdentifierCompleter;
previously it was impossible for multiple threads to stomp on filetype_map_
because only one thread ever accessed it. I changed that some time ago and
forgot to protect filetype_map_.
Idiot.
