Summary: | [dom] early throwing of AbortCompilation causes NPE in CompilationUnitResolver | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> | ||||||||
Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | srikanth_sankaran | ||||||||
Version: | 3.8 | ||||||||||
Target Milestone: | 3.8 M4 | ||||||||||
Hardware: | Other | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Stephan Herrmann
2011-11-15 13:55:31 EST
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. |