| [cdt-dev] Error Parsers behavior problems? |
|
While working on error parser support for the managed build system, I discovered that error parsers are not invoked in the order specified by the user. I asked one of my co-workers to investigate this, and here is what he found.
The routine processLine in ErrorParserManager.java invokes the error parsers (see below). The ErrorParserManager stores the error parsers in fErrorParsers, which is a HashMap. In processLine, the parsers are retrieved from the map using the keySet method. I believe this will return the parser in an undefined order. Empirical testing has verified that the order passed into the ErrorParserManager is correct, but the order in which they are invoked is not the order specified by the user.
For each error parser, processLine invokes the IErrorParser.processLine method. If the processLine method returns true, the method returns since this signifies that the current line has been handled. But none of the GCC error parsers ever return true! The VC++ error parser is the only built-in error parser that can return true.
Also, if processLine returns true, the code attempts to move the current error parser to the top of the list (but I'm not sure that it works..). I assume it is doing this for performance reasons - that is, the error parser that handled the error will more likely be able to handle the next error.
I have the following comments:
1. The fact that error parsers are not invoked in the order specified by the user seems like a bug that should be fixed.
2. The fact that the GCC error parsers always return false seems like a bug that should be fixed.
3. I don't believe that the ErrorParserManager should dynamically change the order of the error parser invocations. I think that if the user went to the effort of specifying an order, then they probably did it so that a particular error parser always get tried before another error parser. Dynamically changing the order defeats that.
If the group agrees, then we (Intel) can work on fixing this. I suggest that these changes are not important enough to try to get into 2.0, but we would try to submit a patch for the first 2.x update.
Comments?
Regards, Leo Treggiari Intel Corp.
===================================================================================
/** * Parses the input and try to generate error or warning markers */ private void processLine(String line) { if (fErrorParsers.size() == 0) return;
String[] parserIDs = new String[fErrorParsers.size()]; Iterator items = fErrorParsers.keySet().iterator(); for (int i = 0; items.hasNext(); i++) { parserIDs[i] = (String) items.next(); }
int top = parserIDs.length - 1; int i = top; do { IErrorParser[] parsers = (IErrorParser[]) fErrorParsers.get(parserIDs[i]); for (int j = 0; j < parsers.length; j++) { IErrorParser curr = parsers[j]; if (curr.processLine(line, this)) { if (i != top) { // move to top Object used = fErrorParsers.remove(parserIDs[i]); fErrorParsers.put(parserIDs[i], used); //savePreferences(); } return; } } i--; } while (i >= 0); }
|