Re: [cdt-dev] Re: Rejected Re: Fixes for PR 39476, 39477 + some cleanup

[John Camelon <jcamelon@xxxxxxxxxx>]

My mistake about ITranslationUnitResult,
all apologies, however the point remains the same.  ParserFactory
exists to instantiate Parser implementations of public interfaces, without
any external core dependencies (like C-Model).  

Please do not get me wrong, Victor,
I am very interested in seeing how this feature is going to turn out.  I
am sure that as the parser matures, we would be able to do a good integration
with the GNU compiler through the error parser to correlate build errors
and parse errors.  Without the correlation, this feature doesn't work
too well, as the user will just receive tons of task-list noise; without
the parser working nearly perfectly, same thing.  The first item is
currently not designed, and the second work item will take some time and
testing to get there.  Thus there is no need at this time to force
other core components (C-Model, Indexer) to use your interfaces.  In
fact, until we have done a simple search for class references (which is
one of our milestones) I would say that it is counter productive for 1.2.
 

If you wish to continue working on this,
I would suggest that you try and solve the great unknown CProblemReconciler
and move as much of the work as you can to another package; in there, you
can implement a parser callback which would allow you to validate the use
case on GNU (for example).  Once we have proof-of-concept, then we
can decide where it fits into the big picture.  

JohnC

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

06/30/2003 07:02 PM

Please respond to
cdt-dev@xxxxxxxxxxx

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] Re: Rejected Re: Fixes for PR 39476, 39477 + some cleanup

    See below...

----- Original Message ----- 
From: John Camelon
To: cdt-dev@xxxxxxxxxxx
Sent: Tuesday, July 01, 2003 12:03 AM
Subject: [cdt-dev] Re: Rejected Re: Fixes for PR 39476, 39477 + some cleanup

> As of right now, the sentiment on the list (at least from Thomas,
Doug and
myself) is
> that hooking this up to the parser right now is problematic, as more
likely than not,
> we will either confuse the user with invalid errors or flood them
with
duplicate errors.
>
> If the interface is just implemented as stubs, it serves only to clutter
code up on
> a feature that is going to have significant development & churn
over the
next few months.
> If the interface was to be implemented, its another thing that we
will
need to test and
> validate architecturally.
>
> I would love to have a feature like this working as smoothly as what
is in
the JDT (w/quick
> fixes et al) but its going to take us some time to get there, that's
all.
If you reorganize the
> packages a bit, removing as many dependencies as you can to-and-from
the
parser, indexer and
> C-Model, I'd feel better about it.

    Now I am confused. What dependencies are you not happy about?
Can you be
more specific? References to task problems from the indexer? It seems it
is
the only place where parse-them-all happens... It can be left as it is,
in
CModelBuilder only, but then tasks will only be collected from the active
editor.
    Or is it a reference to ITranslationUnit from ParserFactory
(see below)?
Anything else?

>> And ParserFactory doesn't produce any CModel elements in this
patch, does
it?
>
><snip>
>+import org.eclipse.cdt.core.model.ITranslationUnit;
><snip>
>+        public static ITranslationResult createTranslationResult(
ITranslationUnit tu )
>+        {
>+                return new
TranslationResult(tu);
>+        }

TranslationResult != TranslationUnit. TranslationResult is not a CModel
element, if that's what you meant. Or do you mean it shouldn't even use
any
CModel package references (ITranslationUnit)?

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