| Summary: | provide more warnings about code-problems like unused variables | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Jesse <jesse.y> |
| Component: | Language Support: CPP (old) | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | esigra |
| Priority: | NOR | ||
| Version: | 4.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 5.0.0 | |
| Sentry Crash Report: | |||
|
Description
Jesse
2003-11-19 22:24:17 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. 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. |