Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Re: Rejected Re: Fixes for PR 39476, 39477 + some cleanup

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.  


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

06/30/2003 07:02 PM

Please respond to

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
   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
>+import org.eclipse.cdt.core.model.ITranslationUnit;
>+        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)?

cdt-dev mailing list

Back to the top