Bug 68610 - provide more warnings about code-problems like unused variables
Summary: provide more warnings about code-problems like unused variables
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (show other bugs)
Version: 4.0.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-19 22:24 UTC by Jesse
Modified: 2016-03-24 13:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse 2003-11-19 22:24:17 UTC
Version:           3.0.0b1 (using KDE Devel)
Installed from:    Compiled sources
OS:          Linux

Enhancing the problem reporter with the following additions will make it infinitly more useable.  (cpp problem reporter)

- Report unused vars and parameters (obvious)

- Vars that have not been declared within scope should be marked
  If I try to use var1 and I haven't declared it yet (or maybe misspelled it) should be indicated

- Invalid method invocations
  Currently if I have obj.do_stuff (); it reports no error (syntactically correct) but method do_stuff () does not exist :(

- Use of deprecated API
  Even though a properly deprecated method in gcc will trigger an output warning upon compilation, it might be good to also report the problem as well

- Problem reporter is too strict and interferes with rest of code
  This is a side affect of the c language in that one misplaced ; will result in hundreds of weird errors.  Perhaps the reporter should try to go line-at-a-time (using some context of course) to prevent the reporter from generating 10 useless errors from one misplaced ;

** Use new arbitrary highlighter to mark the problems in the editor as well
as in the reporter view.

I do a little development with Kate and there's been some talk of creating an arbitrary highlighter so smart applications like KDevelop and Quanta can instruct the editor to highlight certain parts of text in a certain style.
Think: var1 is undeclared so KDevelop tells Kate to highlight var1 so it has squiggly red marks under the name. (akin to red squiggly marks under misspelled text in a word processor)

Think: KDevelop knows all classes within a project.  It can tell Kate to highlight all declaration of the form Class var; so Class is highlighted differently.  The same with method calls and attributes (currently statically highlighted through the Kate syntax defs which isn't too nice)
Comment 1 F Fracassi 2003-11-20 08:02:11 UTC
Full Ack. Three More Points:
1) Simple Wish:
 	- support the doxygen commands @ISSUE, @BUG like the @TODO.
	- make it work on the counterparts \ISSUE \BUG \TODO
2) Fix Makro usage:
	I sometimes use makros for komplex Debug output (Debug images) like this: 

#define VDBG(s) s

And then latter invoke it:

VDBG(
  Image dbgimg();
  ...
  dbgimg.save();
);

which is perfectly legal c++, but the Problems Reporter marks each of these invokations as wrong, thus cluttering the view.


3) Make it possible to rank the problems: 
   for example throug RMB click on a problem a small menu pops up which lets you give the problem a priority from 1 to 5 (3?, variable?) and perhaps an option for "hide this Problem"
The problems should then be sorted by their ranks first.
Comment 2 Amilcar do Carmo Lucas 2003-11-21 10:22:19 UTC
About comment #1 
We already support the doxygen commands @todo and \FIXME
OK, \FIXME is not and official Doxygen command but the cool thing about doxygen is that you can create your own commands and so we created the
\FIXME command for the KDevelop project.

Your 3) is very complicated to implement, we need to keep a list of "issues" ,their location, their priority and hide or not. Then we need to update the location when you change the text. That is tricky!!!
Comment 3 Daniel Franke 2004-04-27 18:00:16 UTC
Concerning priority levels:

An "easy" solution (without having to maintain a list of issues) would be something like this:

Instead of 
--
 @fixme Your-Issue-Here
--
One could introduce levels as in 
--
 @fixme ([1..5]) Your-Issue-Here
--
If the parser hits "@fixme" it could peek for "(n)", if found 'n' is the level, otherwise level will be defined (e.g. 3).

Doxygen will handle "(n)" as part of the description, so the levels will be included in the dox (@todo, @bug) as well (unsorted, though). 

Hiding of issues could be achieved by a threshold "Only show items with priority X or higher" - if you want to see a specific one, raise it's priority. (Doesn't make much sense in having a high-prior TODO and hiding it, does it?)
Comment 4 Jesse 2004-04-27 19:45:26 UTC
Would it be possible to split this off into a seperate wish?

The original wish deals only with enhancing the parser in order to report better, more meaningful errors and to bring up to a point were it would actually be useful in a real world context.

Without that, the 'priority' wish is worthless.  All you'd be able to do is assign priorities to errors of "error: expected semicolon but got x instead ..."  So how is one misplaced semi a higher prio than another ;)  Now if I can set that error's prio to low, while an error of "Unused var or parameter" is set to high (so they bubble up to the top), then that's fine.  But this wish only deals with getting the parser to that point.
Comment 5 Daniel Franke 2004-04-27 22:21:02 UTC
There is already another wish, more or less a subset of this one: #74066

I actually thought of priorities of @fixme, @bug, @todo ... @whatever, not of errors. An error is an error (a high priority task in itself), unused variables shouldn't be much more than warnings, and again I daresay, a warning is a warning, and I do not see much sense in prioritise warnings ?! 
Errors and Warnings are/will be reported by the parser on its own, fixme's and todo's are defined by the user - and the user may have a priority on each of them. 
In addition: in general, I try to get rid of errors as soon as possible, whereas, when I bother to add "@todo ...", I do NOT intend to do it right now,
therefore a ranking is useful only to items that will persist for a while ...
maybe this holds for other users also?!

To add user-defined keywords (and give a facility to rank them), I first thought of adding priorities to keywords, such as:
 * fixasap - hight prior
 * fixme - normal prior
 * fixsometime - low prior
but I didn't like that. 

To avoid to have to track each report-item behind the scenes (add/remove/change items) -which would exceed my capabilities- I came up with the thoughts described at comment #3 - to some extend it even allows to have your priorities in the dox as well, a very nice feature :) - on the other hand, if individual ranks are added, they have to be preserved, otherwise, each time the project is closed one'd loose any customization - but IF these ranked problems are saved - they have to be synced with the files. When doing so, one should have in mind that the user may have used VI to remove a line, add a @todo, remove others and so on ... (there's no need to preserve errors and warnings, of course). 

To summarize:
 * The original wish asks for parser enhancements - I can't do them ;)
 * comment #1 and wish #74066 ask for configureable keywords and priorities for problems - I may add the user-defined keywords, but priorities have to be thought over. 
Comment 6 Juan Medín 2004-11-30 15:37:33 UTC
The IntelliJ IDEA (4.5) IDE could be used as an (extremely advanced) code analyzer. Duplicated code, methods called with the same parameters, methods never invoked, variables never used, etc, etc, are all there. 
Comment 7 Andreas Pakulat 2008-06-29 16:58:26 UTC
the parser improvements should be part of the general language support in KDevelop4, so that they work for all languages at once. fixing the bug-title to be more specific.
Comment 8 Kevin Funk 2016-03-24 13:17:48 UTC
This is fixed, we're using the Clang backend now in KDevelop 5!

Regarding the last comment: IMO this should *not* be done in a language-agnostic way; the individual language plugins are responsible for this kind of issues.