- 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)
For instance (`|` represents the cursor):
1. Buffer state: `foo.|bar`
2. A completion candidate of `zoobar` is shown and the user selects it.
3. Buffer state: `foo.zoobar|bar` instead of `foo.zoo|bar` which is what the
user wanted.
This commit resolves that issue.
It could be argued that the user actually wants the final buffer state to be
`foo.zoobar|` (the cursor at the end), but that would be much more difficult
to implement and is probably not worth doing.
Fixes#374.
By toggling the g:ycm_seed_identifiers_with_syntax option, the user can now tell
YCM to seed the identifier database with the language's keywords.
This is off by default because it can be noisy. Since the identifier completer
collects identifiers from buffers as the user visits them, the keywords that the
user cares about will already be in the database, regardless of the state of the
new option. So the only keywords added will be the ones the user is not using.
Meh. But people want it so there.
Fixes#142.
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.
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.
