Constifying large traits in libstd (i.e. `Iterator`)

[compiler-errors]

• Allow const iterator implementations rust#102225
• implement const iterator using rustc_do_not_const_check rust#106541
• Remove do_not_const_check from Iterator methods rust#132368

My understanding is that constifying iterator currently required constifying all of its extension methods. That was a lot of work.

Instead, we just slapped rustc_do_not_const_check onto all the methods, somewhat leaving us vulnerable to CTFE errors "post-mono" if any of the combinators ended up doing anything non-const.

Instead of doing this, we probably could introduce something like rustc_non_const_trait_method that forces a specific method to be non-const in a const trait.

This means we don't need to work towards constifying all of the combinators all at once. Then when we constify iterator, we can initially slap #[rustc_non_const_trait_method] on every combinator, and slowly work to peel them off until the trait is fully constified.

[Aloso]

Then when we constify iterator, we can initially slap #[rustc_non_const_trait_method] on every combinator, and slowly work to peel them off until the trait is fully constified.

This means that implementing const Iterator has to be forbidden outside the standard library at first. Otherwise, removing a #[rustc_non_const_trait_method] attribute would be a breaking change.

[compiler-errors]

Well, nothing is breaking on nightly. I don't think I clear when I posted this issue, but I only suggested this for experimentation purposes. By the time we stabilize const traits we'd have to get rid of it.

[RalfJung]

Instead, we just slapped rustc_do_not_const_check onto all the methods, somewhat leaving us vulnerable to CTFE errors "post-mono" if any of the combinators ended up doing anything non-const.

I am fairly strongly opposed to that strategy. The attribute exists for use by the panic hooks and should not be used for anything else.