|
Re: Indexing/Linking order problem [message #1753004 is a reply to message #1752994] |
Wed, 01 February 2017 03:58 |
|
Xtext does the thing in two phases
(1) indexing
(2) linking
The reason for that is e.g. Performance
So you should not access scopes in your name provider and or resource description strategy
Can you elaborate more on your use cases to find a solution
Eg
Use node module to fill the user data
Make the user data lazy and access it after indexing only
But therefore we need to know what kind of information you need and when you need it
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
|
Re: Indexing/Linking order problem [message #1753085 is a reply to message #1753005] |
Wed, 01 February 2017 18:13 |
Dan Goldstein Messages: 4 Registered: January 2017 |
Junior Member |
|
|
Thanks for the fast reply, Christian!
I do not access scopes in my name provider (I use the default one) nor in my resource description strategy (default plus one simple instanceof check). My ScopeProvider extends DelegatingScopeProvider, not ImportedNamespaceAwareLocalScopeProvider. Overall, my project setup resembles the SmallJava example in the book "Implementing Domain Specific Languages with Xtext and Xtend". It is a more complex DSL though - a general purpose language somewhat similar to Xtend, with support for C++ as an output language. I don't yet add any extra data to the index, though I'd like to figure out how to soon so I can support efficient cross-file checking of function overloads/specializations.
Breakpointing both my TestDSLScopeProvider.getScope AND my TestDSLResourceDescriptionStrategy.createEObjectDescriptions, when I paste a bunch of code into eclipse I see the getScope being called FIRST, with the following call stack:
TestDSLScopeProvider.xtend line: 379
DefaultLinkingService.getScope(EObject, EReference) line: 59
DefaultLinkingService.getLinkedObjects(EObject, EReference, INode) line: 120
LazyLinkingResource.getEObject(String, Triple<EObject,EReference,INode>) line: 247
LazyLinkingResource.getEObject(String) line: 222
LazyLinkingResource.doResolveLazyCrossReference(InternalEObject, EStructuralFeature) line: 189
LazyLinkingResource.resolveLazyCrossReference(InternalEObject, EStructuralFeature) line: 148
LazyLinkingResource.resolveLazyCrossReferences(CancelIndicator) line: 134
EcoreUtil2.resolveLazyCrossReferences(Resource, CancelIndicator) line: 498
XtextDocumentReconcileStrategy.postParse(XtextResource, IProgressMonitor) line: 175
XtextDocumentReconcileStrategy.doReconcile(IRegion) line: 153
XtextDocumentReconcileStrategy.reconcile(IRegion) line: 67
XtextReconciler.doRun(XtextResource, IProgressMonitor) line: 449
XtextReconciler.access$3(XtextReconciler, XtextResource, IProgressMonitor) line: 429
XtextReconciler$1.process(XtextResource) line: 363
XtextReconciler$1.process(Object) line: 1
XtextReconciler$1(IUnitOfWork$Void<T>).exec(T) line: 37
OutdatedStateManager.xtend line: 71
XtextDocument$XtextDocumentLocker.modify(IUnitOfWork<T,XtextResource>) line: 428
XtextDocument.internalModify(IUnitOfWork<T,XtextResource>) line: 162
XtextReconciler.run(IProgressMonitor) line: 360
Worker.run() line: 55
Only after all the scoping completes do I see my ResourceDescriptionProvider being called:
TestDSLResouceDescriptionStrategy.xtend line: 27
DefaultResourceDescription.computeExportedObjects() line: 89
DefaultResourceDescription$4.get() line: 179
DefaultResourceDescription$4.get() line: 173
OnChangeEvictingCache.get(Object, Resource, Provider<T>) line: 77
DefaultResourceDescription.getLookUp() line: 173
DefaultResourceDescription(AbstractResourceDescription).getExportedObjects() line: 35
DefaultResourceDescriptionDelta.internalHasChanges() line: 68
DefaultResourceDescriptionDelta.haveEObjectDescriptionsChanged() line: 58
DirtyStateEditorSupport.haveEObjectDescriptionsChanged(IResourceDescription, IResourceDescription$Manager) line: 623
DirtyStateEditorSupport.announceDirtyState(XtextResource) line: 533
XtextDocumentReconcileStrategy.postParse(XtextResource, IProgressMonitor) line: 179
XtextDocumentReconcileStrategy.doReconcile(IRegion) line: 153
XtextDocumentReconcileStrategy.reconcile(IRegion) line: 67
XtextReconciler.doRun(XtextResource, IProgressMonitor) line: 449
XtextReconciler.access$3(XtextReconciler, XtextResource, IProgressMonitor) line: 429
XtextReconciler$1.process(XtextResource) line: 363
XtextReconciler$1.process(Object) line: 1
XtextReconciler$1(IUnitOfWork$Void<T>).exec(T) line: 37
OutdatedStateManager.xtend line: 71
XtextDocument$XtextDocumentLocker.modify(IUnitOfWork<T,XtextResource>) line: 428
XtextDocument.internalModify(IUnitOfWork<T,XtextResource>) line: 162
XtextReconciler.run(IProgressMonitor) line: 360
Worker.run() line: 55
As far as I can tell, that means that Xtext is doing linking BEFORE indexing in this case when I paste code into the file, inside of its postParse method first calling resolveLazyCrossReferences and then announceDirtyState. I suppose it's possible that my implementation for some value calculated along the way is somehow forcing scoping to be done early, but I don't see how. Maybe you have ideas of some other places I might be accessing scope related info 'too early' or how I could debug to find out?
I do have a temporary workaround, where I just lookup stuff in the file itself if I detect that it's local to that file, but it seems wrong to have to do so. Maybe I am doing something else wrong or there is a subtle bug in xtext. This is the code for what I'm doing as a workaround:
def getStructForFullyQualifiedName(EObject context, String name) {
val desc = context.getVisibleStructDescriptions.findFirst[qualifiedName.toString == name && EClass == TestDSLPackage::eINSTANCE.XStruct]
if (desc == null || context.eResource.URI.trimFragment == desc.EObjectURI.trimFragment) {
// find it in the context object's containing file instead of the index
var containingFile = context.containingFile;
var rv2 = containingFile.defns.findFirst[it.name==name && it.eClass == TestDSLPackage::eINSTANCE.XStruct]
return rv2 as XStruct;
}
var o = desc.EObjectOrProxy
if (o.eIsProxy)
o = context.eResource.resourceSet.getEObject(desc.EObjectURI, true)
o as XStruct
}
|
|
|
|
|
|
|
Re: Indexing/Linking order problem [message #1753099 is a reply to message #1753098] |
Wed, 01 February 2017 20:12 |
|
yes but i dont understand and what i try to ask/tell you.
the local file editing (e.g. scoping) shall not rely on index, since the eobejctdescriptions are created not by the indexer but by ImportedNamespaceAwareLocalScopeProvider
=> what exactly do you query from the index and where do you do it
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
|
|
|
Powered by
FUDForum. Page generated in 0.03176 seconds