[cg] Support distinct boxed/unboxed/ecore representations

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 458359 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 25, 2015 10:59 EDT | | Modified | May 29, 2019 04:12 EDT | | Version | 5.0.0 | | Reporter | Ed Willink |

Description

The Bug 448470 / Bug 455394 fixes for name of EEnumLiteral introduce a clear 3-way Boxed/Unboxed/Ecore prevailing representation distinction.

This does not exist in the CG, consequently the new EvaluateModelOperationsTest4.test_enumeration_navigation fails with a CCE preparing to invoke an operation on an Enumerator.

Requires a CGEcoreExp counterpart to CGBoxExp, CGUnboxExp and a CGTypeId-dependent determination for isBoxed/isEcore/isUnboxed so that the many types that are more than one of the representations do not incur unnecessary conversions.

[eclipse-ocl-bot]

By Ed Willink on May 18, 2015 14:04

Branch ewillink/458359 improves the unboxing aspect but should really be to-ecore.

[eclipse-ocl-bot]

By Ed Willink on Jun 26, 2015 09:02

(In reply to Ed Willink from comment #0)

Requires a CGEcoreExp counterpart to CGBoxExp

This is now pushed to master. But

EvaluateModelOperationsTest4.test_enumeration_navigation

still fails. Now just a simple confusion as to the Ecore representation of an iterator.

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2015 08:43

(In reply to Ed Willink from comment #2)

still fails. Now just a simple confusion as to the Ecore representation of an iterator.

Not so simple, it's specific to the EnumerationLiteralId/EEnumLiteral/Enumerator requiring correct construction of a ELiteral-specific descriptors.

[eclipse-ocl-bot]

By Ed Willink on May 22, 2019 06:00

We have three distinct representations but no clarity on when which is used. Resolving the CG failures for a QVTd SharedEdge connection require an answer to what is the preferred/mandatory representation for a QVTd MAP parameter value, a FUN field value?

For OCL the three representations have inexact counterparts in CG{Ecore/Executor/Library}{Operation/Property}CallExp with plausible conversions of internal values to outgoing parameter values, but no conversion of incoming returns.

Since the distinct representations are compatible, a redundant toBoxed/Ecore/Unboxed does no 'harm' so maybe a 'convert only when the recipient is restrictive' policy is adequate; we just need to document all the recipient restrictions. QVTd needs to specify and respect its new restrictive reipients.

[eclipse-ocl-bot]

By Ed Willink on May 29, 2019 04:12

The recent QVTd problem was due to use of unboxed for CGFunctionCall, CGGuardVariable. Changing them to boxed avoids the need for an unsupported declaration.

However adding a TypeRepresentation interface with Boxed/Unboxed/Ecore derivations allows a desired representation to be explicit rather than empathized. THis provides an opportunity fo the many class-argument merthods to evolve to rather fewer clearer methods. (Pushed to master for 2019-06M2)