First approach on a debug view for the clang plugin
AbandonedPublic

Authored by apol on Jun 17 2016, 11:06 AM.

Details

Reviewers
None

Diff Detail

Repository
R32 KDevelop
Branch
5.0
Lint
No Linters Available
Unit
No Unit Test Coverage
apol updated this revision to Diff 4589.Jun 17 2016, 11:06 AM
apol retitled this revision from to First approach on a debug view for the clang plugin.
apol updated this object.
apol edited the test plan for this revision. (Show Details)
apol added a subscriber: KDevelop.
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptJun 17 2016, 11:06 AM
mwolff added a subscriber: mwolff.Jun 17 2016, 1:39 PM

Can you please comment on what you are trying to achieve here? The commit message is very terse and needs to be expanded. Some kind of API dox for the class would probably be a good idea as well, just a simple "this is for X" would be very helpful already.

Overall, this looks like you are trying to add a graphical qDebug stream? I'm not fond of that idea, why is qDebug and friends not enough for you?

apol added a comment.Jun 17 2016, 7:57 PM
In D1936#35682, @mwolff wrote:

Can you please comment on what you are trying to achieve here? The commit message is very terse and needs to be expanded. Some kind of API dox for the class would probably be a good idea as well, just a simple "this is for X" would be very helpful already.

The premise with this work is that we need to get better at fixing issues in clang support. Kevin proposed having a dialog with information regarding each file as a solution to diagnose the possible problems. This is what I came up with as a first approach. Having:

  • trigger command line
  • problems found
  • includes
  • defines

I think it would be best to show more information, especially on the clang side, but still open for discussion what's best.

The problems we show already. What is missing is storing the includes and defines, something that is on our TODO (or isn't it?). The oldcpp plugin did that, and allowed us to show a useful message when hovering an "include not found" error, i.e.:

#include <foobar.h>

Error: foobar.h not found.
Searched in paths: /foo /bar /baz

The trigger command line can be found from the CLI debug output, if really needed... So do we really want a graphical widget that displays this information? I don't... But if you guys want it, I won't block that.

apol abandoned this revision.Jan 21 2017, 12:46 AM