Bug 1119186

Summary: kdevelop5: Code completion and parser don't work
Product: [openSUSE] openSUSE Tumbleweed Reporter: Krzysztof Kurek <krzysio.kurek>
Component: KDE ApplicationsAssignee: E-Mail List <opensuse-kde-bugs>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: aaronpuchert, krzysio.kurek, lbeltrame, wbauer
Version: Current   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE Factory   
See Also: http://bugzilla.opensuse.org/show_bug.cgi?id=1198525
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Krzysztof Kurek 2018-12-11 21:33:01 UTC
Installed with zypper without any additional parameters.
Works with same options on the same project if using AppImage.
Comment 1 Wolfgang Bauer 2018-12-12 18:12:39 UTC
Works fine here.

What openSUSE version are you using?

What kdevelop related packages do you have installed exactly?
zypper se -si kdev

Also, you didn't provide much (or any) information about the actual problem.
Which kind of files/programming language is/are affected?
I assume C++, is that right?
Comment 2 Krzysztof Kurek 2018-12-12 20:29:00 UTC
S  | Name              | Type    | Version                    | Arch   | Repository             
---+-------------------+---------+----------------------------+--------+------------------------
i+ | kdevelop5         | package | 5.3.0-2.1                  | x86_64 | openSUSE-Tumbleweed-Oss
i  | kdevelop5-lang    | package | 5.3.0-2.1                  | noarch | openSUSE-Tumbleweed-Oss
i  | kdevplatform      | package | 5.3.0-2.1                  | x86_64 | openSUSE-Tumbleweed-Oss
i  | kdevplatform-lang | package | 5.3.0-2.1                  | noarch | openSUSE-Tumbleweed-Oss
i+ | libblockdev       | package | 2.18-1.1                   | x86_64 | openSUSE-Tumbleweed-Oss
i+ | libblockdev2      | package | 2.18-1.1                   | x86_64 | openSUSE-Tumbleweed-Oss
i  | libkdevplatform53 | package | 5.3.0-2.1                  | x86_64 | openSUSE-Tumbleweed-Oss
i+ | liblockdev1       | package | 1.0.3_git201003141408-31.1 | x86_64 | openSUSE-Tumbleweed-Oss
i+ | lockdev           | package | 1.0.3_git201003141408-31.1 | x86_64 | openSUSE-Tumbleweed-Oss

Yes, my problem is with C++ projects. In the AppImage I can hover over various objects and peek at their types or declarations, additionally each object is colour coded. In the version installed through Zypper however there are no code hints available, no colour coding of individual objects, no coding errors are detected, and no problems are being reported.
Essentially all of the compiler integration is absent, and Kdevelop's text editor acts more like vanilla kate, with basic syntax highlighting.
This happens regardless of which compiler I choose as a parser, be it clang or GCC.

