Bugzilla – Full Text Bug Listing
| Summary: | [null] "Missing code implementation in the compiler" when using @NonNullByDefault in package-info.java | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mickaël Vera <vera.mickael> | ||||||
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | daniel_megert, jarthana, manoj.palat, srikanth_sankaran | ||||||
| Version: | 4.4 | Flags: | jarthana:
review+
|
||||||
| Target Milestone: | 4.4.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I imported the project attached in a new workspace and the problem occurred only when I activated null pointer analysis: Project > right click > properties > Java Compiler > Errors/Warnings > Configure Workspace Settings > Null Analysis Then check "Enable annotation-based null analysis" I can reproduce in R4_4, but not in HEAD. Specifically, the bug appears fixed since the fix for bug 438179. To understand whether that fix really resolves or just hides the problem in this bug I'm using this minimal repro: //--- import org.eclipse.jdt.annotation.*; class R<T> { R(@Nullable T t) {} } class A {} @NonNullByDefault public class Extract { R<A> test() { return new R<A>(null); } } //--- Variant of the code:
Avoid @NonNullByDefault:
//---
import org.eclipse.jdt.annotation.*;
class R<T> {
R(@Nullable T t) {}
}
class A {}
public class Extract {
R<A> test() {
return new R<@NonNull A>(null);
}
}
//---
==>> Also: broken prior to bug 438179, fixed with bug 438179.
==>> Not an issue of nullness defaults.
Another variant:
Remove warning "Redundant specification of type arguments <A>"
(shouldn't we suppress this warning if the type argument brings new type annotations into the equation?):
//---
import org.eclipse.jdt.annotation.*;
class R<T> {
R(@Nullable T t) {}
}
class A {}
public class Extract {
R<@NonNull A> test() {
return new R<>(null);
}
}
//---
==>> OK after bug 438179, before that fix:
java.lang.IllegalArgumentException: Type doesn't have its own method?
at org.eclipse.jdt.internal.compiler.lookup.SyntheticFactoryMethodBinding.applyTypeArgumentsOnConstructor(SyntheticFactoryMethodBinding.java:40)
at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.registerInferenceContext(AllocationExpression.java:776)
at org.eclipse.jdt.internal.compiler.lookup.InferenceContext18.inferInvocationType(InferenceContext18.java:536)
at org.eclipse.jdt.internal.compiler.lookup.Scope.inferInvocationType(Scope.java:5150)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getStaticFactory(Scope.java:5068)
at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.inferElidedTypes(AllocationExpression.java:581)
at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolvePart2(AllocationExpression.java:497)
at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolveType(AllocationExpression.java:487)
Need to investigate relation to bug 440764 ...
Created attachment 245658 [details] patch for issue in comment 4 This patch adds extra safety to avoid the IllegalArgumentException. This patch is not strictly needed for the given snippet after the fix for bug 438179, but may be safer to add anyway. Problems from comment 2 and comment 3 are indeed duplicates of bug 438179. Problem from comment 4 is a duplicate of bug 440764. I still have a patch under test that: - adds all three tests from this bug - applies the patch from comment 5 to fully avoid the original problem To see the patch in effect you'd have to rewind to a state prior to bug 438179. Released for 4.5 M1 via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=caa8e2c381e9b7346f8392e15cd0656885bb751e Proposing for 4.4.1, because: - in 4.4 the IAE can still be observed, in fact even if bug 438179 would be backported, we cannot fully rule out that it pops up in some other situation - the fix is small and directly acknowledges the fact that a MethodBinding can always be a ProblemMethodBinding. (In reply to Stephan Herrmann from comment #7) > - in 4.4 the IAE can still be observed, in fact even if bug 438179 would be > backported, we cannot fully rule out that it pops up in some other situation Correction: not IAE but "Missing code implementation in the compiler". (The IAE is being handled via bug 440764). Since I confused the parts of bug 438179 to which this relates, let me restate the rationale for backporting: - in 4.4 the bogus compiler error "Missing code implementation in the compiler" can still be observed, in fact even if bug 438179 would be backported, we cannot fully rule out that it pops up in some other situation - the fix is small and directly acknowledges a ProblemReason that had been added during 4.4 (invalidMethod already handles this reason, but invalidConstructor lacked that case). Sorry for the confusion :-/ +1 for back porting Released for 4.4.1 via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_4_maintenance&id=940c4cb4f50cb93adf569e6caf512baa70a8b0b1 Verified for Eclipse Luna SR1 4.4.1 Build id: M20140827-0800 Verified for Eclipse Mars 4.5 M5 Build id: I20150126-2000 |
Created attachment 244949 [details] just compile this project, the error should raise The compiler raises the error "Missing code implementation in the compiler" when compiling the small project attached to this report. If I remove the line @NonNullByDefault in package-info.java the problem disappears. I use: jdk 1.8 u5 x64 eclipse 4.4 RC3 x64 compiler compliance level is 1.8 I added plugins checkstyle and findbugs. I did activate a lot of options in warning/errors of the compiler. Regards, Mickaël