Community
Participate
Working Groups
W/the work Andrew is doing on adding IProblem annotations to the editor, we need to make IProblem internationalizable.
I think most of the IProblem strings are already externalized in internal.core.parser/ParserMessages.properties. I do have other strings that need to be externalized though
> W/the work Andrew is doing on adding IProblem annotations to the editor, we > need to make IProblem internationalizable. Sigh .. it is already started and can be enable(see work in progress). Please see PR 61603. I did not commit the rest yet. Since any way the parser does not return any error, i.e. I got a second patch removeing the reparse(A la JDT). Since C parsing is much more cumbersome then Java.
Andrew's work is not the same as what you are doing ... Andrew's work comes from the Indexer and serves as a mechanism for users to see if there are semantic problems coming from the parse. You will not get these type of answers from QUICK_PARSE. Perhaps we should have a quick phone call this afternoon to make sure we are on the same page?
> Perhaps we should have a quick phone call this afternoon to make sure we are > on the same page? Sure sounds cool. But if you tell me that we are not overlapping, that's enough for me.
My stuff is putting IMarkers on the resources as we index them. Currently I'm only marking preprocessor errors (includes etc), but I think the eventual idea was to have like the JDT compiler options to ignore or mark different problems as warnings/errors. The is potential overlap using structural parse if you open a file that has been marked with indexer errors, then once alain's code is triggered you will have both the index marking and the annotation marking. Using markers mean the problems show up in the problems view and (I think) allow for quick fixes in the future. I don't think the TranslationUnitAnnotationModel would support that.
> The is potential overlap using structural parse if you open a file that has > been marked with indexer errors, then once alain's code is triggered you will > have both the index marking and the annotation marking. For now, I do not generate IMarker on the annotation column of the CEditor but only squiggly lines were the problem is trigger. I reserved the IMarkers for "QuickFixes" i.e. problem that I know I can provide a fix for .... Obviously we will not have this tomorrow (next generation of the parser 8-). The Annotation/Marker is actually transient meaning once you close the Editor they disappear ... AND they work on the working copy of the CEditor i.e. they piggy pack on the reconciler thread to generate errors as the user is typing. Well .. it is not exactly like that, the code was lifted from JDT where they do a full reparse to get the IProblems(see CompilationUnitProblemFinder). This will be to expensive for the CDT, I'm planning to get rid of the TranslationUnitProblemFinder to reuse the same parse pass as the outliner. For now if you enable this, only scanner problems will show as squiggly underlines: #iffff #endif Enable in C/C++ working in progress.
Strings have been externalized, see bug 43014 for any details regarding the reporting of indexer problems.
