| Summary: | [compiler] NPE with role ifc wrongly interpreted as a team | ||
|---|---|---|---|
| Product: | [Tools] Objectteams | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | OTJ | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.0.1 | ||
| Target Milestone: | 2.1 M4 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Fixed for 2.1 M4 via http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/commit/?id=0f8bfbbc9ae90550f9f4eb049f43a7c1d0dc568f Along two paths we now explicitly avoid the combination of AccInterface and AccTeam. Main issue (NPE) verified for 2.1 M4 using build 201112131519, however, a fup was detected: Bug 366976 The fix has been backported to 2.0.2 via commit dd71e720db99a23d6becdc5132298085870747e9 |
The following snippet: package t; import base b.Base; public team class T1 extends T0 { protected interface IR @Override protected class R2 playedBy Base { void bar() { this.foo(); } } } triggers this exception: java.lang.NullPointerException at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureTeamState(Dependencies.java:506) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureRoleState(Dependencies.java:844) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureTeamState(Dependencies.java:655) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureAstState(Dependencies.java:447) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureState(Dependencies.java:276) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureState(Dependencies.java:253) at org.eclipse.objectteams.otdt.internal.core.compiler.control.Dependencies.ensureState(Dependencies.java:216) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:820) I can see in the debugger that the syntax error causes IR to be interpreted as a team, then the teamModel is looked up in the class part which naturally doesn't exist (interface!).