FS#56821 - [qtcreator] Clang code model can not find 'stddef.h'

Attached to Project: Arch Linux
Opened by Marius (Martchus) - Friday, 22 December 2017, 14:02 GMT
Last edited by Antonio Rojas (arojas) - Wednesday, 03 January 2018, 23:35 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:
Since updating the clang package to 5.0.1, the clang code model in Qt creator
can not find the header 'stddef.h' anymore.

This leads to a lot of error messages making the code model unusable.

The code model inspector correctly shows the relevant include directory
'/usr/lib/clang/5.0.1/include'. So it should actually be able to find the
header.

Downgrading to clang 5.0.0 helps (despite the header 'stddef.h' itself does
not differ from the 5.0.1 version). It is not even required to restart
Qt Creator.

So likely the source of the issue is the clang package.

Additional info:
* relevant packages/versions:
* qtcreator 4.5.0-1
* clang 5.0.1 (downgrading to 5.0.0 helps)
* exact error message: "fatal error: 'stddef.h' file not found"
* The compilation itself works fine.
* The issue is only triggered when using a kit with clang compiler.
* To work around this, it is not required to downgrade
clang-tools-extra, libc++ or any other packages. So it seems to
be just the core clang package which makes a difference.


Steps to reproduce:
0. Update to clang 5.0.1.
1. Open any project. I've just tested CMake-based ones so far.
2. Ensure the active kit is using clang.
3. Enjoy lots of error messages in any file which includes directly
or indirectly 'stddef.h'.
This task depends upon

Closed by  Antonio Rojas (arojas)
Wednesday, 03 January 2018, 23:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  qtcreator 4.5.0-2
Comment by Yichao Zhou (zhou13) - Saturday, 23 December 2017, 00:16 GMT
I got a similar problem. downgrading to 5.0.0 solves the problem.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 29 December 2017, 04:01 GMT
Sounds like an upstream issue where they don't know about clang 5.0.1 changes. Could you report an upstream issue and link it here?
Comment by Marius (Martchus) - Friday, 29 December 2017, 15:40 GMT
Yes, it is likely an upstream bug. However, it is hard to tell whether the change in clang is intentional or not. Likely it isn't. At least in a patch release I would not expect things to change in a breaking way. If it is an intentional change, though, it would be a Qt Creator bug.
Comment by Marius (Martchus) - Friday, 29 December 2017, 17:30 GMT
LebedevRI mentioned in IRC, that the GCC version could also make a difference. In fact, the working clang-5.0.0 is still built against gcc-multilib-7.2.0-1 and clang-5.0.1 is already built against gcc-7.2.1-2. However, at run-time in both cases gcc-7.2.1-2 is present. But I don't think that this really makes a difference.

Further, I was told to try bisecting. Maybe I'll actually try that. However, I would have to learn how to do that in SVN first (and how to use SVN at all). Convincing Qt Creator to use Clang from a custom path (also for the code model) might be difficult, though.
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 29 December 2017, 19:42 GMT
No need to usw svn, we have svn2gits for all repositories.
Comment by Eli Schwartz (eschwartz) - Friday, 29 December 2017, 19:53 GMT
Unfortunately, clang uses SVN. ;)

And one would want to bisect the upstream code, not the PKGBUILD.
Comment by Marius (Martchus) - Friday, 29 December 2017, 20:06 GMT
And my assumption was that Svenstaro is an LLVM/Clang developer, too :-)

So I looked at https://github.com/llvm-mirror/clang/commits/master. However, through the lack of tags I'm currently not quite sure which commits are relevant.
Comment by Knut Tidemann (Avenger) - Tuesday, 02 January 2018, 13:44 GMT
I had similar issues where the clang code model could not find any headers at all after the 5.0.1 update, and a rebuild of qt creator solved that particular issue for me.
Comment by Daniel Otero (canu7) - Wednesday, 03 January 2018, 20:55 GMT
The binary `/usr/lib/qtcreator/clangbackend` links with `libclang.so.5`. Maybe some subtle ABI change could produce this issue? Perhaps forcing a rebuild fix this problem, as pointed by Knut Tidemann.
Comment by Marius (Martchus) - Wednesday, 03 January 2018, 22:09 GMT
I have made the following observation:

1. When testing on my server instead on my workstation, everything works as expected with clang 5.0.1-1 and qtcreator 4.5.0-1. If not other people would have run into the exact same issue (and mentioning it on #qt-creator IRC channel), I would say there's just something wrong on my end. I also installed clang-tools-extra 5.0.1-1 and libc++ 5.0.1-1 on the server and it continued to work. So those packages doesn't make a difference, too. Hard to tell what's the relevant difference between the two machines.
2. When rebuilding Qt Creator and installing the resulting qtcreator 4.5.0-1.1 package on my workstation, the issue is gone, too.

So the issue might be caused by a messed up configuration. However, rebuilding Qt Creator apparently helps fixing it.
Comment by Evangelos Foutras (foutrelis) - Wednesday, 03 January 2018, 22:12 GMT
The Clang Code Model plugin appears to hardcode the clang version and include path at the time Qt Creator is compiled. (See cpp.defines in [1].)

As hinted by Knut, Qt Creator will need a rebuild; it would also be a good idea to depend on a specific clang version (i.e.: clang=5.0.1).

[1] https://github.com/qt-creator/qt-creator/blob/master/src/plugins/clangcodemodel/clangcodemodel.qbs
Comment by Marius (Martchus) - Wednesday, 03 January 2018, 22:46 GMT
Yes, it is definitely hard-coded (eg. try to run `for file in $(pacman -Ql qtcreator); do if [[ $file == qtcreator ]]; then continue; fi; if grep /usr/lib/clang/5.0.0 "$file"; then echo "$file"; fi; done`).

That makes it even stranger, that it works on my server and that the issue didn't occur after previous clang updates. Packages installed on my server:
> pacman -Q clang clang-tools-extra libc++ qtcreator
> clang 5.0.1-1
> clang-tools-extra 5.0.1-1
> libc++ 5.0.1-1
> qtcreator 4.5.0-1

The command mentioned above shows the hard-coded version 5.0.0 in '/usr/lib/qtcreator/plugins/libClangCodeModel.so'. However, hovering over '#include <stddef.h>' in Qt Creator shows the correct path '/usr/lib/clang/5.0.1/...'. That also proves, that clang is actually used when testing on the server. When switching to GCC compiler, the path changes to '/usr/lib/gcc/...'. I'm also testing with the exact same project files on my server. I really don't know what makes the difference here.

Comment by Evangelos Foutras (foutrelis) - Wednesday, 03 January 2018, 22:53 GMT
Do you have the ClangCodeModel plugin enabled on your server?

(The issue is reproducible for me even with a new "Non-Qt Project -> Plain C++ Application", assuming the ClangCodeModel plugin is enabled and the selected compiler is clang.)
Comment by Marius (Martchus) - Wednesday, 03 January 2018, 23:00 GMT
No, I haven't had it enabled. If I enable the plugin I can also reproduce. I looked for a way to disable the plugin before and haven't found anything in the settings so I assumed it is always enabled nowadays. However, it turns out one can enable/disable it under plugins and not in the main settings dialogs.

Loading...