Bugzilla – Full Text Bug Listing
| Summary: | [compiler] extraneous tests in Scope#findExactMethod | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Maxime Daniel <maxime_daniel> | ||||
| Component: | Core | Assignee: | Maxime Daniel <maxime_daniel> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | 3.3 | ||||||
| Target Milestone: | 3.3 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
It is in Scope#findExactMethod indeed. Created attachment 54769 [details]
Fix
Released for 3.3 M4. Verified for 3.3M4 with I20061211-1119 |
Source version v_725. The following extract shows that the second test against Binding.NO_TYPE_VARIABLES is extraneous, assuming that we are exempt from multi-threading side effects. public MethodBinding findExactMethod( ... MethodBinding exactMethod = ... if (exactMethod != null && exactMethod.typeVariables == Binding.NO_TYPE_VARIABLES && !exactMethod.isBridge()) { ... if (exactMethod.typeVariables != Binding.NO_TYPE_VARIABLES || invocationSite.genericTypeArguments() != null) { ... } return null; } A variant happens within the block. I believe that this is a consequence of a constants rationalization effort that replaced a code in which tests yielding the same results looked different. Now they are clearly redundant. This is a follow-up on bug 164094 that pointed that code area out for another reason.