Bug 97542 - ASTParser#createASTs does not correctly resolve bindings in working copies
Summary: ASTParser#createASTs does not correctly resolve bindings in working copies
Status: CLOSED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.1 RC2   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-31 11:47 EDT by Tobias Widmer CLA
Modified: 2005-06-10 11:03 EDT (History)
0 users

See Also:


Attachments
project (142.60 KB, application/x-zip-compressed)
2005-05-31 11:47 EDT, Tobias Widmer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Widmer CLA 2005-05-31 11:47:05 EDT
N20050601 or JDT UI Head

Steps to reproduce:
- Setup attached JUnit project
- Install breakpoint at row 516, method endVisit(MethodInvocation), class 
SuperTypeConstraintsCreator with condition "binding.getName().equals("trace");"
- Invoke Extract Interface on class 'TestFailure' from the attached project, 
change type references to interface, selecting all 6 methods
- Examine the method binding of the method invocation

-> The declaring class binding of the method binding has no super interface 
bindings, although when the ASTs where created, the working copy owner of the 
refactoring has been passed. This working copy owner owns the working copy of 
the newly extracted interface and the original class that has been rewritten 
to implement the created interface.
-> Only non-workingcopy compilation units are passed to ASTParser#createASTs. 
Since I have set the workingcopy owner before compilation, I exspect the 
compiler to resolve references to type 'TestFailure' to the declaration in the 
workingcopy, which implements the extracted interface.

The Use Supertype Refactoring is also affected by this problem
Comment 1 Tobias Widmer CLA 2005-05-31 11:47:38 EDT
Created attachment 22059 [details]
project
Comment 2 Jerome Lanneluc CLA 2005-06-03 09:48:59 EDT
Reproduced. Problem is in JavaModelManager#getWorkingCopies(...). We add the
primary working even if a working copy for the given owner exists.
Comment 3 Philipe Mulet CLA 2005-06-03 11:19:22 EDT
+1 for RC2
Comment 4 Jerome Lanneluc CLA 2005-06-03 11:23:29 EDT
Changed JavaModelManager#getWorkingCopies(...) to not add primary working copies
that have a corresponding working copy with the given owner.

Added regression test BatchASTCreationTests#tes066().
Comment 5 Olivier Thomann CLA 2005-06-07 14:48:31 EDT
Verified in N20050606-0010 + JDT/Core HEAD
Comment 6 Frederic Fusier CLA 2005-06-10 11:03:22 EDT
Verified for 3.1 RC2 using build I20050610-0010