Summary: | "Document does not match the AST" error when modifying compilationUnit and then moving it | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tom Mutdosch <mutdosch> | ||||
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
Status: | RESOLVED INVALID | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | CC: | jerome_lanneluc, markus.kell.r, martinae | ||||
Version: | 3.2 | Keywords: | needinfo | ||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Tom Mutdosch
2005-10-31 16:23:59 EST
Created attachment 29173 [details]
Regression test
I cannot reproduce this problem. The attached regressin test passes with 3.1.1
and 3.2 M3.
I couldn't run your test myself because I don't seem to have the CopyMoveResourcesTests class in my copy of eclipse, but I'll take your word for it. Then that means that it works in your case but I am still seeing the problem - so what causes this error exactly? What does it mean is happening? I can try doing something differently. It looks like a BatchOperation is executing and then my code adds an import and then calls move and then I get that error. I tried calling reconcile() between adding the import and moving the CompilationUnit, but that didn't seem to help any. Any other ideas? Thanks for the help. Martin, any idea why this would fail with this message ? Hm, it's hard to tell what's going on without an example to reproduce. Tom, is the compilation unit you move completely independent from the compilation units that are touched by JDT/UI's move refactoring? Or could it be that you move a CU that has already been changed before? If I see that correctly, you're running in a JavaCore.run(..), which in turn runs inside a ResourcesPlugin.getWorkspace().run(..) block. Jerome, could that be a problem? The ... Caused by: org.eclipse.core.runtime.CoreException: End Of File at org.eclipse.jdt.internal.core.dom.rewrite.TokenScanner.readNext(TokenScanner.java:121) ... looks like there's a problem with the buffer management. Yes, I am pretty sure that the CU is independent of any other changes, because my scenario is: A JSP file is moved via the eclipse Refactor->Move context menu. There shouldn't be any CU's touched by the JDT refactoring process. I have a MoveParticipant that then gets a CU from an unrelated Java file, and then upates its imports and moves it. That's when I get the AST exception. I have found that if I both reconcile and commit the CU after adding the import and before moving the CU, I do not get the exception: cu.createImport(fullyQualifiedType, null, monitor); cu.reconcile(ICompilationUnit.NO_AST, false, null, null); cu.commitWorkingCopy(false, pm); cu.move(destination, null, newName, true, monitor); I still cannot reproduce. Please reopen if it still happens in Eclipse 3.2 or later and if you have details on how to reproduce. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |