https://bugs.kde.org/show_bug.cgi?id=405221
Bug ID: 405221
Summary: Faulty code parsing with Clang backend
Product: kdevelop
Version: 5.3.2
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Language Support: CPP (Clang-based)
Assignee: kdevelop-bugs-n...@kde.org
Reporter: axel_kellerm...@mentor.com
Target Milestone: ---
Created attachment 118650
--> https://bugs.kde.org/attachment.cgi?id=118650&action=edit
Quick fix
SUMMARY
If I use Clang as backend for source parsing, none of the stdlib/libstdc++
headers on my system are found and parsing flat out fails as the maximum amount
of parse errors is reached. This completely breaks code browsing and renders
kdevelop virtually unusable on my system. (See ADDITIONAL INFORMATION for more
details).
STEPS TO REPRODUCE
1. Set Clang as compiler for Parsing
Project -> Open Configuration -> Language Support -> C/C++ Parser ->
Compiler for path = Clang
2. Open any project
3. See if includes are found and code browsing works
OBSERVED RESULT
None of the stdlib/libstdc++ headers are found, parsing fails, code browsing
isn't working.
EXPECTED RESULT
Headers are found, code parsing and browsing works.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Archlinux/Plasma 5
KDE Plasma Version: 5.15.2
KDE Frameworks Version: 5.55.0
Qt Version: 5.12.1
KDevelop Version: 5.3.2
ADDITIONAL INFORMATION
While digging around, I found out that this erroneous behavior only occurs on
my system, if I use Clang as backend for parsing (which is the default). If I
switch to GCC, it all works fine. Some further investigations and a direct
comparison of kdevelop provided by my package manager and a custom kdesrc-build
of the same revision that worked correctly showed, that the only difference was
the PATH environment variable set during the start of kdevelop. In the
kdesrc-build environment, kdevelop gets started like
PATH=/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
kdevelop --ps
which leads to enumeration of system include paths in the form of
"/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1"
which then gets correctly translated by class Path into
"/usr/include/c++/8.2.1"
Starting kdevelop provided by the package manager within the standard system
environment looks like
PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
kdevelop --ps
which leads to enumeration of system include paths in the form of
"/bin/../lib64/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1"
which then gets translated by class Path into the non-existent path
"/include/c++/8.2.1"
The difference here being that the latter has /bin as first element of PATH.
/bin is a symbolic link to /usr/bin, so the result should be the same. But
apparently class Path doesn't properly resolve the symbolic link, which leads
to the creation of non-existent include paths. I'm going to attach a quick and
simple fix, but I'm not sure if this is the right way to do it. Maybe one of
the devs could have a look.
--
You are receiving this mail because:
You are watching all bug changes.
