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)
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.
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!!!
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?)
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.
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.
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.
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.
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.