Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Clang CC

<< < (35/48) > >>

l_inc:
yvesdm3000
Hi. Did you have a look at the issue with header files parsed out of translation unit context? This issue results in literally every header file in my current main project being full of red diagnostics and no code completion works in the header files. I saw you had created an issue for that, just asking if you'll work on this in anytime soon.

yvesdm3000:
Hi l_inc,

Yes I briefly looked at that and tried enabling it again. The problem is that reparsing doesn't work correctly in that setup. This is because Clang caches all header files in a PCH (the preamble files in /tmp) and this obviously includes the header file we're modifying. Disabling this cache has a big impact on performance and I currently don't know (yet) how I should fix this. A quick fix might be that we disable this caching behaviour when we're working in a header file, but then again the performance degradation will still be there.

Yves

l_inc:
yvesdm3000

--- Quote ---Yes I briefly looked at that and tried enabling it again
--- End quote ---
What exactly do you enable?

--- Quote ---The problem is that reparsing doesn't work correctly in that setup.
--- End quote ---
If I understand the problem correctly, it should be possible to make clang create the PCH cache for an include subtree of an include tree of a particular selectable translation unit. Meaning that you view the header file as a root of a virtual include tree that is terminated at the point of first inclusion of the header file in the original tree of the chosen translation unit. Essentially this way of parsing is a generalization of your current parsing for the case when the virtual include tree does not match the actual include tree that is built starting directly from the header file as the root.

yvesdm3000:

--- Quote from: l_inc on August 21, 2016, 08:19:19 pm ---yvesdm3000

--- Quote ---Yes I briefly looked at that and tried enabling it again
--- End quote ---
What exactly do you enable?

--- End quote ---
There is some lookup code where given a specific FileId it searches for an existing translation unit. This is currently disabled

--- Quote ---
--- Quote ---The problem is that reparsing doesn't work correctly in that setup.
--- End quote ---
If I understand the problem correctly, it should be possible to make clang create the PCH cache for an include subtree of an include tree of a particular selectable translation unit. Meaning that you view the header file as a root of a virtual include tree that is terminated at the point of first inclusion of the header file in the original tree of the chosen translation unit. Essentially this way of parsing is a generalization of your current parsing for the case when the virtual include tree does not match the actual include tree that is built starting directly from the header file as the root.

--- End quote ---
<-- Really needed to read this a couple of times... The PCH cache creation is completely handled by Clang and is simply enabled by an option flag. Maybe we should find a way to handle this PCH cache ourselves?

Yves

l_inc:
yvesdm3000

--- Quote ---<-- Really needed to read this a couple of times... The PCH cache creation is completely handled by Clang and is simply enabled by an option flag.
--- End quote ---
I'm sorry for unclear expressions. I must have given an example of what interface I expect libclang to provide to achieve this. Ideally I expect libclang to allow to setup a callback. This callback should be called every time libclang processes the include directive. And the callback should allow to stop PCH generation. The resulting PCH then represents the result of processing of the subtree I was talking about. In case such a callback interface is not provided, it shouldn't be too complicated to add such an interface.

To say it in different words. You let libclang generate a PCH for translation unit of user's choice. You hook processing of the include directive. During PCH generation your hook/callback checks the file included by the directive. If this is the header file you are interested in, the hook should make libclang finalize PCH creation. This way created PCH is then used for code completion in the header file.

I know it sounds like a foolish speculation, but I can try to have a look at libclang's code and to add such a callback if clang really doesn't provide it or any equivalent interface.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version