Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] GNU Error Parsers rewriten

Hi,

if you're rewriting the gnu error parser code please consider reworking more parts of the error parser framework as it is currently hard to extend and it the implementation is also rather resource consuming.

Lets start with the IErrorParser interface:

public interface IErrorParser {
    boolean processLine(String line, ErrorParserManager eoParser);
}

The ErrorParserManager is a concreate class and should be replaced with one or several interfaces to make it easier to run unit test of an error parser.

The resonsiblities of the ErrorParserManager and an error parser is not clear. The parsers have to use methods in the ErrorParserManager such as findFilePath(), isConflictingName(), generateMarker() and findFilePath(). I suggest moving this kind of logic to a class implementing a new interface IRoblemReporter (?) that the error parser calls for reporting an error on a path (string , IPath or URL) that is a let the new component worry about the eclipse Resource system.

As the parser might be interested in previously processed lines I also suggest adding an "IInputBuffer" interface.

The new error parser interface would then look something like:

public interface IErrorParser2
{
    /**
     * Parses one line.
     *
     * @param currentLine
     *            the current line to be parsed   
     */
    void parse(String currentLine, String previousLine);

    /**
     * Initialize implementor with a callback interfaces
     *
     * @param inputBuffer
     *            interface for working with multiple lines (previous line, scratch buffer? etc)
     * @param problemReporter
     *            interface for reporting problems.
     */
    void initialize(IInputBuffer inputBuffer, IProblemReporter problemReporter);
}

Also consider running the error parsing framework in a profiler and reduce the number of objects created. I think that the checkline() method in the ErrorParserManager is one candidate for optimization.

Best Regards,
Per


On 1/6/06, Doug Schaefer <DSchaefer@xxxxxxx> wrote:

Hey gang,

 

While solving a number of bugs which reported the error parsers reporting false errors, I have rewritten the make, gcc and gnu ld error parsers to use regular expressions. Please report any odd error parser behaviour in bugzilla. I am especially concerned about false and missing problems in the problems view, as well as bad performance since the regex performance is a bit of a mystery (e.g. don't do ".*([^/\\]*ld)(.exe)?:" …)

 

I have only done this in HEAD for CDT 3.1. I'm too afraid of breaking the error parsers for 3.0.2.

 

Thanks,

Doug Schaefer, QNX Software Systems

Eclipse CDT Project Lead, http://cdtdoug.blogspot.com

 

 


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




Back to the top