Community
Participate
Working Groups
Created attachment 207043 [details] test This was initially reported in bug 186342 comment 126: A build path problem (illegal annotation name for non-null) was detected early during beginToCompile(). As a result the parsed unit was never added to Compiler.unitsToProcess. Later, it was attempted to transfer the problems from the unit's compilation result to the DOM CU, but with unit == null we hit an NPE. The attached test demonstrates the problem on top of the latest from bug 186342.
Created attachment 207044 [details] possible fix This patch fixes the issue by simply storing the AbortCompilation.problem during handleInternalException and using this object later if unit==null. Alternatively, we might want to make sure that addCompilationUnit() is always called, but that could potentially have more side effects than we want -- not sure. I think the given patch is a bit safer. Also contained: a little patch to a test util to prevent NPE when trying to report a problem without a file name. We might want to check this: most clients check problem.getOriginatingFileName() for null, with only a few exceptions: 1 call in EclipseCompilerImpl and some calls (not all) in Main.
Created attachment 207268 [details] more fixes Working more on reporting configuration problems regarding bug 186342 I found a few more peculiarities if errors do not directly relate to source code but to the project setup. The patch is part of the work in bug 186342 and documents my proposed solution. Changes in the lookup package are only indirectly related: this is where error reporting happens and especially if LookupEnvironment.problemReporter is used no referenceContext is available, contributing to part of the issues at hand. The changes in lookup and in ProblemReporter do a best effort to actually provide a CompilationUnitDeclaration to the ProblemHandler, but this cannot cover all control flows. Suggested changes and their rationale: Compiler: I observed that some problems were silently dropped, because an AbortCompilation was thrown in a context where neither a CUD nor a CompilationResult would be available. Happens when an error without a referenceContext is reported as early as during LookupEnvironment.buildTypeBindings because at this point Compiler.addCompilationUnit() hasn't happened yet. Solved by recovering the CompilationResult in an intermediate catch. CompilationUnitResolver: (same as previous patch) Recover the problem via new field CompilationUnitResolver.abortProblem. AbstractImageBuilder: Don't report CAT_BUILDPATH problems against a random CU but against the problem. ReconcileWorkingCopyOperation: Don't show CAT_BUILDPATH problems in every Java editor. I resigned from my original goal of reporting these errors with a BUILDPATH_PROBLEM_MARKER (as to get the red "!" decoration on the project) because that seems to be specialized for actual classpath problems, using such markers directly influences the builder more than I'd intend here.
(In reply to comment #2) > AbstractImageBuilder: > Don't report CAT_BUILDPATH problems against a random CU but against the > problem. Correction: Don't report CAT_BUILDPATH problems against a random CU but against the *project*.
Minimal version released for 3.8 M4 as part of commit http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=305123b230bcfd1f733969b7cd2c687b75857ff0 on behalf of bug 186342.
Verified for 3.8 M4 via code inspection.
