[cdt-dev] Re: [cdt-patch] Support for task tags, and more... (initial re

["Douglas Schaefer" <dschaefe@xxxxxxxxxx>]

Moving to cdt-dev.  cdt-patch should be for patches only...

Be very careful if we are going down this road, i.e., the CDT parser 
reporting errors to the user.  In the current scheme of things, the parser 
is a best effort and is not ready to handle this job.  There currently is 
no way to know exactly what the compiler will/won't except as valid code. 
Plus, you will need to deal with compiler errors coming back and 
correlating them with parser errors, an impossible task without having 
compiler specific information.

We have long term plans for this but we still need to get a good search 
engine out for 1.2.  It would probably be in our best interest to keep our 
focus on that.

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



"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