Community
Participate
Working Groups
Created attachment 236644 [details] Screenshot package one.test; import java.lang.annotation.Repeatable; @interface FooContainerContainer { FooContainer[] value(); } @Repeatable(FooContainerContainer.class) @interface FooContainer { Foo[] value() default {}; } @Repeatable(FooContainer.class) @interface Foo { int value(); } @Foo(0) @FooContainer({ @Foo(1) }) @FooContainer({ @Foo(2) }) public class A3 { } ------------------------------------ 1. File is initially saved with error at '@Foo(0)' 2. Delete the '@Foo(0)' line. Editor is dirty. 3. Add semicolon at the end of '@FooContainer({ @Foo(1) })' 4. Press Ctrl+Z twice. Editor is not dirty anymore. But the error marker (sometimes red and mostly gray) at '@FooContainer({ @Foo(1) })' stays. (See attached screenshot)
This is not reproducible anymore - I could and did reproduce it when it was reported. Closing as WORKSFORME. Noopur, please test against the HEAD of BETA_JAVA8 and if you are also not able to reproduce - please mark as verified. Otherwise reopen. Thanks.
Created attachment 237892 [details] Screenshot with latest code Now with the latest code, I can see a warning instead of error at '@Foo(0)'. And playing with the steps given in comment #0, I still see different markers as attached in the screenshot.
Thanks Noopur, don't know what is going on - will take a look.
Created attachment 238201 [details] WIP: Patch I can reproduce the issue. I have trouble coming up with a test case where I can reproduce the bug problematically. I am attaching the WIP patch. Can one of you help with the test case. I will attach the jclMin1.8src.jar and jclMin1.8src.zip files needed. The following file: Repeatable.class and Repeatable.java have been added. Path : src\java\lang\annotation Thanks
Created attachment 238202 [details] Jar file zip Please see Comment 4
Created attachment 238203 [details] Source file zip Please see Comment 4.
I have observed as well as we have heard reports from Markus and Noopur that some times, the reconciler ends up with incorrect source ranges for constructs. These are not consistently reproducible. In my observation, one or more of - Pasting snippets into editor or package explorer, - quick fix/refactoring. - Undo/Redo - Incremental build/clean build - Change of project settings (compliance/source levels in particular) may be involved. The observed symptoms are one or more of : - Editor shows persisting error which will vanish after a save, or some other operation. - Package explorer will show the project having errors while it does not - Bad AST structure exceptions - Editor highlighting of erroroenous constructs is off by a few characters here and there These usually vanish with one or more of: - Save editor, - Clean and rebuild, - Refresh workspace - Shutdown and start eclipse. We need to track this loch ness mosnter and shoot it down in time for GA.
*** Bug 424164 has been marked as a duplicate of this bug. ***
We need reproducible test cases. If you spot any weird issues in this area, please document your observations/steps here.
I've seen a couple like that related to naming and renaming of compilation units. First one involves one CU with two classes, one of them public. After editing the source to make the public class package-private and the other one public instead the CU remains tied to the formerly public class. Second one seemed much more serious and happened with two classes A and B in separate CUs. After renaming class A->C and class B->A Package Explorer showed the contents of the new A correctly but the editor view of A showed the old contents of the former A, now C, and these contents didn't seem to be tied to anything anymore. Only restarting cleared this. I haven't tried to find the exact steps for these yet, but hopefully there aren't any edge-case conditions that are needed for them to occur.
I don't see this problem anymore. Yes, I have claimed that before :) Noopur, can you double check ?
(In reply to Srikanth Sankaran from comment #11) > Noopur, can you double check ? Screen shots not necessary, your word is proof enough :)
(In reply to Srikanth Sankaran from comment #12) > (In reply to Srikanth Sankaran from comment #11) > > > Noopur, can you double check ? > > Screen shots not necessary, your word is proof enough :) Yes, I can reproduce the issue in comment #0 with latest code of BETA_JAVA8. The error/warning marker and its color varies depending on how fast I press Ctrl+z and whether I save the editor with code having error and then undo the changes.
(In reply to Noopur Gupta from comment #13) > Ctrl+z and whether I save the editor with code having error and then undo > the changes. Thanks, the save operation seems to be essential. I can see it now.
See also bug 423416, which is about sporadically failing CodeCompletionTests. We can't explain why they sometimes fail, but the issue seems to be that the working copy buffer contains outdated contents.
(In reply to Noopur Gupta from comment #13) > Yes, I can reproduce the issue in comment #0 with latest code of BETA_JAVA8. > The error/warning marker and its color varies depending on how fast I press > Ctrl+z and whether I save the editor with code having error and then undo > the changes. However, when you save and then do ^Z, the editor is tagged as dirty - right ? If so, I don't see an issue here - unless you see a red circle when you should not. I see only the grayed out circle after save and undo.
(In reply to Markus Keller from comment #15) > See also bug 423416, which is about sporadically failing > CodeCompletionTests. We can't explain why they sometimes fail, but the issue > seems to be that the working copy buffer contains outdated contents. Thanks, sounds plausible. I am retargetting this 4.4 - it is not clear that JDT/core has a role here. If evidence emerges to the contrary, will pull it back up. The comment#0 scenario itself is not hugely worrisome for me - it is the other scenarios listed - but I haven't spotted this lately.
Here is a scenario that shows the problem consistently. Basically, if you answer yes to the dialog that says "... project settings have changed, do you want to rebuild ?" when the editor is dirty, then the build seems to operate on the old contents, while the editor is showing new contents. Steps: - Start with Kepler SR + Java 8 bundles. - Create a 1.8 project with the code below: // -- interface I { void doit(); } class X { static void foo() {} I i = (I & java.io.Serializable) () -> {}; I i2 = new I() { public void doit() { } }; } // compiles fine, no issues. -- Replace the contents of the editor by copy + pasting the code below: import java.io.File; public class X { static interface IInterface { public void method(File file); } static abstract class AbstractClass implements IInterface { public void method(File file) { System.err.println("file"); } public void method(String string) { System.err.println("string"); } } private static AbstractClass newAbstractClass() { return new AbstractClass() {}; } public static void main(String[] args) { // this should be flagged as ambiguous, but is not // correctly reported by javac as an error newAbstractClass().method(null); } } // Reconciler shows one error - good. -- Without saving the file, go to project + properties + Java compiler + change compliance level, source level etc to 1.7 + apply -- Answer yes to the rebuild now question. -- You can see problems view reporting issues from the old file contents. Editor shows the new file, error underlining is all messed up as the offets etc are wrt to old file contents. I am not sure whether this belongs in JDT/UI or Text. Please pass it back if JDT/Core has a hand somewhere.
I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=428858 for the issues reported in https://bugs.eclipse.org/bugs/show_bug.cgi?id=419829#c7 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=419829#c18 as it is very different from the issue reported in comment#0. Let us keep the present defect only for the issue reported in comment#0. Ignore all comments pertaining to more general weird issues in reconciler. Restored the original titled of the bug and assigning to JDT/Text for investigation. The phantom markers (grayed out ones) is what I see (when I see) now and these are not managed by JDT/Core. However, if analysis shows we have a hand somewhere, pass it back.
(In reply to Srikanth Sankaran from comment #16) > (In reply to Noopur Gupta from comment #13) > > > Yes, I can reproduce the issue in comment #0 with latest code of BETA_JAVA8. > > The error/warning marker and its color varies depending on how fast I press > > Ctrl+z and whether I save the editor with code having error and then undo > > the changes. > > However, when you save and then do ^Z, the editor is tagged as dirty - right > ? > If so, I don't see an issue here - unless you see a red circle when you > should > not. I see only the grayed out circle after save and undo. After save, when I press Ctrl+Z twice very quickly, the editor is dirty and I also see the red circle at "@FooContainer({ @Foo(1) })".
I don't see this issue anymore. Please re-open with updated steps if you can still reproduce it.
