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.
