-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NullPointerException: Cannot invoke "TypeBinding.kind()" because "type" is null #986
Comments
It is after all just an example - the NPE occurs no matter if I add the import for But as you say, you can't reproduce it with a new Java project, I narrowed the problem further down: I have annotation-based null analysis turned on (as you can see from my stacktrace - I've attached an MRE project now: Test.zip |
@stephan-herrmann Another problem scenario where org.eclipse.jdt.internal.compiler.lookup.ClassScope.hasDefaultNullnessFor(ClassScope.java:1737) triggers a symptom that is different from #1007 and cousins |
Will be fixed by the next iteration in #1067 |
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotation details Common point-fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces part of the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotation details Common point-fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces part of the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Reverts/replaces the fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Replaces the reverted fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Replaces the reverted fix from: * eclipse-jdt#630
(regression 2023-03) Avoids any risky ahead-of-time resolving of annotations Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 Replaces the reverted fix from: * eclipse-jdt#630
…ssion 2023-03) (#1077) Avoids any risky ahead-of-time resolving of annotations + In ClassScope.findSuperType() remove the early hasDefaultNullnessFor() from #630 + In ReferenceBinding.implementsInterface() remove ahead-of-time resolving from from #630 + TypeReference.internalResolveType() should never resolve any annotations when not ready - Readiness is determined by (tagBits & EndHierarchyCheck) != 0. + Scope.hasDefaultNullnessForType, when not ready, always answers false to leave a clean slate for a later phase to consider null annotations. Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work + Starting from LookupEnvironment.completeBindings() a new phase has been introduced which may safely assume that all type hierarchies are fully completed to avoid all out-of-order processing + Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations(): - complete the initialization of tagBits relating to all kinds of annotations - traverse all superclass, superInterfaces and memberTypes links to update resolved bindings with information from anntations + 2nd level implementation is in TypeReference.updateWithAnnotations() which will resolve annotations and possibly update .resolvedType with that information Common fix for these problems: * #1007 * #854 * redhat-developer/vscode-java#3076 * #986 * #476 Replaces the reverted fix from: * #630 Remove remnants of deferred checks from Bug 434570 et al see #1074 Also: + additional tweak to help completion to find fields + Test isolation: fix deletion of jar and classpath entry + Test isolation: recover currentProject when run in a suite + Temp disable tests affected by #1201
Resolved via #1077 |
…ssion 2023-03) (eclipse-jdt#1077) Avoids any risky ahead-of-time resolving of annotations + In ClassScope.findSuperType() remove the early hasDefaultNullnessFor() from eclipse-jdt#630 + In ReferenceBinding.implementsInterface() remove ahead-of-time resolving from from eclipse-jdt#630 + TypeReference.internalResolveType() should never resolve any annotations when not ready - Readiness is determined by (tagBits & EndHierarchyCheck) != 0. + Scope.hasDefaultNullnessForType, when not ready, always answers false to leave a clean slate for a later phase to consider null annotations. Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work + Starting from LookupEnvironment.completeBindings() a new phase has been introduced which may safely assume that all type hierarchies are fully completed to avoid all out-of-order processing + Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations(): - complete the initialization of tagBits relating to all kinds of annotations - traverse all superclass, superInterfaces and memberTypes links to update resolved bindings with information from anntations + 2nd level implementation is in TypeReference.updateWithAnnotations() which will resolve annotations and possibly update .resolvedType with that information Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 * eclipse-jdt#476 Replaces the reverted fix from: * eclipse-jdt#630 Remove remnants of deferred checks from Bug 434570 et al see eclipse-jdt#1074 Also: + additional tweak to help completion to find fields + Test isolation: fix deletion of jar and classpath entry + Test isolation: recover currentProject when run in a suite + Temp disable tests affected by eclipse-jdt#1201
…ssion 2023-03) (eclipse-jdt#1077) Avoids any risky ahead-of-time resolving of annotations + In ClassScope.findSuperType() remove the early hasDefaultNullnessFor() from eclipse-jdt#630 + In ReferenceBinding.implementsInterface() remove ahead-of-time resolving from from eclipse-jdt#630 + TypeReference.internalResolveType() should never resolve any annotations when not ready - Readiness is determined by (tagBits & EndHierarchyCheck) != 0. + Scope.hasDefaultNullnessForType, when not ready, always answers false to leave a clean slate for a later phase to consider null annotations. Introduces a new phase CONNECT_TYPE_HIERARCHY2 to finish deferred work + Starting from LookupEnvironment.completeBindings() a new phase has been introduced which may safely assume that all type hierarchies are fully completed to avoid all out-of-order processing + Central implementation of this phase is in TypeDeclaration.updateSupertypesWithAnnotations(): - complete the initialization of tagBits relating to all kinds of annotations - traverse all superclass, superInterfaces and memberTypes links to update resolved bindings with information from anntations + 2nd level implementation is in TypeReference.updateWithAnnotations() which will resolve annotations and possibly update .resolvedType with that information Common fix for these problems: * eclipse-jdt#1007 * eclipse-jdt#854 * redhat-developer/vscode-java#3076 * eclipse-jdt#986 * eclipse-jdt#476 Replaces the reverted fix from: * eclipse-jdt#630 Remove remnants of deferred checks from Bug 434570 et al see eclipse-jdt#1074 Also: + additional tweak to help completion to find fields + Test isolation: fix deletion of jar and classpath entry + Test isolation: recover currentProject when run in a suite + Temp disable tests affected by eclipse-jdt#1201
I just migrated from Eclipse 2022-12 to 2023-03.
Now I get the following exception when building or editing some of the classes in my project:
I could narrow the problem down to this class:
The real class looks different and is much more complex,
Serializable
andDeprecated
are just examples. The problem occurs with any other annotation or interface and even when dropping theimplements Serializable
and using a super class instead. If I importExample
into another class (even without using it), I get the same error for that class, too.If I remove either the
implements
, the annotation or thetarget
attribute, or if I inline thesince
reference, the error is gone. As a workaround I'm using the inline String in the annotation (@Deprecated(since = "...")
).The text was updated successfully, but these errors were encountered: