The code doesn't seems to be executed in background, but at exit time...
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.
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.
…plete into tobig Conflicts: plugin/libclang.py
…_complete into cdb
This reverts commit 53462d9. That was causing issues when snippets were disabled.
…on 2.6. Python 2.5 can be supported if we add the appropriate import from future.
Patch provided by Matthias Kleine <email@example.com> https://llvm.org/svn/llvm-project/cfe/trunk@167216
Patch by Leo Liu, test case by me. https://llvm.org/svn/llvm-project/cfe/trunk@165374
The issue is that we were calling clang_getCompletionBriefComment unconditionally. New we check if this function is available before calling it. https://llvm.org/svn/llvm-project/cfe/trunk@164464
libclang now allows to remove the compatibility check. This is done on our own risk and no upstream support is provided. My tests have shown that with this patch, we can provide code completion back to clang 2.8 and error highlighting at least back to 3.0.
At the moment, we implictly check compatibility between the python bindings and libclang, as the python bindings will fail to load in case a method we use in libclang is not available. This patch makes the use of this compatibility check explicit and introduces a flag to optionally disable the check. This will allow us to further harden the compatibility check, but it also gives the user the possibility to disable the compatibility check to evaluate compatibility with older libclang versions. I added documentation that makes clear the python bindings are only tested with the libclang version they have been shipped with https://llvm.org/svn/llvm-project/cfe/trunk@163238
By calling cindex.Config.set_library_path(path) or cindex.Config.set_library_file(file) it is possible to specify from where we load libclang. This fixes an open FIXME. We also point the user to these functions, in case libclang can not be loaded sucessfully. https://llvm.org/svn/llvm-project/cfe/trunk@163121 This merge removes the last difference between our python bindings and the official ones. There is no need any more to use sys.argv to secretly forward the library path.
The helper allows us to define how the initialization of functions should behave. We use this patch to provide an informative error message, in case a function is not available: "LibclangError: /home/grosser/Projekte/llvm/install/lib/libclang.so: undefined symbol: clang_method_added_in_2020. Please ensure that your python bindings are compatible with your libclang.so version." This patch also ensures that no spelling mistakes slip into the library initialization. At the moment, there are a couple of 'argtype' -> 'argtypes' mispellings that have been overlooked. https://llvm.org/svn/llvm-project/cfe/trunk@163057
Without this patch, lib.clang_getNumCompletionChunks is called at each _iteration_ of a 'for chunk in CompletionString' loop. Now we call it just once. https://llvm.org/svn/llvm-project/cfe/trunk@16220
Suggested by: Francisco Lopes <firstname.lastname@example.org> https://llvm.org/svn/llvm-project/cfe/trunk@162191
It isn't used anywhere yet. https://llvm.org/svn/llvm-project/cfe/trunk@162190
Reported by: Francisco Lopes <email@example.com> https://llvm.org/svn/llvm-project/cfe/trunk@162182