Community
Participate
Working Groups
Especially having some visual indication whether some method call is an extension method or not, seems to be very interesting. Also the typical italics style for statics would be good.
Also the following should be colored like in JDT: - Field declaration and references - Annotations Everything which is applicable to Xbase in general should go into XbaseHighlightingCalcuator.
pushed first version to master. Xtend2Fields are not handled at the moment. I will wait until Sven changes Xtend2Field to JvmField. Please have a deeper look at the XbaseHighlightingCalculator. Resolving all this proxies seams to be very expensive. As Sebastian suggested the semantic highlighting should be invoked after linking has been done so that all proxies are already resolved.
May be deprecated members should be highlighted like in Java. (Strikethrough && black) Now we do handle Annotations and references to the same with only one highlightingConfigurationID. In Java they are handled with different IDs. Any thoughts?
Looks very good :-) The coloring of extension methods can go to Xbase as well, as we have extension method invocation there (e.g. IterableExtensions.*) The coloring for "Field" can be overloaded like you did with annotations, such that field reference are colored like that (in Xbase) and in addition field declarations in Xtend.
added support for fieldDeclaration in Xtend and fieldAccess in Xbase pushed to master.
Just a minor remark: This code is redundant: field.eClass().getEStructuralFeature(Xtend2Package.Literals.XTEND_FIELD__NAME.getName()) since Xtend2Package.Literals.XTEND_FIELD__NAME is already the EStructuralFeature.
As we do not have enough informations about the state of a JvmElement concerning deprecation I will mark this bug as fixed. Please reopen if there is another concept we should highlight.
We should check for @java.lang.Deprecated. 1) target of feature calls (Xbase) 2) cross references to JvmType (and subclasses) (Xbase) 3) declaration of XtendMember (only Xtend of course :-))
Will have time on Fr. I hope.
All the 3 different szenarios implemented. Only Bug 359409 should be resolve to see the reference to deprecated XtendMembers strikedthrough. Tests will follow tomorrow. What about @deprecated in JavaDoc? Is there a way to get that information?
(In reply to comment #10) > All the 3 different szenarios implemented. Only Bug 359409 should be resolve to > see the reference to deprecated XtendMembers strikedthrough. > Tests will follow tomorrow. Cool. > What about @deprecated in JavaDoc? Is there a way to get that information? I think the best we can do is something along these lines here: org.eclipse.emf.mwe2.language.ui.highlighting.SemanticHighlightingCalculator.isDeprecated(JvmAnnotationTarget) I think we should extract the code to DeprecationUtil (o.e.x.common.types.util).
That is what I already did. :-) But I like the idea of the DeprecationUtil. XtendAnnotationTarget is another thing we have to handle. As this is only an Xtend2 concept I will keep the implementation in org.eclipse.xtext.xtend2.ui.highlighting.XtendHighlightingCalculator and delegate to DeprecationUtil with the resolved JvmAnnotationType. May be we should have two methods in the DeprecationUtil. isDeprecated(JvmAnnotationTarget) isDeprecated(JvmAnnotationType) And delegate from the first to the second.
pushed version with attention to @Deprecated with tests. Added a test for szenario depending on bug 359409 also but commented it out.
Uncommented tests depending on resolve bug 359409. Now everything is fine. Feel free to reopen if there is anything to highlight.
Closing all bugs that were set to RESOLVED before Neon.0
