…g_complete into builtin-dirs
simple fix for #264 after 3 hours of struggling..
…ound in the compilation database
…ile is not found This is a very common case : it happens for all headers. In practice, this heuristics gives good results.
If g:clang_use_library wasn't set in the .vimrc, the use of compilation database would generate an error.
This removes the .acquire() and .release(), and avoid potential lockups if the code wasn't guarded by try catch.
This is easier to read, and may be a bit faster.
The tabs slipped in accidentally. https://llvm.org/svn/llvm-project/cfe/trunk@172934
Most of the CompletionChunks represent braces, colons or other one character spellings. There is no need to call libclang, to figure out how to write a colon. Instead we use an internal cache to retrieve the correct spelling. As function calls from python are very expensive and this is a performance critical part of auto completion this patch makes formatting of auto completion results a lot faster. Formatting time changes from 0.57 to 0.45 seconds https://llvm.org/svn/llvm-project/cfe/trunk@172901
This is a very performance critical point for auto completion. The manual implementation gives a large speedup. As it does not complicate the code a lot, I figured it is worth the change. If anybody understands why the CachedProperty is here so much slower, I am very interested in working on an improvement of CachedProperty. Formatting time changes from 0.72 to 0.57 seconds. https://llvm.org/svn/llvm-project/cfe/trunk@172900
We can directly the number of the kind instead of going through the completionChunkKindMap. Formatting time changes from 0.84 to 0.72 seconds. https://llvm.org/svn/llvm-project/cfe/trunk@17289
…erenced). Patch by Matthew King! https://llvm.org/svn/llvm-project/cfe/trunk@171423
shadow the 'file' builtin, and fix up a docstring a little. Hat tip to Sebastian Kreft Carreno at Google for noticing the bug. https://llvm.org/svn/llvm-project/cfe/trunk@169887
While I cannot show any performance improvement, I'll argue that the complexity of retrieving a translation unit is now two times faster. The python "in" keyword has to walk to the datastructure once, and we walk a second time to retrieve it. We only walk it once now.
This save some ms: from 0.147s to 0.137s
If the user did not request anything specific, we first try to use libclang and only fall back to the clang executable if libclang could not be found. Error messages are only printed in debugging mode or if the user explicitly requested libclang. This patch allows us to use libclang.so as soon as it can be found in the system library path. No further configuration is required in .vimrc.