Bug 110976 - [model] (un)equal bindings with same key for local variables in duplicate methods
Summary: [model] (un)equal bindings with same key for local variables in duplicate met...
Status: CLOSED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-28 14:46 EDT by Markus Keller CLA
Modified: 2019-11-04 20:32 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2005-09-28 14:46:53 EDT
M20050923-1430

A minor problem, but I though I should still file it, since it could become more
interesting when we start applying quick fixes in ASTs with syntax errors.

class Try {
    void m() {
        int local;
        Object obj;
    }
    void m() {
        int local;
        Integer obj;
    }
}

The bindings for the two 'obj' are not idential and not isEqualTo(..) each
other, but they share the same key '#obj'.

The bindings for the two 'local' are not idential, but they are isEqualTo(..)
each other and share the same key '#local'.

Furthermore, getJavaElement() returns null for all 4 variable bindings.

I guess the root problem is that the two methods m() don't have bindings.
Wouldn't it be possible to create
- a normal method binding for the first occurrence of m()
- a different binding for the second m(), where the key contains something like
a !2 as it is done in the second IMethod's handle identifier?
Comment 1 Frederic Fusier CLA 2007-06-19 06:56:06 EDT
Reproduced with 3.3 RC4
Comment 2 Jerome Lanneluc CLA 2007-06-20 06:59:04 EDT
Fix for bug 149590 ensures that the keys for local variables are different.
However the Java element is still null. This is because (as Markus said) the method binding is null.
Need to investigate if we can get a method binding in this case.
Comment 3 Jerome Lanneluc CLA 2008-05-07 07:46:33 EDT
Deferring post 3.4
Comment 4 Eclipse Genie CLA 2019-11-04 20:32:14 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.