Bug 358506

Summary: Fix-it hint for missing include should suggest QCamelCase include
Product: [Applications] kdevelop Reporter: David Faure <faure>
Component: Language Support: CPP (Clang-based)Assignee: kdevelop-bugs-null
Status: RESOLVED FIXED    
Severity: normal CC: kfunk
Priority: VHI Keywords: release_blocker
Version First Reported In: 4.90.91   
Target Milestone: 5.0.0   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: http://commits.kde.org/kdevelop/6ca8995de6fcf6874c63dc5c6c9ef98d71c41cc4 Version Fixed/Implemented In:
Sentry Crash Report:

Description David Faure 2016-01-24 21:58:39 UTC 
The fix-it hint in case of missing #include for e.g. QBuffer should suggest <QBuffer>, not just <qbuffer.h> and <../src/corelib/io/qbuffer.h>

Reproducible: Always

Steps to Reproduce:
1. Configure Qt with -developer-build (I don't know if it works on an installed Qt)
2. Open kio/autotests/clipboardupdatertest.cpp
3. In initTestCase() type QBuffer buffer;


Actual Results:  
The fix-it hints (both the ones on top and the redundant ones in the "Problem in semantic analysis" button (why the duplication of GUI?) offer only <qbuffer.h> and <../src/corelib/io/qbuffer.h>

Expected Results:  
I would expect only one GUI for fix-it hints (right now it's a bit of a mess, it seems quite unreliable when either one is going to pop up), but mostly this bug is that I would expect <QBuffer> as a suggested include, as recommended by the Qt documentation (and as QtCreator does).
Comment 1 Kevin Funk 2016-01-24 22:19:00 UTC 
Regarding the duplication of GUIs: You're using kdevelop from master, right? We have a few "bad commits" in there which change the way fixits are handled. We've reverted them in the 5.0 branch, but didn't do so in master yet. Sorry for this.

Regarding KDevelop not suggesting <QBuffer>: That's a problem with the developer-build of Qt indeed. Right now we don't propose headers which just include other headers. (In a developer build, the QBuffer header just includes qbuffer.h, that's all it does). As far as I remember this rule is here to be able to only propose include files which actually contain the declaration you're looking for (IOW: KDevelop knows the QBuffer decl is part of qbuffer.h, but not <QBuffer>, thus doesn't propose the latter).

We should probably ignore that rule specifically for Qt developer-builds, in some way...
Comment 2 David Faure 2016-01-25 07:24:50 UTC 
No I'm using branch 5.0 now, after Milian said the same.
(and yeah, I hate branches, especially when master isn't the latest and greatest...)

Even in 5.0 there are two guis: the numbered suggestions at the top of the view,
and the pushbutton in the "Semantic analysis" popup.
Comment 3 David Faure 2016-01-25 07:27:35 UTC 
One possible solution is to offer <QFoo> for QFoo, i.e. rely on the Qt headers being correct, in addition to the code that actually parses them. I suppose that's what QtCreator does...
  (after checking that such a file does exist, of course).
Comment 4 Milian Wolff 2016-01-25 17:46:02 UTC 
I agree, if we find an include that is named like the class we should prefer it. We can even look at its DUContext and see if we can resolves QID of the forward declaration from there.
Comment 5 Milian Wolff 2016-01-30 17:41:10 UTC 
Git commit 6ca8995de6fcf6874c63dc5c6c9ef98d71c41cc4 by Milian Wolff.
Committed on 30/01/2016 at 17:40.
Pushed by mwolff into branch '5.0'.

Ignore case when searching for missing include files.

This way we can also offer the Qt camelcase includes.

M  +5    -9    languages/clang/duchain/unknowndeclarationproblem.cpp

http://commits.kde.org/kdevelop/6ca8995de6fcf6874c63dc5c6c9ef98d71c41cc4