Bug 71046 - "Within" is treated as an identifier and not as a reserved word
Summary: "Within" is treated as an identifier and not as a reserved word
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: CME (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Peri Tarr CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-28 21:13 EDT by Juri Memmert CLA
Modified: 2004-08-04 15:57 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Juri Memmert CLA 2004-07-28 21:13:42 EDT
I want to find all calls to Cosmos.execute(..) such that the calls occur in
subclasses of class Concern?

The query I would use is:

call( * Cosmos.execute(..)) && within(sourceof(relationship extends(class *
,class Concern)))

This query results in a Syntax Error.

Below, you'll find Peri's response on the CME Users list in an abriged form:

Okay, I've looked into this, and it's a problem with our query parser--it's
treating "within" as an identifier instead of as a reserved word.  (This traces
back to a problem with our parser generator, which I'm in the process of replacing.)

<snip>

I'll do the interim fix, which is to disallow the use of AspectJ pointcut tokens
as identifiers, and then probably will be able to address this issue properly
when I've finished the move to the new parser generator.  (Sorry, this problem
probably arose as the result of a fix to a different problem in the parser
generator; I'm really surprised that the test suite didn't pick it up, because
we have test cases for it, but I'll update those as well, so this was a
particularly good catch--thanks.)

<snip>

Sorry it caused you problems, but fortunately, I think it's a 5-minute
workaround, so I may even have you running today :-).  Thanks for raising the issue!
Comment 1 Peri Tarr CLA 2004-08-04 15:57:07 EDT
Problem turns out to be that within() only is defined on named types and 
packages at present, as in AJ--you can't use general queries as parameters at 
present, and you were trying to use it (entirely reasonably) with a query as a 
parameter.  I think there's a deadly parser ambiguity in the current parser 
generator if I change it to accept any query as a parameter, but I will check.