rustc_skip_during_method_dispatch: decouple receiver & edition

[GrigorenkoPV]

• Removes the implicit assumption that arrays are gated behind edition 2021, and boxed slices behind 2024.
• Addresses // FIXME: We could probably do way better attribute validation here.
• Abstracts array and boxed_slice away to a GatedReceiver enum, offering a more convenient extension point for when we run into the "add this impl now, but gate the method call syntax behind an edition" situation again.
• Instead of having a bool field for each possible receiver store a vec¹ of all Receiver + Edition pairs.
• Stable MIR now has a #[non_exhaustive] enum for Editions.

Would be cool if this attribute could be applied inside of an impl instead of to the entire trait declaration. This would eliminate the need for the receiver in the first place. But that's either something that had already been tried and failed, or a story for another day.

Footnotes

1. An alternative would be to use a HashMap from receivers to editions, but 99.999% of the time it would be empty (currently IntoIterator is the only trait in existence to have this attribute) and the remaining 0.001% it has like two elements, so any asymptotic improvements would probably be crushed by the constant multiplier. Also ThinVec is just 1 pointer wide, while FxHashMap is 4, IIRC. A bit wasteful. ↩

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
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

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

[compiler-errors]

Thanks for putting in the effort for generalizing this attribute, but given its inherently hacky nature, I personally don't believe it warrants generalization at the moment. I think the right point at which to decide is when we add another hack implementation in edition 2027, since there's no guarantee that this change is actually well suited for whatever receiver/trait pair we'd need to apply this to next, and the current design is suitable for the two existing implementations at moment.

[GrigorenkoPV]

Sounds reasonable.

I will look into whether it is possible to move this from trait declarations to implementations, as this might reduce the "hackiness". But it is probably very not trivial, because otherwise it would've likely already been done. But until then,

[bors]

☔ The latest upstream changes (presumably #130016) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

since this is now in draft status, i'll move it back to waiting-on-author

@rustbot author

[Dylan-DPC]

@GrigorenkoPV any updates of this?

[GrigorenkoPV]

@GrigorenkoPV any updates of this?

I initially created this as a step forward to #129872, which, similarly to IntoIter for [T; N] would have to gate method calls behind an edition, in this case, the 2027 edition (or whatever it will be called), which is different from the currently hardcoded 2021 edition for arrays.

However, #129872 should probably go through an ACP first, which I am yet to write.

(Then the ACP itself will probably also take ages to get accepted/declined.)

[Dylan-DPC]

@GrigorenkoPV thanks. I'm going to close this then since this is blocked on a pr that requires an ACP to be written and merged and that's going to take a while which could cause this to bitrot.