Parsing issues with libclang5 on kdevelop 5.2.1

[René J.V. Bertin]

On Monday March 05 2018 11:18:39 Milian Wolff wrote:

> This is about the compiler built-in macros and include paths, cf. 
> IncludesAndDefinesManager code which queries a compiler.

Ah, right.

> 
> We may need to get rid of this feature, as it apparently does not work. But 
> that means KDevelop will basically require clang as a compiler, which is 
> different from libclang as a parser...

Maybe the issue is in the "a" (in "queries a compiler") above, and KDevelop should instead offer a possibility to select the exact compiler to be used by the project, so that the libclang parser can be configured to use the exact paths and macros as far as that is possible? (But maybe it already does this when it can get the exact compiler info from the build system?)

Locking in to a specific compiler doesn't seem like a good design choice, esp. if that is for a relative minority of projects. AFAIC it's easier to live with an imperfect parser than with having to use another IDE for projects that just don't build with clang. That still includes almost anything kernel-related, no?

A couple of brain farts:

- I know how much a really failing parser can get in the way, it should probably be possible to add an auto-shut-up option to the parser that activates when there is more than a certain percentage of lines with errors?
- I seem to recall from a previous discussion that it should be feasible technically to load libclang dynamically. If certain libclang versions are more issue prone than others that might justify implementing such a feature, for the benefit of users who do not want to build KDevelop themselves?

This is a bit comparing apples and pears, but I've never noticed a systematically better parsing experience with KDevelop on Mac (= using clang systematically) than on Linux (where I mostly use GCC).