[Soot-list] JimpleLocal.equals()

[Patrick Lam]

On 01/29/13 06:51, Michael Faes wrote:
> Thank you for your answers. If equivTo() is used for things like
> subexpression elimination, the current implementation makes sense. It
> would be nice if this fact was documented, but oh well.
>
> But what about equals()? I use JimpleLocals (or objects that build on
> top of them) in HashSets and -Maps and it's very counter-intuitive to
> have multiple objects with exactly the same structure (and therefore the
> same string representation) in those sets.

Yes, it's disconcerting. But the alternative results in incorrect code 
at the compiler level.

> Anyway, I just changed the implementation in my copy of Soot and it
> doesn't seem to cause any trouble, so I'm fine. But I think it would be
> more intuitive (meaning less surprising and therefore better) if
> equals() was structure-based and (if desired) the fact that two local
> variables with the same name can be different was reflected in the
> structure.

That would be incompatible with the popular use-original-names option, 
unless we were to add another field to disambiguate local variables with 
the same name. Then we'd have to make sure that we always maintained 
that invariant. Sounds like another source of bugs to me.

pat