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.
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.
Use *LD_LIBRARY_PATH when configured to build against the systems libclang.
This patch makes the install script work even when libclang is in a custom path.
Signed-off-by: Ola Jeppsson <ola.jeppsson@gmail.com>
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.
We now use the compilation working directory for a file that is specified in the
CompilationDatabase. We don't actually change the working directory of the
process, even temporarily (that would be annoying to users); we munge the flags
coming from the database so that all the relative paths in them are resolved to
absolute ones.
