Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320890

Summary:

Warn about let filtering

Product:

[Modeling] Acceleo

Reporter:

Ed Willink <ed>

Component:

Core

Assignee:

Project Inbox <acceleo-inbox>

Status:

CLOSED FIXED

QA Contact:

Severity:

enhancement

Priority:

CC:

laurent.goubet, stephane.begaudeau

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Patch v1.0	none

Description Ed Willink

2010-07-26 09:04:24 EDT

The MOFM2T [let semantics is dangereously different to an OCL let. Accidentally assigning a Bag (from an implicit collect) to a Set is particularly easy and undiagnosed, just silent.

Suggest:

a) Provide a warning if the let initializer is not conformant to the let type.

b) Provide some @nowarn annotation for users who rerally want to filter.

Comment 1 Laurent Goubet

2010-07-26 09:27:30 EDT

Hi Ed,

We cannot go for a) as the let is clearly specified as would be an "if - oclIsKindOf" (or "if - instanceof" if talking Java); it is expected that the specified type might not match the right operand value, in which case we switch to the "elselet" or ignore the let block altogether.

However the evaluation engine's runtime checks might not be enough if you say we do allow for the assignment of a Bag to a Set-typed variable. I'll try and check that.

Comment 2 Ed Willink

2010-07-26 09:56:04 EDT

The behaviour is entirely correct (specification-wise) but unhelpful (user-wise).

An attempt to assign a Bag to a Set does not succeed.

It would be nice to have a warning that this guaranteed failure has been requested.

Comment 3 Laurent Goubet

2010-07-26 10:37:55 EDT

I see now... but adding a warning that the user wouldn't be able to get rid of (if it is what he requested)?

Do you have examples of what you would like reported as warning as compared to what you would allow unreported (as far as Set and Bag are concerned)?

Comment 4 Ed Willink

2010-07-26 11:32:48 EDT

I suggested a nowarn annotation for when the user knows that the warning is wrong c.f. Java allows you to do all sorts of stupid things post-suppressWarnings.

Thinking about this a bit more, this may be an Acceleo bug after all.

An 'Unreachable match' (analoguous to an unreachable if branch in Java) occurs whenever the source type is incompatible with a target type. These errors are mostly diagnosed, except implicit filters ([let, [for). So whenever the collection kind is different (unless target is Collection itself), the match is dead, and if one element type does not conform to the other element type the match is dead.

Comment 5 Laurent Goubet

2010-07-27 05:01:06 EDT

Indeed, I can see how such a warning would be useful... and in fact I too come to wonder whether we really need a @nowarn annotation in these cases. We'll need to put some thought in this.

Comment 6 Stephane Begaudeau

2010-09-13 08:53:07 EDT

Created attachment 178741 [details]
Patch v1.0

Comment 7 Stephane Begaudeau

2010-09-13 08:59:57 EDT

Contributed and available in Acceleo 3.1.0 M2