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.
This provides a framework for completer-writers to create
completer-specific commands. I have in mind to use this for the clang
completer to force reloading of a flags module via `:YcmCompleter reload`.
To prevent the execution of malicious code the new default is
to ask the user before a `.ycm_extra_conf.py` file is loaded.
This can be disabled using the option `g:ycm_confirm_extra_conf`.
This commit introduces a helper class `FlagsModules` that keeps track of
and caches the currently loaded modules. To introduce further criteria
for a module look at `FlagsModules.ShouldLoad`.
Also `:YcmDebugInfo` now lists the file that was used to determine
the current set of flags.
`Flags.ModuleForFile` could be used in a user-facing command that
opens the `.ycm_extra_conf.py` corresponding to the current file.
A second command could then force a reloding of this module via
`Flags.ReloadModule`.
I'm pretty sure that allowing ycm_core.dll was wrong. Python docs state that the
extension for compiled Python modules on Widows is "pyd"; see this link for more
details: http://docs.python.org/2/faq/windows.html#is-a-pyd-file-the-same-as-a-dll
Key quote from the page:
"Of course, foo.pyd is required if you want to say import foo."
CMakeLists.txt has been previously updated to produce a ycm_core.pyd on Windows,
not a ycm_core.dll.
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.
