Bugzilla – Full Text Bug Listing
| Summary: | [evaluator] Tuples containing null values cause exceptions | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Axel Uhl <eclipse> | ||||||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | ed | ||||||||
| Version: | 3.0.0 | ||||||||||
| Target Milestone: | 3.1.0 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | 342644 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Adding dependency on 342644 because a patch will be relative to the patch for 342644 Created attachment 194440 [details] GIT patch fixing the Tuple-null problem, with tests Extracts the now reverted changes of 342644 that fix the issue, including new and now again uncommented tests. Apply the fix after applying attachment 194438 [details] of 342644, ignoring the first two path elements. Created attachment 194443 [details]
CVS patch containing the same fix as 194440
Fixes the Tuple/null issue, includes test cases
Created attachment 194447 [details]
Patch for underlying EMF bug
The VoidType guard is indeed a fix for the wrong bug.
The true bug is in EMF that assumes that setting delegates are for EClass, when setting delegates for EAttributes may have EClassifier types to which VoidType conforms.
Please raise the EMF bug, then +1 to commit after re-commenting the eSet and eGet guards as workarounds for the EMF Bug number.
Enhanced comment, pointing to new EMF bug 344395. Committed to CVS HEAD. Closing all bugs resolved in Indigo. |
Here's an additional test case for TupleTest that fails so far. public void test_tupleLiteral_nullValues() { // one part assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a = null}.a " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:OclVoid = null}.a " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:String = null}.a " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:Fruit = null}.a " + "endpackage"))); // multiple parts assertEquals(1, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a = null, b=1}.b " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a = null, b=1}.a " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:String = null, b='abc'}.a " + "endpackage"))); assertEquals("abc", evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:String = null, b='abc'}.b " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:Fruit = null, b:String='abc'}.a " + "endpackage"))); assertEquals(null, evaluate(parse( "package ocltest context Fruit " + "inv: Tuple{a:Fruit = null, b:OclVoid=null}.b " + "endpackage"))); } The null values cause ClassCastExceptions with VoidTypeImpl not conforming to EClass. A fix has to avoid actually invoking the setting delegate for OclVoid-typed tuple components, for both reading and creating.