Community
Participate
Working Groups
We have Check rules that define a context like so context MyType#isFeature but when a diagnostic is created from that rule the whole MyType element is highlighted, which is undesirable and seems to contradict the intention behind the context specification. From debugging it seems that the implementation of org.eclipse.xtext.validation.DiagnosticConverterImpl.resolveStructuralFeature(EObject, Object) is simply lacking s.t. like if (feature instanceof String) return ele.eClass().getEStructuralFeature((String)feature); In my experiments in the debugger this produced the exact expected result. BTW: the migration guides in the user doc seem to lack any mentioning of Check based validation, but I may have been looking in the wrong places as I didn't find any reference to (new) extension points, like org.eclipse.xtend.typesystem.emf.checks.
Since the old check language is deprecated, the contract of Diagnostic#getData does not describe Strings as valid entries in the data list and a custom implementation of the DiagnosticConverter serves as a nice workaround, I close this as won't fix. Please reopen, if I missed something.
(In reply to comment #1) > Since the old check language is deprecated, Deprecated as in: you personally no longer recommend its use, or deprecated as in: all documentation has been updated to alert the user that this language will be discontinued, and providing help for migrating to a suitable replacement? I'm asking because I see neither the alert nor the migration hints. > the contract of Diagnostic#getData > does not describe Strings as valid entries in the data list It says "arbitrary associated list of data", which is not very restrictive.. OTOH, a method called "resolveStructuralFeature" which does nothing but a guarded cast looks like some kind of bug to me. > and a custom > implementation of the DiagnosticConverter serves as a nice workaround, I disagree, the implementation of a custom DiagnosticConverter might be simple, but without internal knowledge it is *not* trivial to setup the configuration to use the new class. > I close > this as won't fix. Please reopen, if I missed something. I won't fight for it, because I'm already using the solution outlined in comment 0 (using an OT/Equinox plug-in). I still don't understand why you don't want it, but that's your choice.
Check is slow hard to debug and inflexible in terms of reporting problems and where they were. Moreover it drags the runtime dependencies form Xpand in. We think even the Java-based API is much nicer, because it is more flexible, easier to debug and has much nicer tooling. However using Xtend 2 is a straight forward alternative for people who dislike the verbose nature of Java. You are right in that we missed to list the deprecation of Check in the migration document. It should have been in 0.7 -> 1.0 already.
Closing all bugs that were set to RESOLVED before Neon.0
