| Summary: | [Xbase] XExpressionHelper.isLiteral(XExpression) doesn't support extensions | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Stephane Barbey <stephane> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jan, sebastian.zarnekow, sven.efftinge |
| Version: | unspecified | Flags: | sven.efftinge:
indigo+
|
| Target Milestone: | SR1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Workaround: inject one's XExpressionHelper instead of the standard one. Maybe we should introduce a marker interface for literal classes? The default implementation checks only types from XbasePackage Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |
Build Identifier: 20110615-0604 The implementation of org.eclipse.xtext.xbase.util.XExpressionHelper.isLiteral(XExpression) is based on the value yielded by expr.eClass().getClassifierID(). This value is unique within an EPackage, but not within a language: I have e.g. a language that extends XBase and adds an XGuardExpression returns xbase::XExpression : ...; that gets the classifier ID 13, i.e. the same as XSTRING_LITERAL in Xbase. As a consequence, this rule is considered as being a Literal by XExpressionHelper. This can have various consequences depending on the usage of this helper function. In my particular case, I have introduced XGuardExpression as part of a XBlockExpression, and thus the validation rule @Check public void checkInnerExpressions(XBlockExpression block) { for (int i = 0; i < block.getExpressions().size() - 1; ++i) { XExpression expr = block.getExpressions().get(i); if (expressionHelper.isLiteral(expr)) { error("Literals can only appear as the last element of a block expression", expr, null, ValidationMessageAcceptor.INSIGNIFICANT_INDEX, INVALID_INNER_EXPRESSION); } } } fails each time it encounters a XGuardExpression. Reproducible: Always