Bugzilla – Full Text Bug Listing
| Summary: | AssertionError in AcceleoEvaluationEnvironment.mostSpecificTemplate | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | laurent.goubet |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
Ed, This comment indicates that ... I do not know how to get there :). Could you provide us with a sample of something that fails like that? It was an optional element that was undefined. a.b.partialName() so the old OCL gave you a null as the 'object' for a.b and Acceleo couldn't decide which polymorphic template to apply for null. I think you just want to add an extra if-null, generate is-null error message, else assertion to ease debugging so that the Acceleo rather rthan Java backtrace occurs. Perhaps you can replace the assertion too so that the 'impossible' case gives an Acceleo backtrace. Ed, If I read this correctly, this means that the "type" of the argument of a template call is null; not its actual value. Which means that either "((EObject)arg).eClass()" or "arg.getClass()" is null... This sounds extremely fishy to me. I'll change the "assert false" into an AcceleoException in order to have a meaningful stack trace ... but this use case will fail anyway unless I can understand how to get there with a null argument type. My guess is that you were using one of the 3.2 versions where the builder once again a) behaved incorrectly or b) didn't behave at all -_-. These builder issues should be fixed now, but we really encountered a lot of problems with it. (In reply to comment #3) > Ed, If I read this correctly, this means that the "type" of the argument of a > template call is null; not its actual value. Which means that either > "((EObject)arg).eClass()" or "arg.getClass()" is null... This sounds extremely > fishy to me. Indeed it is. One of the delights of the legacy code is the vagueness between OCL-undefined, OCL-null, OCL-invalid, NullLiteralExp, InvalidLiteralExp, Java-null, Java-exception. Axel's changes eliminated some Java-null as OCL-null but clearly not all. The new code always has NullValue for OCL-null, and either InvalidValue for OCL-invalid when it needs to be accessed or Java-exception for OCL-invalid when just propagating. The problem is that a Java-null is being used loosely as the original OCL-undefined, which was ambiguously OCL-null or OCL-invalid. In this case the Java-null is an OCL-null whose type conforms to everything (except OclInvalid). So for a Java-null argument, Acceleo should look first for an exact OclVoid match and if that is missing look for all possible matches (except OclInvalid) reporting an ambiguity if more than one. (In reply to comment #4) > The problem is that a Java-null is being used loosely as the original > OCL-undefined, which was ambiguously OCL-null or OCL-invalid. In this case the > Java-null is an OCL-null whose type conforms to everything (except OclInvalid). > So for a Java-null argument, Acceleo should look first for an exact OclVoid > match and if that is missing look for all possible matches (except OclInvalid) > reporting an ambiguity if more than one. Even with OCLVoid, "obj.eClass()" does not return null (or, at least, I do not think so). Maybe eClass() returns null for an unresolvable proxy? In short, I still have no idea as to how to get to this "error" code path. It now throws an Acceleo exception. I set this bug as "worksforme" since I cannot really say that it is "solved". Until someone stumbles on this with reproduction steps :). |
For Acceleo 3.1.2 I can get java.lang.AssertionError at org.eclipse.acceleo.engine.internal.environment.AcceleoEvaluationEnvironment.mostSpecificTemplate(AcceleoEvaluationEnvironment.java:928) at org.eclipse.acceleo.engine.internal.environment.AcceleoEvaluationEnvironment.getMostSpecificTemplate(AcceleoEvaluationEnvironment.java:340) at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.prepareInvocation(AcceleoEvaluationVisitor.java:1547) which is } else { // TODO are there any chance the argument would not be an EObject? assert false; } So, yes. The argument can be null.