Community
Participate
Working Groups
If a resource has had a unresolved cross-ref when it was loaded, the serializer should be able to re-serialize that cross-ref using the node model information.
Created attachment 185639 [details] Test reproducing the error condition Attached a test.
check if this depends on bug 333976. It does, if the INode is not correctly identified for the cross reference's token.
I think this has been fixed in the meantime.
While debugging a quickfix situation in Xtext 2.4.3 I still see this bug: Model A Element B ref |X Element C ref X I have a quickfix for creating the unresolved element X, invoked at "|". The quickfix fails with "Could not serialize EObject via backtracking...". If I remove the second unresolved ref in Element C the quickfix works as desired. If s.t. has been fixed in this area, could you provide a pointer to the change so I can check why the fix doesn't help in my case? In my case failure starts at AssignmentFinder.findValidAssignmentsForCrossRef (where it calls crossRefSerializer.isValid()). Since isValid() answers false for the unresolved proxy, we end up with no result and I couldn't see anybody up the call chain gracefully handling this situation.
isValid() should only answer with false if no node from the NodeModel has been found for the cross reference. The node is required because it holds the textual representation of the cross reference as seen by the parser at the time of the last parse. Is it the case for you that no node has been found? see: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/plugins/org.eclipse.xtext/src/org/eclipse/xtext/serializer/tokens/CrossReferenceSerializer.java?id=v2.4.3
Hi Moritz, thanks for looking into this. Indeed node is null, and here is why: In this call stack: AssignmentFinder.findValidAssignmentsForCrossRef(EObject, Iterable<AbstractElement>, EObject, INode) line: 100 AssignmentFinder.findAssignmentsByValue(EObject, Iterable<AbstractElement>, Object, INode) line: 73 ContextFinder.findAssignedElements(EObject, EStructuralFeature, Iterable<AbstractElement>) line: 73 we're called from return assignmentFinder.findAssignmentsByValue(obj, candidates, value, null); Do you see the null, I'm seeing?
(In reply to Stephan Herrmann from comment #6) > we're called from > > return assignmentFinder.findAssignmentsByValue(obj, candidates, value, null); > > Do you see the null, I'm seeing? Should've said: this call is in ContextFinder.findAssignedElements(..) Is there a way I can avoid this call, or work around the null in some way?
I'm on it.
pushed a fix to gerrit: https://git.eclipse.org/r/#/c/24527/ As a workaround without upgrading/waiting for Xtext 2.6, you can subclass org.eclipse.xtext.serializer.sequencer.ContextFinder and bind your own implementation in the RuntimeModule. Your own implementation of ContextFinder would need to contain the changes from the commit I'm mentioning above.
fix merged in http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=69e45ea47c48369ff8333305a47b85f13aadfb70
Stephan, do you have a little spare time to verify this works? =)
(In reply to Stefan Oehme from comment #11) > Stephan, do you have a little spare time to verify this works? =) I do plan to try it soon (using the sub-classing approach from comment 9), I just need to squeeze it into a super busy schedule ... I'll let you know ... (after RC1 +0 things *should* calm down to some degree, I hope ...). Are we slipping any Xtext code freeze deadline these days?
The 2.6.0 release will be next Wednesday. In case there's still an issue here, it could be fixed in 2.6.1 (planned for early June).
I finally found the time to adopt the solution (following the recommendation in comment 9), and: Yes, it works! Thanks a lot, Moritz!
Thanks, Stephan.
