It would defeat the whole purpose of that branch…
Also, instead of counting the number of diagnostics to see if the builtin headers are found, return False only if an error was encountered.
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.
If libclang is installed in some non-default location, it sometimes fails to find the path to the builtin includes. This will cause an error when including these headers which again blocks precompiled header caching. Even though autocompletion often still works, it is annoyingly slow. We now check explicitly if the builtin includes are available. If they are not we try to find them ourselves. Only if this does not work, we warn the user and ask him to report a problem.
Instead of passing on the exception, we now provide a proper error message to the user and fall back to the clang executable.
Like this we can avoid special cases in the later code path
The clang and gcc autoloaders are not necessary any more to optain the system include paths. Due to the previous commit, the include paths are now correctly added by the clang driver. libclang always used internally the clang driver and never had problems finding the system include paths. We remove these options as incorrectly derived include paths can cause all kind of spurious problems. We now print the following message, if someone manually adds 'clang' or 'gcc' to the auto_user_options: 'gcc' in clang_auto_user_options is deprecated.
By using the clang driver all system include paths are automatically available and there is no need to recover in any way.
…plete into tobig Conflicts: plugin/libclang.py
…_complete into cdb