problem reporter

[Sascha Cunz]

Hi Daniel,
> Hi all :)
>
> I just played with configureable keywords to the problem reporter (@bug,
> \issue, ...) when I realized that there is not only one problem reporter,
> but there currently are FOUR (ada, cpp, java, pascal) - naivly I took cpp
> for granted and hadn't had a look in the different directories before
> hacking away :(

I wasn't aware of 4 problem reporters, too. Silly issue; probably we should 
adress that.

> Giving the current language-support setup some more thougt:
> Each language defines its own config-page (which is reasonable) and its
> own problem reporter (which is not reasonable).
> What does a problem reporter do? It displays five pieces of information:
>  1. the type of the problem
>  2. the file were the problem occured
>  3. which line in previous file
>  4. which column in mentioned file
>  5. a description of the actual problem at hand
additional functions:
6) jump to the requested location in source as the user asks for it
7) maybe export to html ( or at least copy problems to clipboard )

exactly that's it. :)

> This should be true for any language: cpp, java, ruby, ...
It has nothing to do with the language. It's the parser recognizing problems 
doing it's work - and report about that.

> So, is there really need to implement it N-times? (There might be, I
> neither know all languages supported nor was I involved in development so
> far - there are obviously reasons why it was done this way, but I don't
> know them.)

No there is no real need to implement it N-Times. One is slightly enough.

> I now spent quite a while with this and I found two major obstacles:
>  * Either keywords are defined on a per-language base, or globally. In my
> eyes language based keywords would lack any sense since a @todo is a
> @todo, in ada, cpp, java, python, whatever. In addition, since they are
> so similar, the same code is duplicated N-times instead of re-used
> N-times. Therefore I conclude they should be defined globally ;)

These "todo", "bug", "fixme" and such are just additional features - but i'm 
pretty sure you already know that. :-) The "problem reporter" is misused in 
this case as something like a "grep" on all the sources... though, as the 
parser must walk the sources anyway, it can do that, too.

>  * How to seed the new keywords to the parser/lexer? That's more or less
> the same question I asked a few days before (no one replied so far).
> Shall a lexer access config files or not? Most likely it shall not. So 
> they have to be handed down from backgroundparser to driver to lexer ...
> (more or less this way)

Well, i suppose this has to be stored in the project DOM.

> But where is the problem? The cpp-parser was 
> hand written, ad, java and pascal are antlr-based. Therefore there isn't
> much of a unified interface.

No, there is no unique interface. It has to be designed.

> The advantage of an unified interface: any language could be provided with
> problem reporter functionality, even without a working parser, as long as
> the start-of-comment-sequence is known, e.g. for bash, the parser/lexer
> will skip anything, but '#', then (until end of line) the globally defined
> keywords will be searched and found "problems" will be reported to the
> (globally available) problem-reporter-part.

yeah, you are kind of right on this topic. though, i do not really know how 
the starting- and ending- points of comment sequences should be known without 
a parser?

However, while writing this reply, i was suddenly inspired by an idea: While 
with your approach we would still have to teach each and every parser to 
recognize those dynamic keywords inside a comment block. Same applies for 
doxygen parsing.
So i came to this: given the fact that any parser must determine where a 
comment starts and where it ends (and usually ignore anything inside that 
area), we could also do this:
When parser finds a comment it should emit a signal, giving filename, 
startingpoint, endingpoint (and posibly comment in plaintext ) as parameters.
Then a slot inside the problem reporter could be connected to that signal and 
parse it's additional keywords. OTOH, this way we could keep doxygen syntax 
parsing away from the language parsers...

roberto, jonas: can you comment on this?

> To those who know more about parsers and lexers: would it be possible to
> create a global interface to hand-written and antlr-based parsers, that
> might be used as a skeleton to implement a "keyword-only" problem reporter
> easily (as described above)?

see the above comment :)

> To those who have a deeper insight in part/plugin-handling: is it possible
> to release the problemreporter from its language dependency and use it as
> a part/plugin on its own? (Most likely it is _possible_, but is it also
> reasonable to do so?)

yes it is - and most likely it should be done. I think of an interface as 
i.e.:

class KDevProblemReporter
{
public:
  virtual void clearList() = 0;
  virtual void addProblem( const QString& fileName, int line,
    int column, const QString& text ) = 0;
};

class KDevCore
{
  //...
public:
  void setProblemReporter( KDevProblemReporter* reporter );
  KDevProblemReporter* problemReporter();
};

> Regards of an interested-user-who-still-doesn't-understand-
> too-much-of-how-kdevelop-works
everybody has to start anywhere :) Details come as you dig deeper and 
deeper :) Still nowadays i keep on finding pieces of code inside kdevelop, i 
never saw before...

Cheers Sascha