address: current `PartialEq` implementation breaks `match`-against-`const` situations

[rustopian]

Problem

The new PartialEq implementation on Address will break match-against-const contexts (incl. in agave here), as StructuralPartialEq can no longer be auto-derived.

This also breaks other similar patterns such as if let against constant.

Rust doesn't allow constants to be used as patterns for matching when PartialEq is hand-implemented - since that could, for example, expose private implementation details.

Solutions

There are a few options here, including these briefly-considered possibilities:

• require dependents to avoid match patterns against constants (and document this), which makes some semantic sense for Address
• restore derive(PartialEq) and move the custom equality logic back behind a separate method/trait, as before
• require dependents wishing to match against constants to use a new simple helper that exposes a #[derive(PartialEq)] type
• assorted solutions that split the type, such as raw and wrapper
• impl StructuralPartialEq, but who knows when that will be stable

For now, I'm adapting agave code when needed, e.g. switching match to if/else or guarded match patterns.

cc @febo @grod220

[febo]

One of the solutions is to improve the code generation when the default PartialEq is used. 😊

cc: @LucasSte

[rustopian]

One of the solutions is to improve the code generation when the default PartialEq is used. 😊

Woot, of course. That will make this issue moot.

[LucasSte]

One of the solutions is to improve the code generation when the default PartialEq is used. 😊

cc: @LucasSte

I'll investigate what's wrong there after finishing the Rust 1.89 upgrade: anza-xyz/rust#140.

[joncinque]

I'm wondering if it makes more sense to revert the PartialEq change for now to avoid this breakage. If the compiler can do the right thing with not too much work, this would save the headache of breaking agave or any other downstream user

[febo]

I'm wondering if it makes more sense to revert the PartialEq change for now to avoid this breakage. If the compiler can do the right thing with not too much work, this would save the headache of breaking agave or any other downstream user

Agree, reverting the change makes sense. Should we add a stand-alone address_eq helper like the way it works on pinocchio?

[joncinque]

Should we add a stand-alone address_eq helper like the way it works on pinocchio?

Yeah that makes sense to me!