| Summary: | [otjld] [compiler] Merging of class-based and binding-based precedences is underspecified | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Objectteams | Reporter: | Stephan Herrmann <stephan.herrmann> | ||||||||
| Component: | OTJ | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | resix | ||||||||
| Version: | 0.7 | ||||||||||
| Target Milestone: | 0.7 M4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 171439 [details]
OTJLD clarification
Addition to the OTJLD that clarifies how declarations are merged.
Created attachment 171440 [details]
implementation
This patch contains the implementation part of the fix.
Corresponding tests are test4127_precedenceDeclaration15() f.
Fix has been committed as r438. Created attachment 171511 [details] Additional fix The patch from comment 2 caused a regression in MethodMappingBindingTest#testPrecedence1() f. Investigation revealed that we have always performed too much transformation on the AST: collecting precedences in the enclosing team should not modify the AST but work on bindings only. Otherwise the DOM AST is affected, too, as witnessed by this regression. Also one error message is improved in this patch: when precedences are in conflict say which ones (either symmetrically or point to one list and mention the other in the message). Verified for M4 using build 201006111053. |
OTJLD ยง4.8(d) currently reads: " Multiple precedence statements All precedence statements are collected at the outer-most team. At that level all precedence declarations involving the same base method are merged using the C3 algorithm [3]. It is an error to declare incompatible precedence lists that cannot be merged by the C3 algorithm." While this ensures that the actual precedence will _conform_ to all individual precedence declarations, this fails to determine the actual ordering when class-based and binding-based precedence declarations need merging. Consider this team: public team class MyTeam { precedence MyRoleB.bl1, MyRoleA; protected class MyRoleB playedBy MyBase { precedence bl1, bl2; void rm() { System.out.println("RoleB.bl1"); } bl1: rm <- before bm; void rm2() { System.out.println("RoleB.bl2"); } bl2: rm2 <- before bm; } protected class MyRoleA playedBy MyBase { void rm() { System.out.println("RoleA"); } rm <- before bm; } } calling bm() currently produces: RoleB.bl1 RoleA RoleB.bl2 whereas the following would be legal too: RoleB.bl1 RoleB.bl2 RoleA Actually, the latter seems more intuitive because it gives priority to inner precedence declarations ("bl1, bl2") over outer precedence declarations ("MyRoleB.bl1, MyRoleA"). The OTJLD should be updated to disambiguate the behavior and the implementation be adjusted accordingly.