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.
ycm_extra_conf.py files used to import clang_helpers and then use the
PrepareClangFlags function; this is now unnecessary since the logic from that
function has been moved to flags.py. The old PrepareClangFlags function is still
there (it just returns the flags it gets) for the sake of backwards
compatibility with old ycm_extra_conf.py files.
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
GetWordBoundaryChars would return "allcaps" for "ALL_CAPS" instead of "ac". This
would manifest as ranking (for instance) "STDIN_FILENO" ahead of "stdin" for
query "std", which is terrible.
This bug has been present in YCM for many months, but no one noticed the issue.
Fixes#272.
It was never supposed to be licensed under the GPL since it's effectively
example code (that's also used for YCM compilation flags, but still).
No one has ever edited this file except me, Strahinja Val Markovic, and thus I
can release it into the public domain.
Previously it returned an empty list. It makes mores sense to return the input
list of candidates because conceptually everything matches an empty query.
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.
We used to do this but it was unsafe, as issue #167 proves. YCM has to give
libclang an include to YCM's copy of clang system headers (again, see issue #167
for details) and those headers may not be valid for a newer libclang.
If the user really wants to user the system libclang, then he can just always
call cmake himself. The installation guide in the README goes to great lengths
to explain the simple process of building YCM "by hand".
Fixes#167.
Previously, a string like 'foo\'bar\'zoo' would make the collection process
think that "bar" is not inside a string because it wouldn't recognize that the
quotes are escaped. Now it does.
Fixes#143.
