Community
Participate
Working Groups
M5: I have two problems with AbstractOCLAnalyzer.simpleNameCS that are fixed by the following override that exploits a derived Environment that keeps track of the current CSTNode for use in error message contexts: @Override protected OCLExpression<EClassifier> simpleNameCS(SimpleNameCS simpleNameCS, Environment<EPackage, EClassifier, EOperation, EStructuralFeature, EEnumLiteral, EParameter, EObject, CallOperationAction, SendSignalAction, Constraint, EClass, EObject> env, OCLExpression<EClassifier> source) { if (source instanceof InvalidLiteralExp) return source; @SuppressWarnings("unchecked") E cstEnv = (E)env; CSTNode savedNode = cstEnv.setCSTNode(simpleNameCS); try { return super.simpleNameCS(simpleNameCS, env, source); } finally { cstEnv.setCSTNode(savedNode); } } Firstly (easily fixed): An expression such as a.b in which a is unrecognised correctly reports a as unrecognised, but then invokes simpleNameCS with an InvalidLiteralExp source, resulting in a further redundant unrecognised error for b. simpleNameCS (and perhaps other property/operation methods) should handle InvalidLiteralExp and avoid generating additional errors. Secondly (probably too much of an API ripple so not a separate Bugzilla): The direct use of env.lookup(String) prevents the error detection knowing the narrow source context of the String. It would be much better if env.lookup(SimpleNameCS) were used.
Yes, it is a problem that the parser attempts to parse the navigation on an incorrect source. The problem with OclInvalid is that it inherits features from all types, but we do not know what those are. And, of course, this use of OclInvalid is an MDT-ism anyway. I would rather remember that the source was unrecognized and so just ignore the navigation. Perhaps it would be more practical to remember that in the state-machine, rather than the SimpleNameCS? And yes the other is too late an API change (in addition to actually being one part of the environment API that actually follows the spec. :-)
For resolution of errors within QVT parses I introduced the trivial org.eclipse.gmt.umlx.unresolved model that provides a distinctive package, class, attribute, reference, enum, literal to terminate any reference which parsing/analysis cannot otherwise terminate. This ensures that the resulting ASTs are free from nulls, structurally valid and able to be unparsed with some utility. This has the very simple semantic that the first instantiation of any unresolved element is responsible for generating an error message, allowing the recipient of any unresolved element to safely propagate appropriate unresolved elements without further diagnosis. I found that I needed to convert a few OCL null/void/invalid returns to this policy in a pragmatic fashion. You might find something similar convenient for parsing/analysis failures leaving the standard bad OCL elements for the run-time failures for which they are defined. -- Is there any chance of a tryLookup(SimpleNameCS) that falls back to the specification-compatible lookup(String)?
Updated the AbstractOCLAnalyzer with a protocol for tracking which AST nodes are "error nodes." Employed this to avoid parsing navigation expressions on names that couldn't be resolved (as per the original bug description) and also to avoid parsing the bodies of iterator expressions in similar circumstances, as these body expressions generally depend on the source expression being parsed correctly. The OCLAnalyzer implements this new protocol, using its existing implementation of a history of AST nodes (with appropriate clean-up). I am not inclined (at least, not at this stage of the release) to introduce another metamodel, with objects that are intrinsically recognizable as special, which clients would now encounter. Also, it's too late in this release to add another operation to the Environment.Lookup interface that is implemented by clients. Please raise a new bug for the 1.3 release that explains in more detail why a SimpleNameCS-based lookup is required. Added JUnit tests to cover each of these two scenarios.
Fix available in HEAD: 1.2.0M7 (S200805061053).
Closing after over a year in verified state.