I'm using OpenSUSE Tumbleweed, and I'm currently on 20181211.
Comment 3 Wolfgang Bauer 2018-12-12 22:24:37 UTC
(In reply to Krzysztof Kurek from comment #2)
> S  | Name              | Type    | Version                    | Arch   |
> Repository             
> ---+-------------------+---------+----------------------------+--------+-----
> -------------------
> i+ | kdevelop5         | package | 5.3.0-2.1                  | x86_64 |
> openSUSE-Tumbleweed-Oss
> i  | kdevelop5-lang    | package | 5.3.0-2.1                  | noarch |
> openSUSE-Tumbleweed-Oss
> i  | kdevplatform      | package | 5.3.0-2.1                  | x86_64 |
> openSUSE-Tumbleweed-Oss
> i  | kdevplatform-lang | package | 5.3.0-2.1                  | noarch |
> openSUSE-Tumbleweed-Oss
> i+ | libblockdev       | package | 2.18-1.1                   | x86_64 |
> openSUSE-Tumbleweed-Oss
> i+ | libblockdev2      | package | 2.18-1.1                   | x86_64 |
> openSUSE-Tumbleweed-Oss
> i  | libkdevplatform53 | package | 5.3.0-2.1                  | x86_64 |
> openSUSE-Tumbleweed-Oss
> i+ | liblockdev1       | package | 1.0.3_git201003141408-31.1 | x86_64 |
> openSUSE-Tumbleweed-Oss
> i+ | lockdev           | package | 1.0.3_git201003141408-31.1 | x86_64 |
> openSUSE-Tumbleweed-Oss

Looks fine. I suspected some version inconsistency from different repos.

I'm wondering why you reported this against KDE:Extra then, but well... ;-)

Hm, not sure at the moment why it's not working for you.
I'm using Leap 15.0 here with the latest version from KDE:Extra (devel project for Tumbleweed, so should be the same), and the things you describe do work fine here.

Too late now for more though, I'll look at it again tomorrow.

Just one thing: you don't have the c++ parser disabled by chance?
Maybe you could try on a fresh user account to rule out a problem with the settings. (I think the Appimage wouldn't use the config files in the user's home)
Comment 4 Luca Beltrame 2018-12-12 22:30:24 UTC
Do you have the clang headers installed? (clang-devel)
Comment 5 Krzysztof Kurek 2018-12-12 22:40:31 UTC
Oh, no I didn't.
Indeed after installing the package code completion started working.
Comment 6 Wolfgang Bauer 2018-12-12 22:42:20 UTC
(In reply to Luca Beltrame from comment #4)
> Do you have the clang headers installed? (clang-devel)

Well, I don't have them installed here.

But they may be required in Tumbleweed now, I suppose?
Comment 7 Luca Beltrame 2018-12-12 22:48:01 UTC
Likely yes, starting from 5.3. It actually prints a message to stdout saying it can't find them. Of course, easy to miss.
Comment 8 Krzysztof Kurek 2018-12-12 22:49:55 UTC
(In reply to Wolfgang Bauer from comment #3)
> I'm wondering why you reported this against KDE:Extra then, but well... ;-)
I'm sorry but I'm completely new to OpenSUSE and I was told to report this as a bug, so I pressed the Report Bug link on the OBS Project's page and came here.

> But they may be required in Tumbleweed now, I suppose?
Oh yeah I've noticed that with the clang-devel package uninstalled kdevelop prints this to the console:
kdevplatform.shell: Could not load plugin "kdevclangsupport" , it reported the error: "The clang builtin include path \"/usr/lib64/clang/6.0.1/include\" is invalid (missing cpuid.h header).\nTry setting the KDEV_CLANG_BUILTIN_DIR environment variable manually to fix this.\nSee also: https://bugs.kde.org/show_bug.cgi?id=393779"
Comment 9 Wolfgang Bauer 2018-12-13 13:32:42 UTC
(In reply to Luca Beltrame from comment #7)
> Likely yes, starting from 5.3. It actually prints a message to stdout saying
> it can't find them. Of course, easy to miss.

I am using kdevelop 5.3.0 on Leap 15.0, and I see no problem or that message here without clang-devel (or clang5-devel) installed.

So it seems to be caused by a change in clang...

Anyway, if it is needed, we should of course add a Requires to the kdevelop5 package.
I'll take care of that, maybe together with the 5.3.1 update I already prepared (I'm just waiting for the announcement before I submit it...)

PS: the include files are part of the clang package itself in Leap 15.0:
$ rpm -qf /usr/lib64/clang/5.0.1/include/
clang5-5.0.1-lp150.7.3.1.x86_64

Although, I'm not sure that's being installed by default either. The only packages that requires it on my system are libqt5-qttools-doc and kdevelop5-plugin-clang-tidy.
Comment 10 Wolfgang Bauer 2018-12-13 13:57:30 UTC
(In reply to Wolfgang Bauer from comment #9)
> PS: the include files are part of the clang package itself in Leap 15.0:
> $ rpm -qf /usr/lib64/clang/5.0.1/include/
> clang5-5.0.1-lp150.7.3.1.x86_64

And uninstalling clang5 reproduces the problem for me, i.e. breaks the C(++) support.

I just had a look at the Tumbleweed packages, and the cpuid.h header (mentioned in the error message) is in clang(6) there as well, so that's what's actually required. (clang-devel will of course pull this in too)

The question now is: do we really need to require clang-devel, or is clang sufficient?
As mentioned, I didn't notice any problems without the latter here, but I might have missed something of course.
Comment 11 Krzysztof Kurek 2018-12-13 16:38:05 UTC
I've had clang installed and it didn't suffice.
Comment 12 Wolfgang Bauer 2018-12-13 22:22:34 UTC
(In reply to Krzysztof Kurek from comment #11)
> I've had clang installed and it didn't suffice.
Are you sure you really had clang installed and not just libclang6? (the latter is being pulled in by kdevelop5 already)

I just tried on a current Tumbleweed KDE LiveCD, and installing clang (and not clang-devel) definitely did make the C(++) parser and code completion work, and the error message disappear.

I'd somehow prefer to just require clang, because clang-devel does have quite some more dependencies...
Comment 13 Krzysztof Kurek 2018-12-14 00:25:39 UTC
Ah, I've made an oversight. I had clang7 installed, not clang.
Indeed it works with just clang, and doesn't require clang-devel.
Comment 14 Wolfgang Bauer 2018-12-14 07:47:11 UTC
(In reply to Krzysztof Kurek from comment #13)
> Ah, I've made an oversight. I had clang7 installed, not clang.
> Indeed it works with just clang, and doesn't require clang-devel.

Yes, as the version is part of the include path, you need the same version installed that it is built against. (i.e. clang7-devel wouldn't have helped either)
Unless you explicitly set $KDEV_CLANG_BUILTIN_DIR yourself...
(there is some autodetection on runtime, but only on Windows so far: https://cgit.kde.org/kdevelop.git/commit/?h=5.3&id=ec5477f351b6c4b25b7f6533314628ebdd7c2945 )

That also means that we should probably better use "%requires_eq clang" to force the "correct" version.
Comment 15 Luca Beltrame 2018-12-14 08:08:02 UTC
(In reply to Wolfgang Bauer from comment #14)

> That also means that we should probably better use "%requires_eq clang" to
> force the "correct" version.

Agreed. This is probably the best way to go.
Comment 16 Wolfgang Bauer 2018-12-18 13:02:24 UTC
The mentioned change is on the way to Factory/Tumbleweed:
https://build.opensuse.org/request/show/659267
Comment 17 Aaron Puchert 2019-02-03 23:54:23 UTC
(In reply to Luca Beltrame from comment #15)
> (In reply to Wolfgang Bauer from comment #14)
> 
> > That also means that we should probably better use "%requires_eq clang" to
> > force the "correct" version.
> 
> Agreed. This is probably the best way to go.

I think with https://phabricator.kde.org/D12331 and https://phabricator.kde.org/D17858 in upstream this should no longer be necessary. The last change will be contained in the next 5.3 update or 5.4.
Comment 18 Wolfgang Bauer 2019-02-04 06:28:10 UTC
(In reply to Aaron Puchert from comment #17)
> (In reply to Luca Beltrame from comment #15)
> > (In reply to Wolfgang Bauer from comment #14)
> > 
> > > That also means that we should probably better use "%requires_eq clang" to
> > > force the "correct" version.
> > 
> > Agreed. This is probably the best way to go.
> 
> I think with https://phabricator.kde.org/D12331 and
> https://phabricator.kde.org/D17858 in upstream this should no longer be
> necessary. The last change will be contained in the next 5.3 update or 5.4.

Yes, I'm aware of that and will keep it in mind for the next update.

But to clarify: The first one is already in 5.3.0 and obviously doesn't help here.
The second one should indeed make it unnecessary to require the exact same version as it was built against, but as I see it you still need the exact same versions of clang and libclang installed.

In practice, removing the %requires_eq again won't gain much for the user though (it just will avoid package rebuilds when there are minor clang updates), so we probably still should keep it to be on the safe side.
Actually I can imagine a situation where it probably won't help:
Consider clang/llvm is upgraded to 8.x. The clang and clang-devel packages will point to 8.x eventually, but as 7.x is still in the repos, kdevelop5 won't get rebuilt and continues to use 7.x. There is no dependency on clang7 though, only clang (which pulls in clang8 then), so the appropriate headers will be missing (if you install it fresh at least, when updating the installed clang7 should not get removed I hope)...
Probably an edge case though.
Comment 19 Aaron Puchert 2019-02-05 01:07:27 UTC
(In reply to Wolfgang Bauer from comment #18)
> The second one should indeed make it unnecessary to require the exact same
> version as it was built against, but as I see it you still need the exact
> same versions of clang and libclang installed.
We don't actually need clang, but the builtin headers. I've thought about whether they should not in fact be part of the libclang package, because every package I know that uses libclang also wants these headers and I'm not sure what you can do with libclang without them. (There isn't much you can do.)

> In practice, removing the %requires_eq again won't gain much for the user
> though (it just will avoid package rebuilds when there are minor clang
> updates), so we probably still should keep it to be on the safe side.
Not with vanilla Tumbleweed, but I find myself occasionally using updates from devel:tools:compiler that haven't landed in Factory yet — then I have to tell zypper to "break" KDevelop. It does actually break, but I can fix that by setting KDEV_CLANG_BUILTIN_DIR. Ideally Clang would just use the major version for the include directory (like GCC does) or create a symlink, but apparently nobody has thought about that yet.

> Actually I can imagine a situation where it probably won't help:
> Consider clang/llvm is upgraded to 8.x. The clang and clang-devel packages
> will point to 8.x eventually, but as 7.x is still in the repos, kdevelop5
> won't get rebuilt and continues to use 7.x.
Something similar actually happened with the update to LLVM 7.0.0 — KDevelop didn't properly work for about a week or two because it linked with libLLVM.so.6 and libLLVM.so.7 at the same time. I had opened bug 1120416 for that, which is now resolved, but it will likely appear again.

> There is no dependency on clang7 though, only clang (which pulls in clang8
> then), so the appropriate headers will be missing (if you install it fresh at
> least, when updating the installed clang7 should not get removed I hope)...
> Probably an edge case though.
Would that be solved if we package the headers with libclang or in a package required by libclang?
Comment 20 Wolfgang Bauer 2019-02-05 08:29:08 UTC
(In reply to Aaron Puchert from comment #19)
> > In practice, removing the %requires_eq again won't gain much for the user
> > though (it just will avoid package rebuilds when there are minor clang
> > updates), so we probably still should keep it to be on the safe side.
> Not with vanilla Tumbleweed, but I find myself occasionally using updates
> from devel:tools:compiler that haven't landed in Factory yet

Ok, I suppose that it is indeed a problem in that case (unless kdevelop5 would be built against that repo).
Unfortunately, I don't see how we can really cover all cases inside the kdevelop5 package (with the way clang is packaged currently)... If we make your case work, it can break for others.

> Not with vanilla Tumbleweed, but I find myself occasionally using updates from > devel:tools:compiler that haven't landed in Factory yet — then I have to tell > zypper to "break" KDevelop. It does actually break, but I can fix
> that by setting KDEV_CLANG_BUILTIN_DIR.

I suppose the latter should actually be "fixed" by https://phabricator.kde.org/D17858.

> > Actually I can imagine a situation where it probably won't help:
> > Consider clang/llvm is upgraded to 8.x. The clang and clang-devel packages
> > will point to 8.x eventually, but as 7.x is still in the repos, kdevelop5
> > won't get rebuilt and continues to use 7.x.
> Something similar actually happened with the update to LLVM 7.0.0 — KDevelop
> didn't properly work for about a week or two because it linked with
> libLLVM.so.6 and libLLVM.so.7 at the same time. I had opened bug 1120416 for
> that, which is now resolved, but it will likely appear again.

Well, that could just as well happen without the %requires_eq, because there is no guarantee that Mesa and kdevelop5 would be rebuilt at the same time (e.g. kdevelop5 could get an update and being rebuilt against the newer version, but Mesa not).
Using %requires_eq in both (or actually *all* packages that use clang/libclang) should avoid that though I suppose... ;-)

> > There is no dependency on clang7 though, only clang (which pulls in clang8
> > then), so the appropriate headers will be missing (if you install it fresh at
> > least, when updating the installed clang7 should not get removed I hope)...
> > Probably an edge case though.
> Would that be solved if we package the headers with libclang or in a package
> required by libclang?

Sure, if libclang(X) contains the headers itself, it's basically "guaranteed" that they are available and in the right place.
That's probably indeed the best way to ensure this.
No idea if that is a feasible/desirable thing to do (from the clang packaging side) though.
Comment 21 Aaron Puchert 2019-02-06 00:08:35 UTC
> Well, that could just as well happen without the %requires_eq, because there
> is no guarantee that Mesa and kdevelop5 would be rebuilt at the same time
> (e.g. kdevelop5 could get an update and being rebuilt against the newer
> version, but Mesa not).
Yes, that doesn't help. I thought about whether an update to llvm6 would have helped, but then I didn't find anything to update there.

> > Would that be solved if we package the headers with libclang or in a package
> > required by libclang?
> 
> Sure, if libclang(X) contains the headers itself, it's basically
> "guaranteed" that they are available and in the right place.
> That's probably indeed the best way to ensure this.
> No idea if that is a feasible/desirable thing to do (from the clang
> packaging side) though.

I will propose this to the maintainer. I'm maintaining another package (include-what-you-use) where I have to add a dependency on Clang although the compiler itself is not needed. It just uses libclang, which needs the builtin headers to parse code. KDevelop is in a similar situation.
Comment 22 Wolfgang Bauer 2019-03-07 14:38:10 UTC
FYI: kdevelop 5.3.2 has been released today.
I removed the %requires_eq, and added a Requires: clangX (corresponding to the libclangX-devel that's used for building) now:
Requires:       clang%(rpm -q --qf '%''{version}' clang-devel | cut -d. -f1)
(inspired by what we have in the libqt5-creator package...)

That should be safe enough I hope, and should also allow you to install a newer clang from 3rd party repos.

https://build.opensuse.org/request/show/682480
Comment 23 Aaron Puchert 2019-03-14 22:36:32 UTC
(In reply to Wolfgang Bauer from comment #22)
> FYI: kdevelop 5.3.2 has been released today.
> I removed the %requires_eq, and added a Requires: clangX (corresponding to
> the libclangX-devel that's used for building) now:
> Requires:       clang%(rpm -q --qf '%''{version}' clang-devel | cut -d. -f1)
> (inspired by what we have in the libqt5-creator package...)
> 
> That should be safe enough I hope, and should also allow you to install a
> newer clang from 3rd party repos.
> 
> https://build.opensuse.org/request/show/682480
Cool, thanks.

Please have a look at https://build.opensuse.org/request/show/685028. It moves the Clang builtin headers from the clang7 package to libclang7. When it lands in Factory, you should be able to remove the runtime dependency to clangX completely.

Does (the current version of) KDevelop need to build for older versions of LLVM as well? In that case I'd need to port that change back to llvm{4-6}. Otherwise I'd just leave them as they are.

My understanding is that Leap has a fixed older version of KDevelop, so fixing this issue in llvm7 should be enough.
Comment 24 Wolfgang Bauer 2019-03-15 15:21:33 UTC
(In reply to Aaron Puchert from comment #23)
> Please have a look at https://build.opensuse.org/request/show/685028. It
> moves the Clang builtin headers from the clang7 package to libclang7. When
> it lands in Factory, you should be able to remove the runtime dependency to
> clangX completely.

Ok, thanks for the info, I will follow that up.

> Does (the current version of) KDevelop need to build for older versions of
> LLVM as well? In that case I'd need to port that change back to llvm{4-6}.
> Otherwise I'd just leave them as they are.

We do provide the latest kdevelop5 version in KDE:Extra for Leap 15.0 and 42.3 as well. (AFAICS, Leap 15.1 does have llvm7 as default already but without that change so far, apparently it comes from SLE, not Factory)

We can conditionally leave the dependency in for the older versions though, so it's not really necessary to release an update with this change from our side I think.

OTOH, kdevelop5-plugin-clang-tidy needs clangX anyway (for the clang-tidy executable), and will be included in kdevelop5 5.4 AFAIK (currently it's released separately). Although it's probably not necessary to add a Requires for that, a Recommends at most should be enough IMHO.