[editor] content type present false information after a filter or select

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 357196 | | Status | NEW | | Importance | P3 major | | Reported | Sep 09, 2011 03:59 EDT | | Modified | Apr 13, 2016 04:34 EDT | | Version | 3.1.0 | | Reporter | Bouchet Stéphane |

Description

HI,

given the following exemple : \ A.references->filter(subB)->sortedBy(name)

With A that references B elements that have subA and subB heritance, and name is a subB attribute.

the content assists does not show inside the sortedBy() the subB attributes or operation, but the values from A.

same problem with select, or by casting to specified Element.

[eclipse-ocl-bot]

By Laurent Goubet on Apr 04, 2016 11:09

This seems to happen deep in OCL as the "self" variable never seems to be seen as being of type EClass in the iteration.

Ed, do you have any idea why the completion would give such results? You don't need a complex example, the following also fails with 'self' being an EPackage

self.eClassifiers.oclAsType(EClass)->collect()

ask for the completion inside the collect, it will show the EPackage features and operations instead of the EClass ones.

[eclipse-ocl-bot]

By Ed Willink on Apr 04, 2016 11:31

My guess is that the complexities of implicit sources and/or arrow operators are ignored.

The syntax help is provided by pragmatic manual code that is written completely independently of the LPG grammar. It has been tweaked to give superficially useful results. I think QVTo works quite hard to improve it.

---

I intensely dislike duplicate code, especially manual code that duplicates auto-generated code, so I am pleased that the Xtext-based approach upon which the Pivot OCL is based uses only one grammar and derives its completion assist automatically. The generated code is at least duplicated across "ui", non-"ui" plugins and perhaps further, but at least it is all auto-generated from one source. The auto-generated completion has steadily improved as I refine failures to comply with Xtext protocols, so that typically a couple of lines of my code can give a significant improvement to the offered proposals. However proposals for iterations are still suspect awaiting a roundtuit.

The automated generation of the CS2AS conversion is making steady progress. It involves modeled definitions of the lookups, so that I hope this will enable accurate completion assists for all genuine possibilities.

---

Given that the syntax help is a bad approach and two designs out of date, I cannot devote time to fix it. If you provide a straightforward patch that is easy to review and JUnit tested, I'll try to incorporate it. NB since QVTo works hard to improve this area, an OCL fix may break QVTo.

[eclipse-ocl-bot]

By Laurent Goubet on Apr 05, 2016 02:41

Well I've already spent too much time trying to nail this down, so for now I think this can remain as-is as I go through the rest of our existing Acceleo bugs. This one affects both content-assist and compilation but isn't too major.

[eclipse-ocl-bot]

By Ed Willink on Apr 05, 2016 04:03

(In reply to Laurent Goubet from comment #3)

This one affects both content-assist and compilation but isn't too major.

How does it affect compilation?

[eclipse-ocl-bot]

By Laurent Goubet on Apr 05, 2016 05:46

(In reply to Ed Willink from comment #4)

(In reply to Laurent Goubet from comment #3)

This one affects both content-assist and compilation but isn't too major.

How does it affect compilation?

I haven't tried it with pure OCL, but "self.eClassifiers.oclAsType(EClass)->collect(nsPrefix)" does compile with Acceleo, even though "nsPrefix" will not be found at runtime.

[eclipse-ocl-bot]

By Ed Willink on Apr 05, 2016 06:05

(In reply to Laurent Goubet from comment #5)

I haven't tried it with pure OCL, but "self.eClassifiers.oclAsType(EClass)->collect(nsPrefix)" does compile with Acceleo, even though "nsPrefix" will not be found at runtime.

I don't understand. If it compiles correctly, a plausible AST is built and it should execute since the AST refers to the correct implicit source.

Ah! yes there is no nsPrefix in EClass, so it should fail. Trying it in the OCLinEcoore editor by adding an invariant to Ecore's EPackage, it compiles ok. Odd.

No it is correct, but a demonstration that 'helpful' abilities to omit 'redundant' self's can actually be very unhelpful. Since:

(In reply to Laurent Goubet from comment #1)

the following also fails with 'self' being an EPackage

self.eClassifiers.oclAsType(EClass)->collect()

So the unexpectedly successful compilation is:

self.eClassifiers->collect(i : EClassifier | i.oclAsType(EClass))->collect(j : EClass | self.nsPrefix)

rather than the expected failure:

self.eClassifiers->collect(i : EClassifier | i.oclAsType(EClass))->collect(j : EClass | j.nsPrefix)

[eclipse-ocl-bot]

By Laurent Goubet on Apr 13, 2016 04:34

Bug 405726 has been marked as a duplicate of this bug.