Currently, when VIM opens a source file, YCM always defaults to
'g:global_ycm_extra_conf_file' if it exists.
This commit changes YCM's behaviour so that it first tries to find the config
file in the source file's folder (or any of its parents folder), before
falling back to 'g:global_ycm_extra_conf_file'.
Now there's a nice user-configurable setting for when YCM should trigger
semantic completion. This is very useful for the new omni_completer that uses
data coming from Vim's omnicomplete system.
Vim allows setting the filetype string to something like "cpp.c", which means
that the file is both cpp and c (nonsense, but allowed). We need to support such
filetype strings.
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.
We have to have these beneath the folder where ycm_core.so is placed so that we
get fast completions. If these files are not here, then clang fails to
precompile a file preamble and completions are slow.
This was intended to show the full clang output for a given diagnostic,
including notes. But it appears that libclang does not provide this
functionality...
If the user had code like "foo.bar" and then entered insert mode after the 'r'
in "bar", YCM would cause vim to hang.
The problem happened because a sorting task was created that would try to sort
on the latest clang result but none would be created because a clang task was
not created in this occasion. clang_data_ready_ would remain false and would
never be set to true, thus causing an infinite loop in SortingThreadMain since
the thread would forever wait on the mutex.
This was rectified with better handling of the clang results cache. Now the
cache is a full class and it also stores the line & column number of the
location for which the results were computed. Better logic is in place for the
cache invalidation.
The problem was caused by a race condition of all things. ClangCompleter would
set possibly_completions_ready when starting the first parse pass for the file
and then would try to extract diagnostics for the file before the diagnostics
were done. Technically this was not a problem because only an empty diagnostics
vector would be returned, but this triggered Syntastic because hey, we have some
diagnostics to show (even though we don't).
And then Syntastic would try to close the location list window during startup
when this operation is not available. Technically it's Syntastic's fault, but a
more principled way to check for done diagnostics is to return and use a future
for file parsing operations and this solution also works around the Syntastic
issue.
This change should fix the random hangs and segfaults when using the clang
completer. Also, assertion errors printed to the console on vim exit should go
away too, same thing with segfaults on vim exit. These "on exit" errors were
caused by not cleanly shutting down the background threads; both the identifier
completer and the clang one now join the threads on destruction. This results in
a clean shutdown.
The new clang completer architecture now uses only one clang thread (again)
instead of a completion and parsing thread. Since the parsing task needs to wait
on the completion task if it was started first (and vice-versa) there's no point
to using two threads. The desired "simplicity" of using two threads for these
two tasks actually created needless complexity (and bugs). Sigh. Such is life.
A TranslationUnit abstraction was also created and this in turn also reduces the
complexity of the clang completer.
The clang completer now also has some (very) basic tests.
The completion text in the menu is different. We used to just show the func name
in the "main" part of the completion menu, now we show the full signature
without the return type (which is shown on the right)
This should help catch cases where the user jumps to an identifier and then
edits it in place; we want to add that new ident to the db ASAP because the user
may want to have it completed soon.
Still, we're not perfect. If the user just deletes chars with 'x' or 'd' in Vim
and therefore never even enters insert mode we are obviously not going to pick
up that identifier until the next full file sweep.
Clang searches for these files and if it doesn't find them, completion is twice
as slow (or slower) than otherwise.
See this issue report for more details:
https://github.com/Rip-Rip/clang_complete/issues/17
We limit the number of candidates returned to Vim to 20 and also make sure that
we are not returning any duplicate candidates. This provides a noticeable
improvement in latency.
This makes the whole plugin much faster since we now don't need to serialize and
deserialize the return values from python funcs before we can use them in Vim.
Oh God I've been waiting for something like this for so long... using this also
forces us to demand vim 7.3.584 or higher.
First off, we don't block the GUI thread anymore for ClangCompleter (that was
always temporary). Secondly, now ClangCompleter will cache the data coming from
clang so that query-based filtering of members is fast.
This change was also the root cause of the crash bug I spent two days tracking
down. The problem was that the new bool member was not added to the custom copy
ctor... since we don't really need a custom copy ctor for Result, we're going
with the compiler-provided one.
This removes the need for a special overload for AddCandidatesToDatabase. Also,
the GetFuture function now provides a more sensible API with the list being
returned instead of accepted as an out parameter.
