Applied [HEAD] Re: [cdt-patch] Support for task tags, and more... (initi

[John Camelon <jcamelon@xxxxxxxxxx>]

I'm going to apply the patch although
I think that perhaps we should decide architecturally how the parser ties
into this feature before you continue on too much further, Victor.  

Dual errors are not the end of the world
... sometimes in the JDT you'll see the same compile error coming up as
2 tasks (for some errors, not all).  
The issues as I see them are as follows:


  a) what is the cost of reconciling
all of these errors?
  b) are all parsing clients responsible
for pushing these errors to the reconciler?  do they have discretion
as to what errors they think are task-worthy? 
  c) how do we make sure that Parser
bugs which manifest as IProblem do not show up in the user's task bar?

Alain & Douglas I would welcome
your opinions.  

JohnC

"Victor Mozgin" <vic_mozgin@xxxxxxxxxxx>
Sent by: cdt-patch-admin@xxxxxxxxxxx

06/27/2003 02:03 PM

Please respond to
cdt-patch@xxxxxxxxxxx

To	<cdt-patch@xxxxxxxxxxx>
cc
Subject	Re: [cdt-patch] Support for task tags, and more... (initial revision)

        Currently, all IProblems
are collected into a single
TranslationResult during translation, and then this object is converted
into
persistent problem markers on IResources. For initial task tags support
that
is enough. However, for general problem reporting we need to do much more.
    Even if CModel doesn't (and never will) do a full parse,
it can still
report certain problems, like task tags, missing include files, wrong
declarations etc. Then indexer will be doing a full parse, and will be
able
to find more problems. In (distant) future, there might be some kind of
C/C++ analyzer that will report semantic errors. Plus we have build errors.
To cope with all that, we need careful categorization/marking of problems,
so we can detect problems as the same even if they are reported from several
places. Then we'll need something like a problem reconciler (problems with
problem markers): called with a set of reported problems (which doesn't
cover _all_ problems), it will detect which problems are the same, which
are
obsolete, inconclusive, etc. So each component that can produce problems,
will accumulate them in TranslationResult, then pass it to this reconciler
(which implements ITranslationResultRequestor). Well, that's one of possible
ways to implement general problem reporting. As it is now, CModelBuilder
works as a reconciler for task problems ;)
    Speaking about build problems, I think it would be a good
idea to merge
all problems into IProblem, as it should simplify
maintenance/localization/etc. I am not sure if it will be possible to
eliminate creation of (semantically) duplicate translation/build problems
in
all cases: it might require a lot of AI from the problem reconciler...

                /Vic


----- Original Message ----- 
From: John Camelon
To: cdt-patch@xxxxxxxxxxx
Sent: Friday, June 27, 2003 4:00 PM
Subject: Re: [cdt-patch] Support for task tags, and more... (initial
revision)

Cool Victor!  Thanks for getting IProblem started, I've been dreading
that.
I have no problem with the work done on the Parser side, I'll let Alain
comment on the C-Model/UI portion and leave it in his hands to apply the
patch.

I do have a question about the overall architecture to support this : is
it
the indexer that is expected to update the TranslationUnit problem list?
The CModel will never do a full parse and thus will not catch any problems
inside of method bodies ... but the indexer is doing the full parse on
all
translation unit/build property changes.

JohnC


----- Original Message ----- 
From: John Camelon
To: cdt-patch@xxxxxxxxxxx
Sent: Friday, June 27, 2003 6:52 PM
Subject: Re: [cdt-patch] Support for task tags, and more... (initial
revision)



Also ... how does this correspond to real compiler build errors in the
task
view?  Are we to consolidate build errors w/our own IProblems so that
the
user does not receive 2 tasks for every real problem?

JohnC
_______________________________________________
cdt-patch mailing list
cdt-patch@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-patch