Infix scoping issue [message #1101723] |
Wed, 04 September 2013 17:57  |
Eclipse User |
|
|
|
Hi all,
Given a grammer like:
Entity :
...
('[' mappings+=Map ("," mappings+=Map)* ']')?
...
Map :
source=[Value|QualifiedName] '<->' target=[value|QualifiedName];
QualifiedName returns ecore::EString:
StringId ('::' StringId)*;
StringId returns ecore::EString:
STRING | ID;
With scope provider like:
def IScope scope_Map_source(Map map, EReference ref) {
return Scopes.scopeFor(map..[valid_sources].)
}
def IScope scope_Map_target(Map map, EReference ref) {
return Scopes.scopeFor(map...[valid_targets])
}
When trigerring code completion w/ cursor at beginning of a map entry, I would expect to get content completion for just the valid sources, without qualifiers. However, I actually seem to get both the source and the target completions, with the fully qualified names (which aren't actually legal in this context).
What's interesting is that the text does validate as I expect, it just doesn't return the right scope for the content completion provider.
Naturally, if I modify my grammar to provide a prefix or wrap, it works fine. (But I don't want that. )
Map :
'(' source=[Value|QualifiedName] '<->' target=[value|QualifiedName] ')';
Note that I have greatly simplified things. (For example, I'm actually creating xcore objects.)
Is this the expected behaviour? If so, any advice on how to modify the grammar or scope to make this work?
thanks!
Miles
|
|
|
|
|
|
Re: Infix scoping issue [message #1102433 is a reply to message #1102421] |
Thu, 05 September 2013 15:08   |
Eclipse User |
|
|
|
Christian,
That did the trick, thanks! I think despite the lengthy explanation (or perhaps because of its lengthiness!) on the xtext docs, I wasn't quite getting the order and context of dispatch. I was trying stuff like:
def IScope scope_Entity_mappings(Entity ctx, EReference ref) {
Which doesn't make much sense either, but the solution you proposed was hard to intuit, because it looks like you're passing in the container to the child and why would we want that? But it makes more sense if you think of the context like "this is the closest enclosing scope that we've constructed at this point"..
Because you have grammars where the order of the parsing really defines the scoping, and you (me, anyway) expect those things to be orthogonal.
cheers,
Miles
|
|
|
Re: Infix scoping issue [message #1105010 is a reply to message #1102433] |
Mon, 09 September 2013 04:13   |
Eclipse User |
|
|
|
The declarative scope provider with the reflective calls based on naming
conventions is not the most fortunate decision we ever made in Xtext.
Things might get clearer if you override
IScopeProvider.getScope(EObject, EReference) instead and do the
dispatching yourself. It's also a lot easier to debug.
Am 05.09.13 21:08, schrieb Miles Parker:
> Christian,
>
> That did the trick, thanks! I think despite the lengthy explanation (or
> perhaps because of its lengthiness!) on the xtext docs, I wasn't quite
> getting the order and context of dispatch. I was trying stuff like:
>
> def IScope scope_Entity_mappings(Entity ctx, EReference ref) {
>
> Which doesn't make much sense either, but the solution you proposed was
> hard to intuit, because it looks like you're passing in the container to
> the child and why would we want that? But it makes more sense if you
> think of the context like "this is the closest enclosing scope that
> we've constructed at this point"..
>
> Because you have grammars where the order of the parsing really defines
> the scoping, and you (me, anyway) expect those things to be orthogonal.
>
> cheers,
>
> Miles
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
Re: Infix scoping issue [message #1146513 is a reply to message #1105010] |
Sun, 20 October 2013 03:36  |
Eclipse User |
|
|
|
Dear All,
I need your favor or suggestion regarding migrate the xtext version from 1.0.1 to 2.3.0 in custom application.
I followed all following process for migrate the xtext version.
1. Delete the old plug-ins and update the latest plug-ins in target platform.
2. Update the Plug-in Dependencies and Import Statements.
3. Introduction of the Qualified Name.
4. Changes in the index and in find references.
5. Rewritten Node Model.
6. AutoEditStrategy.
7. Other Noteworthy API Changes
To consider the above steps, I started the work with Eclipse-4.2, Which has a xtext-2.3.0 dependency. Successfully I completed the all above steps and removed the compilation error.
Problem: After that I start the testing and getting below error Messages:
[XtextLinkingDiagnostic: null:6 Couldn't resolve reference to Material 'MPS_RECUR'.,
XtextLinkingDiagnostic: null:9 Couldn't resolve reference to Cstic 'NUM_OF_ALLOC'.,
XtextLinkingDiagnostic: null:15 Couldn't resolve reference to Cstic 'INSTANCE_NUM'.,
XtextLinkingDiagnostic: null:14 Couldn't resolve reference to Class 'ALLOC'.]
|
|
|
Powered by
FUDForum. Page generated in 0.07910 seconds