| Content assist strangely behaving in relation to scoping [message #1015958] |
Mon, 04 March 2013 12:17  |
 Victor Noël
Messages: 112
Registered: June 2010 |
Senior Member |
|
|
Hi,
Following the thread http://www.eclipse.org/forums/index.php/t/457539/ and my own problems with content assist and scoping, I open a new one because I think the problem is different (but maybe link to lazy instantiation...).
So, I have this language:
https://anon:anon@wwwsecu.irit.fr/hg/SMAC/victor-noel-phd/may/may-xtext2/
There is an ecore model, and then an xtext language built on top of it.
The point of interest here is the language description in xtext (in fr.irit.smac.may.speadl), I put some comments when there is things that could seem strange. There is some french comments but they are unimportant.
I'm using xtext 2.4M5.
I only committed the code I changed, for the rest one need to execute both mwe2 workflow in fr.irit.smac.may.spead then fr.irit.smac.may.speadl.
So I defined different scope methods in SpeADLDeclarativeScopeProvider (which is called by SpeADLScopeProvider without any problem) for my different rules to produce PortReference elements.
The problem is that while this scope is used correctly for validation, when doing content assist, the getScope method is called directly starting from the Binding context, without entering the {Required,PartProvided,ThisProvidedOrRequired}PortReference Eclasses, even though they do exist and that I forced the instantiation using an action.
Thus for content assist, the scope for my PortReference is never called.
Another strange thing is that only the predicate scope_PortReference_port is used, and never the predicate scope_{Required,PartProvided,ThisProvidedOrRequired}PortReference_port ... I don't know if it is normal.
Here is an example to play with it:
namespace Test {
ecosystem TestE1 {
provides test: String = a.test
requires test2: String
part a: TestE2 {
bind test4 to a.test3
bind test to a.test
bind test2 to this.test2
}
}
ecosystem TestE2 {
provides test3: String = this.test3
requires test4: String
}
}
I hope this is clear :)
Thank you
|
|
|
| Re: Content assist strangely behaving in relation to scoping [message #1016071 is a reply to message #1015958] |
Mon, 04 March 2013 19:51  |
|
HI,
i cannot watch the grammar (get 500 http error)
never the less. if you have a look at org.eclipse.xtext.scoping.impl.AbstractDeclarativeScopeProvider.getPredicate(EObject, EReference)
you can see that the method name has nothing todo with the grammar rules but with the (maybe) derived metamodel
scope_<Class that Containstheref>_refname.
since xtext moves stuff up to superclasses when deriving the metamodel it may actually be the superclass. in your case PortReference
another problem is that Xtext create objects lazy on the first assignment so the context may be a parent object if the referene is the first thing in your rule.
without knowing your exact grammar it is hard to tell what best to do. maybe using a simple action ({Type})can help
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
| Re: Content assist strangely behaving in relation to scoping [message #1016076 is a reply to message #1016071] |
Mon, 04 March 2013 20:53 |
|
Hi,
the server seems to be working now.
it seems that the simple actions need a keyword to be executed.
in your case i see 2 options.
(1) change the grammar and move the bind keyword down to the RequiredPortReference
(2) simply change the scoping (context seem to come from outside in your case anyway.
protected IScope scope_PortReference_port(fr.irit.smac.may.spead.Binding context, EReference ref) {
return Scopes.scopeFor(getType((ComponentPart)context.eContainer()).getRequires());
}
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
| Re: Content assist strangely behaving in relation to scoping [message #1016186 is a reply to message #1016132] |
Tue, 05 March 2013 11:56 |
Victor Noël
Messages: 112
Registered: June 2010 |
Senior Member |
|
|
Well, I was happy too quickly, there is still something strange...
For the rules named PartProvidedPortReference and ThisProvidedOrRequiredPortReference, normally, for the feature "port", the scope should propose elements found based on the declaringComponent feature, but while it does so with validation, it does not with contentassist...
If I enter the first character of a port name, then it uses the correct scope, but I don't see how lazy evaluation is the problem as we are in the middle of a rule...
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04831 seconds
] 
Search
Help
Register
Login
Home
