Bugzilla – Full Text Bug Listing
| Summary: | Spurious loop counter i outside loop | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | laurent.goubet, stephane.begaudeau |
| Version: | 3.1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
This variable should never be visible outside loops, and there lies the problem (it is not diagnosed since the compiler "sees" it and thus thinks it is valid). Is that variable "visible" everywhere, or only after the closing tag of a loop? Initially I thought it was inherited from a call, but of course the editor doesn't know about call hierarchy, so it must have been after a closing tag. I didn't investigate far, since I already know this was an area where Acceleo has Microsoft ergonomics; helpful 90% of the time and troublesome the remaining 10%. (In reply to comment #2) > I didn't investigate far, since I already know this was an area where Acceleo > has Microsoft ergonomics; hey :p. > helpful 90% of the time and troublesome the remaining 10%. The fact is, in should never be troublesome. And in these case it is, there is mostl likely a bug lingering. (Just like here.) Any language that makes "i" a secret variable is always going to be surprising it's users. You must find an obscure spelling. Perhaps "\i" is you want something really short. After a deep analysis of the state of countless of stuff in Acceleo and OCL environments, I have found that this issue was coming from a trivial guard in Acceleo preventing the removal of variables without any containers... so I have added a useless container to this "i" variable. The fix has been contributed on R3_1_maintenance with unit tests and it will be available in Acceleo 3.1.1 Closing our "resolved" and "verified" bugs. This CLOSE is very premature. The fix is less than a week old so there has been no opportunity for user assessment. Ed, We had 50-ish bugs in a "resolved" state, some dating back to 2009. This particular close is indeed a little premature, bug it was part of a bulk-closing :p. Feel free to re-open when you have had time to test if you find out that the fix is wrong. |