Bug 58580 - VariableBinding.getVariableId() returns wrong IDs for nested types
Summary: VariableBinding.getVariableId() returns wrong IDs for nested types
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-14 19:38 EDT by Mirko Raner CLA
Modified: 2004-05-20 17:39 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mirko Raner CLA 2004-04-14 19:38:29 EDT 
The documentation for org.eclipse.jdt.core.dom.IVariableBinding.getVariableId()
explicitly states that "the numbering does not include the local variables
declared within the method's local (or anonymous) types - their ids would be
relative to the methods of the local type".
However, this is apparently not the case. When obtaining an IVariableBinding
from a SimpleName that represents a local variable, the IDs for local variables
inside nested methods are not relative to their directly declaring method (i.e.,
starting at 0) but to the enclosing method (i.e., starting at last ID used in
enclosing method plus one).

I was hoping to solve a certain variable use analysis problem using the variable
ID, but that code depends on getVariableId() working as specified.
Comment 1 Olivier Thomann CLA 2004-04-14 22:46:49 EDT 
Would you have a test case to submit?
Thanks.
Comment 2 Jim des Rivieres CLA 2004-04-29 14:28:45 EDT 
We've looked into this and you're right. The implementation does not honor 
this clause of the spec: "Note that the numbering does not include the local 
variables declared within the method's local (or anonymous) types - their ids 
would be relative to the methods of the local type." Since it has never worked 
this way, and would be some work to make it work that way, we are considering 
dropping this clause from the spec. 

btw, although the implementation currently start variable ids from 0, the 
initial numbering and gap between ids is unspecified. The intent is to provide 
sufficient info to judge relative position and nothing more.

Mirko: would you be able to adjust your analysis algorithm accordingly?
Comment 3 Olivier Thomann CLA 2004-05-19 15:38:23 EDT 
Reconsider post 3.0.
Comment 4 Mirko Raner CLA 2004-05-19 15:47:13 EDT 
Thanks for looking into this.

We were able to work around the bug and use a different approach that does not
depend on getVariableId().
If you decide not to implement the numbering scheme that is advertised, please
make sure that the documentation is updated accordingly, so that no one else
runs into this trap.
Comment 5 Jim des Rivieres CLA 2004-05-19 16:22:28 EDT 
We will drop the clause from the spec. This aligns the spec with what has been 
implemented all along.

This API change approved by PMC from inclusion in 3.0 M9.

Reopening. Olivier, pls verify.
Comment 6 Olivier Thomann CLA 2004-05-19 16:45:06 EDT 
Verified that the note has been removed.
Comment 7 Olivier Thomann CLA 2004-05-20 11:07:41 EDT 
Fixed and released in HEAD.
Comment 8 Olivier Thomann CLA 2004-05-20 17:39:32 EDT 
Verified in 200405201600.