declare_interior_mutable_const, borrow_interior_mutable_const: resolve <T as Trait>::AssocT projections

[GrigorenkoPV]

changelog: [declare_interior_mutable_const, borrow_interior_mutable_const]: resolve <T as Trait>::AssocT projections

---

This came up during rust-lang/rust#130543 where we have <T as AtomicPrimitive>::Assoc = AtomicT instead of just AtomicT and clippy failed to resolve that properly.

This really needs a review, because

• I don't know if try_normalize_erasing_regions is the right thing to call here.
• I'm not sure if I peel off the correct amount of ValTree::Branch layers (I think I do).

Also, shouldn't this lint's infrastructure rely on Freeze trait (rust-lang/rust#121675) instead of hardcoding a list of known-to-be-interior-mutable types?

---

Previously filed this in the main rust repo (rust-lang/rust#136369), was asked to do it here instead (rust-lang/rust#136369 (comment)).

[rustbot]

r? @blyxyas

rustbot has assigned @blyxyas.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[blyxyas]

Also, shouldn't this lint's infrastructure rely on Freeze trait (rust-lang/rust#121675) instead of hardcoding a list of known-to-be-interior-mutable types?

This is a great idea! Would you like to implement it here, in another PR or would you like for someone else (probably me) to implement it?

[GrigorenkoPV]

Also, shouldn't this lint's infrastructure rely on Freeze trait (rust-lang/rust#121675) instead of hardcoding a list of known-to-be-interior-mutable types?

This is a great idea! Would you like to implement it here, in another PR or would you like for someone else (probably me) to implement it?

I think I might give it a try myself, but definitely in a separate PR, because for now I just want to unblock rust-lang/rust#136316

[blyxyas]

Oh I didn't know this was a blocking PR, sorry for the wait. I'll be swift in the reviews then.

[GrigorenkoPV]

Oh I didn't know this was a blocking PR, sorry for the wait. I'll be swift in the reviews then.

No problem, it's nothing urgent. In fact it is not even 100% blocking. We can just avoid using Atomic<T> in places where clippy does not like it for now, because eventually there will be a switch from Atomic<T> being an alias for AtomicT via projections to AtomicT being an alias for Atomic<T> with (afaict) no projections involved.

[blyxyas]

LGTM, thanks! ❤️

For transparency, I had to open a thread on Zulip asking for some assistance because try_normalize_erasing_regions was out of my area of expertise, and with that newly-found knowledge, I think this is a good use of the function.

Also, compiler-errors took a look at this and he also thinks it's fine.

[GrigorenkoPV]

Also, compiler-errors took a look at this and he also thinks it's fine.

Yay, that is reassuring.

---

As for the Freeze, I've opened an issue (#14222) so at least this does not get lost to time. Hopefully, I will be able to work on it in the nearest future. If not, I guess others can claim it.