Community
Participate
Working Groups
Created attachment 260417 [details] Example Project for Reproduction ### Overview: The boolean, unary NOT operator in some (extreme?) circumstances causes some exception in org.eclipse.jdt.internal.compiler.ast.QualifiedNameReference.optimizedBooleanConstant which causes issues further up in Eclipse. I hope I was correct in filing this in the JDT bug tracker and not that of Eclipse. Else, please forgive me. ### Steps to Reproduce in Eclipse: 1) Import the attached project, which has been reduced and anonymised to the minimum of what I was able to use to reproduce the issue. 2) Open the file bugrepro/BugReproTest.java in the Editor by double clicking it in the Package hierarchy tree sidepane. 3) Mouse over the green run button. 4) Receive an "Compute launch button tooltip" error with vague information. A full error log is available from the 'Error Log' view. 5) (Extra): Open the Run > Run As... Menu, and notice that it is completely blank/empty (not even the 'none applicable' is there). ### Actual Results An error message was received with a stack trace in the Error Log view. ### Expected Results No such error should occur, and an option for running as Java Application should be visible (if main method present) or a grayed out '(none applicable)' pseudo-option should be in the Run > Run As... menu. ### Build Date & Hardware Using build: Version: Mars.2 Release (4.5.2) Build id: 20160218-0600 Running Ubuntu 15.04 (x64) `uname -a` Linux spruce-GA-78LMT-USB3 3.19.0-47-generic #53-Ubuntu SMP Mon Jan 18 14:02:48 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Using Java JDK: openjdk version "1.8.0_45-internal" OpenJDK Runtime Environment (build 1.8.0_45-internal-b14) OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode) ### Additional Builds and Platforms None available for test. ### Additional Information The bug is very finickity to reproduce, so I have attached a project which can be used to reproduce the error, while cutting out as much code as possible and anonymising it. The error log will follow in a new comment if possible, because the attachment form only seems to accept one attachment.
Created attachment 260418 [details] Error log exported from Eclipse with Stack Trace
Created attachment 260419 [details] (Corrected) Eclipse Error Log with Stack Trace Apologies for the prior attachment which was seemingly the entire log file, not the log for this single case.
I can reproduce, although debugging the code that creates a sub menu is prone to freezing the computer ... Anyway, the statement in question is pp.rs = (! (boolean) pp.rs) inside this method public void abc() { Pqrs pp = new Pqrs(); pp.rs = (! (boolean) pp.rs); } During normal compilation all is fine, the qualified name reference pp.rs has resolved type j.l.Object. But on the given call path from HierarchyResolver, the STB for Pqrs has no fields, hence 'rs' is a ProblemFieldBinding with no type. Apparently, one part of the machine thinks we don't need any details, but another part disagrees. It should be possible to create a JUnit by just requesting the type hierarchy for type BugReproTest. Anyone? :)
HierarchyResolver.accept(ISourceType[], PackageBinding, AccessRestriction) has this CompilationUnitDeclaration unit = SourceTypeConverter.buildCompilationUnit( new ISourceType[] {sourceType}, // ignore secondary types, to improve laziness SourceTypeConverter.MEMBER_TYPE | (this.lookupEnvironment.globalOptions.sourceLevel >= ClassFileConstants.JDK1_8 ? SourceTypeConverter.METHOD : 0), // need member types // no need for field initialization this.lookupEnvironment.problemReporter, result); where it is explicitly excluding fields from the built type declaration, so the fields are not included in the parsed type declaration thereby resulting in this problem. Including SourceTypeConverter.FIELD in the flags solves the problem. Could it be for performance reasons that fields were left out??
(In reply to Sasikanth Bharadwaj from comment #4) > where it is explicitly excluding fields from the built type declaration, so > the fields are not included in the parsed type declaration thereby resulting > in this problem. Including SourceTypeConverter.FIELD in the flags solves > the problem. Could it be for performance reasons that fields were left out?? I believe so. It seems like in former times the different use cases calling into the compiler paid great attention to performing only the minimal necessary work, and with Java getting more and more complex, this erodes to doing almost all the work almost all the time (see, e.g., the ">= JDT1_8" part in the quoted snippet). Regarding the issue at hand: I wouldn't expect a huge performance penalty from including fields of secondary types, but OTOH I believe compiling statements (which triggers the NPE in the first place) is beyond the point for creating a type hierarchy. Perhaps this is done in order to find local types? Perhaps we could prune the parse tree in scenarios like type hierarchy to discard all statements other than local type declarations?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
