…errors." This reverts commit 76975ae.
…g_complete into builtin-dirs
…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.
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.