Error specification doesn't support index for multi-valued features

[lwrage]

In a DSL I have a mechanism to pass arguments to a function. Each argument must be a variable, so in my metamodel the argument list consists of a list of references to variable declarations. I use Xsemantics to check if the type of the arguments matches the parameter type in the function declaration. However, if there is an error I have no way to associate it with the specific argument because I cannot pass an index to the error specification. As a result the whole argument list is underlined in the editor and not just the offending variable name inside the list.

[LorenzoBettini]

Hi using "source" and "feature" in the error specification is not enough? If you pass the specific argument to the error specification, this won't work?

[lwrage]

The argument is just a cross reference to a variable declaration so there's no EObject I could pass as the source. If I pass the referenced object, then the variable declaration is marked with an error, but that's not what I need. In Xtext an index can be passed to ValidationMessageAcceptor.acceptError to select the position in a multi-valued feature that has an error. Currently XsemanticsValidatorErrorGenerator.error passes -1 as the index which tells ValidationMessageAcceptor.acceptError to ignore the index.

[LorenzoBettini]

OK, I see. So this is a feature enhancement I'll work on as soon as possible :)

[SimonCockx]

@LorenzoBettini I've actually had a similar issue. Is it possible to report a variable amount of errors with a validation rule?

To take the example of @lwrage, suppose we defined a function syntax like doTheThing(x1, x2, x3), and we want to create a validation rule that checks whether x1, x2 and x3 are of the right type. In general, for a function F(x1, ..., xn) with n arguments, I would like to define a validation rule that can raise up to n errors. Is this possible in XSemantics?

[LorenzoBettini]

IIRC it is currently not possible... have you tried that yourself? I guess that a rule exits as soon as an error is raised.

[SimonCockx]

@LorenzoBettini Yes, I noticed it indeed ends at the first error it encounters. That's a pickle... I have two cases where I need this: function calls and typed records. I guess that for now I will implement their validation manually in the validator class then.

I'm just thinking aloud here: it would probably mean a big change in the code to support multiple errors, but would this be supported, I guess a posibility would be to allow stand-alone error "message" without the keyword fail in front, e.g.,

fail error "some message" // -> this stops the rule's execution

error "some message" // -> this continues the rule's execution

Should I raise a seperate ticket?