Community
Participate
Working Groups
If you have a DSL with Xbase integrated and you have a modelinferrer implemented like in the DomainModelExample the contentAssist does not show the inferred types before the resource gets saved. The linking work fine.
*** Bug 351027 has been marked as a duplicate of this bug. ***
not SR2
*** Bug 363799 has been marked as a duplicate of this bug. ***
We should address this issue. It's especially important since we now allow multiple classes per Xtend file.
The solution with the least impact on the lookup performance would be to use the IDirtyStateManager to explicitly query the dirty resources for JvmTypes.
The approach works basically. However, we'd need more user data on JvmTypes to decide about the icon and the filter criteria. Another issue is the shadowing of types. Consider the following scenario: === saved Xtend file === class MyNewType {} class MySecondType extends MyNewType {} === end === If I edit this file and add characters to the name of 'MyNewType', let's say 'MyNewFancyType' and use content assist afterwards on the extends clause, I'll still get a proposal for MyNewType since the java class is still available. After saving the file, the MyNewType class will be deleted and I get an error marker in the Xtend file. Not too nice. I think we'll have to filter the inferred class files from the scope of the currently edited file by means of the available trace information.
not Juno
The major part of this bug has already fixed, i.e. new types from dirty state get proposed. Also the editor in dirty state won't link against types removed in the editor but still existent on disk. We don'T want to do the outstanding bit described in comment #6, as the additional complexity and performance overhead is not worth it, given the very rare situation where this could cause an invalid proposal. I.e. we live with proposals of elements which exist on disk but will be deleted after save.
Requested via bug 522520. -M.
