Bugzilla – Full Text Bug Listing
| Summary: | Empty AST for class with static inner class in a package with package-info.java | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Xavier Coulon <xcoulon> | ||||||
| Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | amj87.iitr, clappi, daniel_megert, donksr1, eclipse.sprigogin, eclipse, jarthana, jwnimmer, markus.kell.r, michael.koch, michael, mlippert, nahid.akbar, Olivier_Thomann, philippe.marschall, srikanth_sankaran, stephan.herrmann, tball, tparker, vyazelenko | ||||||
| Version: | 3.7 | Flags: | srikanth_sankaran:
review+
stephan.herrmann: review+ |
||||||
| Target Milestone: | 3.7.1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
[Sorry, I submitted the issue a bit too fast] -> Steps to reproduce : use the sample code provided in the initial comment. I'll take a look at it. I could not reproduce using I20110529-2200 (4.1 build). Could you please pack up a project with project's specific settings and attach it to this bug report ? Xavier, could you reproduce on Indigo RC4 ? If yes, please provide your project as I cannot reproduce following steps in comment 0. Moving to JDT/UI I get the same error using the refactor to rename a constructor argument name of a inner class. (In reply to comment #6) > I get the same error using the refactor to rename a constructor argument name > of a inner class. Would it be possible for you to attach a test case ? *** Bug 350523 has been marked as a duplicate of this bug. *** *** Bug 350413 has been marked as a duplicate of this bug. *** Created attachment 199088 [details] Test case Eclipse project for bug 348024 The attached zipped Eclipse project is a test case for this bug. Note that as in bug 350523 I can only reproduce the error if there is a package-info.java in the same package as the test class. *** Bug 351915 has been marked as a duplicate of this bug. *** *** Bug 353687 has been marked as a duplicate of this bug. *** I can confirm that I ran into this same issue with classes with static internal classes and package level annotations. This broke both the JPA plugin and getter/setter generation. works fine on heilos This is a bug in JDT Core. The ASTParser returns an empty AST as soon as there's a package-info.java file. To reproduce, import the project from comment 10 and then e.g. use the ASTView in "Use ASTParser.createASTs" mode. I'll take a look. This is severe. Seems to be fixed in HEAD. Investigating. The fix for bug 354536 is fixing this one as well. > use the ASTView in "Use ASTParser.createASTs" mode. -----> It's actually "Use ASTParser.createAST". Yup, fixed in HEAD, but broken in R3_7_maintenance. Bug 354536 fixes the problem, but I'd like to understand why. Inside the org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitDeclaration, ICompilationUnit, NodeSearcher, boolean, boolean, boolean) there is no loop as it was done for other paths to retrieve the right unit after the call to beginToCompile(..). Check the fix for bug 337868. I think the same patch that was done for bug 337868 should also be done in this case. So instead of applying patch for bug 354536 I prefer to be more consistent and apply the same loop done for the fix for bug 337868. Patch to follow. Created attachment 202021 [details]
Proposed fix + regression test
Srikanth, please review. Stephan, please review as this is similar to the fix you made for bug 337868. I think one path was missing. First, here's my analysis: I agree on the similarity to bug 337868, in both cases the code was based on the brittle assumption that beginToCompile would insert exactly one CUD into unitsToProcess. This is dangerous. At a closer look the design seems to be: during beginToCompile no further types must be requested from the LookupEnvironment. If the compiler follows that rule, the above assumption should be sound. So far we know of exactly one violation of the rule: the lookup of package-info.java triggered along the path that was removed in bug 354536. If this was indeed the only trigger, the patch from bug 354536 should be the superior solution. Otherwise the following fact can still strike back on us: if during beginToCompile a further type is requested and accepted() that type will actually get ahead of the initial type, because it will be process up-to and including completeTypeBindings(), before the initial type even completes beginToCompile(). I.e. the additional loop proposed here (a la bug 337868) doesn't guarantee the intended processing order. I couldn't easily find a test case to demonstrate possible havoc, but I feel we are on unsafe grounds as long as we accept such unintended orders. For 3.8 I suggest to combine both approaches and additionally add checks that will report/log whenever we see more than one unitsToProcess at the locations is question. For 3.7.1 I'm not quite sure which way is safest. Either patch fixes the immediate issue. I'm leaning towards suggesting both patches also for 3.7.1, to be on the safe side. Do you see any risk in the patch from bug 354536? (In reply to comment #24) > For 3.7.1 I'm not quite sure which way is safest. Either patch fixes the > immediate issue. I'm leaning towards suggesting both patches also for > 3.7.1, to be on the safe side. Do you see any risk in the patch from > bug 354536? I am also tempted to go with both fixes as this makes the compilation order more predictable and prevent types from being inserted into the unitToProcess array when beginToCompile(..) is called. Srikanth, I think the patch I attached makes the code from bug 337868 more consistent. The fix for 354536 makes sure that the package-info unit is not inserted in the units to process too early. This might fix other issues when package-info unit exists. (In reply to comment #24) > I.e. the additional loop proposed here (a la bug 337868) doesn't > guarantee the intended processing order. This was not the intent. I wanted all paths to be covered the same way. Right now one path is clearly inconsistent. (In reply to comment #26) > (In reply to comment #24) > > I.e. the additional loop proposed here (a la bug 337868) doesn't > > guarantee the intended processing order. > This was not the intent. I wanted all paths to be covered the same way. Right > now one path is clearly inconsistent. Fully agree. I was discussing more the global picture of underlying design intentions :) BTW: feeling "guilty" for the incompleteness in bug 337868 I looked for other candidates, but there is only one third call to beginToCompile which is the main compile(ICompilationUnit[]) method which looks clean to me. (In reply to comment #25) > I am also tempted to go with both fixes I'll give you my +1 for this. RC2 will be built tomorrow morning, right? Were you planning to contribute the patch to that build? (In reply to comment #28) > RC2 will be built tomorrow morning, right? > Were you planning to contribute the patch to that build? Ideally. I'll also give a +1 for the fix for bug 354536. Patch looks good. (In reply to comment #25) > I am also tempted to go with both fixes as this makes the compilation order > more predictable and prevent types from being inserted into the unitToProcess > array when beginToCompile(..) is called. > Srikanth, I think the patch I attached makes the code from bug 337868 more > consistent. The fix for 354536 makes sure that the package-info unit is not > inserted in the units to process too early. +1 for thew fix for bug 354536 also. Released in HEAD for 3.8 M2 and in 3.7.x maintenance stream for 3.7.1 RC2. Jay, please include this for 3.7.1 RC2. *** Bug 355390 has been marked as a duplicate of this bug. *** Verified for 3.7 RC2 using build I20110824-0800. Verified for 3.8M2 with build I20110912-2126. *** Bug 361047 has been marked as a duplicate of this bug. *** *** Bug 361181 has been marked as a duplicate of this bug. *** |
Build Identifier: I20110519-1138 I have the following class with a private constructor and an internal builder class that invokes this constructor. public class TestClass { private String testField; public static class TestBuilder { private String t; public TestClass build() { return new TestClass(this); } } private TestClass(TestBuilder builder) { this.testField = builder.t; } } When I try to pugenerate getters and setters for the 'testField' attribute, it fails with the following errors: java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:477) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2642) at org.eclipse.ui.internal.progress.ProgressManager$RunnableWithStatus.run(ProgressManager.java:1346) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager$7.run(ProgressManager.java:1184) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4681) at org.eclipse.ui.internal.progress.ProgressManager.runInUI(ProgressManager.java:1182) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:618) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.generate(AddGetterSetterAction.java:549) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:340) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:575) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:279) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4163) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Caused by: java.lang.NullPointerException at org.eclipse.jdt.internal.corext.dom.ASTNodes.getParent(ASTNodes.java:514) at org.eclipse.jdt.internal.corext.codemanipulation.AddGetterSetterOperation.run(AddGetterSetterOperation.java:307) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4860) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464) ... 46 more and Java Model Exception: Core Exception [code 4] Could not find the selected type element at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:50) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4860) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2642) at org.eclipse.ui.internal.progress.ProgressManager$RunnableWithStatus.run(ProgressManager.java:1346) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager$7.run(ProgressManager.java:1184) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4681) at org.eclipse.ui.internal.progress.ProgressManager.runInUI(ProgressManager.java:1182) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:618) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.generate(AddGetterSetterAction.java:549) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:340) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:575) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:279) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4163) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Caused by: org.eclipse.core.runtime.CoreException: Could not find the selected type element at org.eclipse.jdt.internal.corext.codemanipulation.AddGetterSetterOperation.run(AddGetterSetterOperation.java:312) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4860) at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:106) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:759) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:756) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2642) at org.eclipse.ui.internal.progress.ProgressManager$RunnableWithStatus.run(ProgressManager.java:1346) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager$7.run(ProgressManager.java:1184) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4681) at org.eclipse.ui.internal.progress.ProgressManager.runInUI(ProgressManager.java:1182) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:618) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.generate(AddGetterSetterAction.java:549) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:340) at org.eclipse.jdt.ui.actions.AddGetterSetterAction.run(AddGetterSetterAction.java:575) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:279) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:251) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4163) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Reproducible: Always Steps to Reproduce: 1. Use a sample class 2. 3.