Parsing issues with libclang5 on kdevelop 5.2.1

[Mathias Kraus]

Does anyone have problems with parsing when using kdevelop 5.2.1 with libclang5. I'm using KDE neon which ships libclang5 since a few weeks and I had problems with parsing since then, e.g. displayed error for connection Qt signals and slots. Just reverted back to libclang4 and everything is fine again.

Regards,
Mathias

[René J.V. Bertin]

Hi,

Post by Mathias Kraus
Does anyone have problems with parsing when using kdevelop 5.2.1 with libclang5. I'm using KDE neon which ships libclang5 since a few weeks and I had problems with parsing since then, e.g. displayed error for connection Qt signals and slots. Just reverted back to libclang4 and everything is fine again.

Yeah, and crashes in libclang5 either for no apparent reason (correct code) or while editing code.

I'm using the .debs directly from llvm.org which gets regular updates and I'd say things have been improving steadily. You can always install the llvm5 packages from there too and make sure KDevelop uses that libclang.

R.

[Milian Wolff]

Post by Mathias Kraus
Does anyone have problems with parsing when using kdevelop 5.2.1 with
libclang5. I'm using KDE neon which ships libclang5 since a few weeks and I
had problems with parsing since then, e.g. displayed error for connection
Qt signals and slots. Just reverted back to libclang4 and everything is
fine again.

I have seen one issue myself, so maybe that's also it. To verify: Can you
please do the following:

In one of the erroneous files, open the Problems tool view, select "show
imports" and then inspect the errors that you see?

In my case, I've sometimes seen issues with the maximum template instantiation
depth being reached, leading to dozens of errors which eventually let the
parser give up. Is that the case for you too? Can you fix it by increasing the
instantiation depth via the project settings -> custom defines/includes ->
compilers -> add -ftemplate-depth=1024 or even something higher?

Cheers

[Mathias Kraus]

Post by Milian Wolff

Post by Mathias Kraus
Does anyone have problems with parsing when using kdevelop 5.2.1 with
libclang5. I'm using KDE neon which ships libclang5 since a few weeks and I
had problems with parsing since then, e.g. displayed error for connection
Qt signals and slots. Just reverted back to libclang4 and everything is
fine again.

I have seen one issue myself, so maybe that's also it. To verify: Can you
In one of the erroneous files, open the Problems tool view, select "show
imports" and then inspect the errors that you see?
In my case, I've sometimes seen issues with the maximum template instantiation
depth being reached, leading to dozens of errors which eventually let the
parser give up. Is that the case for you too?

There are many errors, but it seems they are not related to template instantiation.

Post by Milian Wolff
Can you fix it by increasing the
instantiation depth via the project settings -> custom defines/includes ->
compilers -> add -ftemplate-depth=1024 or even something higher?

I couldn't find something like that. Did you mean this?
Project -> Open Configuration -> Language Support -> Defines Tab

I could create a minimal example and upload it somewhere if it helps.

[Mathias Kraus]

Post by Mathias Kraus

Post by Milian Wolff

Post by Mathias Kraus
Does anyone have problems with parsing when using kdevelop 5.2.1 with
libclang5. I'm using KDE neon which ships libclang5 since a few weeks and I
had problems with parsing since then, e.g. displayed error for connection
Qt signals and slots. Just reverted back to libclang4 and everything is
fine again.

I have seen one issue myself, so maybe that's also it. To verify: Can you
In one of the erroneous files, open the Problems tool view, select "show
imports" and then inspect the errors that you see?
In my case, I've sometimes seen issues with the maximum template instantiation
depth being reached, leading to dozens of errors which eventually let the
parser give up. Is that the case for you too?

There are many errors, but it seems they are not related to template instantiation.

Post by Milian Wolff
Can you fix it by increasing the
instantiation depth via the project settings -> custom defines/includes ->
compilers -> add -ftemplate-depth=1024 or even something higher?

I couldn't find something like that. Did you mean this?
Project -> Open Configuration -> Language Support -> Defines Tab
I could create a minimal example and upload it somewhere if it helps.

I think I found the problem. By default, gcc is set as compiler at Project -> Open Configuration -> Language Support -> C/C++ Parser.
Setting it to clang solved the problem. Is there somewhere a configuration option to set clang as default?

Regards,
Mathias

[René J.V. Bertin]

Post by Mathias Kraus
I think I found the problem. By default, gcc is set as compiler at Project -> Open Configuration -> Language Support -> C/C++ Parser.
Setting it to clang solved the problem. Is there somewhere a configuration option to set clang as default?

This may be a stupid question: can libclang be set to parse as if it's GCC, or is the option name an echo from the past when KDevelop had its own parser?

R.

[Milian Wolff]

Post by René J.V. Bertin

Post by Mathias Kraus
I think I found the problem. By default, gcc is set as compiler at Project
-> Open Configuration -> Language Support -> C/C++ Parser. Setting it to
clang solved the problem. Is there somewhere a configuration option to set
clang as default?

This may be a stupid question: can libclang be set to parse as if it's GCC,
or is the option name an echo from the past when KDevelop had its own
parser?

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

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...

[René J.V. Bertin]

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

Ah, right.

Post by Milian Wolff
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).