Summary: | Front End Bug, if* should be a valid name pattern | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Laurie Hendren <hendren> |
Component: | Compiler | Assignee: | Adrian Colyer <adrian.colyer> |
Status: | REOPENED --- | QA Contact: | |
Severity: | trivial | ||
Priority: | P5 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | other | ||
Whiteboard: |
Description
Laurie Hendren
2004-05-09 12:48:08 EDT
Thanks for the simple and clear bug report. This is a valid bug; however, I'm marking it a P4 because it is a little bit hard to fix, and the problem is a minor one. If it was available, I'd mark this with a 1.3 milestone. The parser for name patterns goes to a lot of work to handle all of the standard java keywords as part of a name pattern. To do this, all of the keyword tokens that come out of the jdt's parser are converted to name tokens for our parser (in org.aspectj.weaver.patterns.PatternParser). The one exception to this is the if keyword which we currently use the jdt's grammar and parser to produce a single IfPseudoToken out of 'if' '(' <expr> ')'. Reusing the jdt's java parser (in shadows/org.eclipse.jdt.core/grammars/java_14.g) to parse the if expression is essential to our integration with the jdt. Fixing this bug will require carefully looking at our modified jdt grammar and parser + our custom PatternParser. The case that I think will be hardest to handle is something like, 'call(* *if(x))'. In this case, I don't see how our pseudo token stream code can tell the difference between the pcd 'if(x)' and the name pattern '*if'. This bug is fairly well localized to the two parsers and is the kind of bug that would be much likelier to be fixed with an attached patch. We're not going to get to this in AJ 1.5.0. Marking as "LATER" for consideration in 1.5.1 and future release planning. LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated. |