Experiment: Const iterrator range with #[rustc_do_not_const_check]

[onestacked]

TODO / this code will probably be used later in #104100:

• Wait for implement const iterator using rustc_do_not_const_check #106541 to land and be in Boostrap

r? @ghost

[rustbot]

Failed to set assignee to Ghost: invalid assignee

Note: Only org members, users with write permissions, or people who have commented on the PR may be assigned.

[onestacked]

error[E0744]: `?` is not allowed in a `const fn` --> library/core/src/iter/range.rs:438:19 | 438 | res = Step::forward_checked(res, 0x800)?; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

@fee1-dead Do you know why this doesn't work?

[fee1-dead]

Enable #![feature(const_try)]?

[onestacked]

It is enabled in library/core/src/lib.rs

[fee1-dead]

Oh, then the function needs to be const-unstable so it can use unstable const features

EDIT: hmm it is unstable though..

[fee1-dead]

This is probably a bug that needs fixing. The checking for ? is in rustc_passes that operates on the hir, unlike the const checking code we do on MIR. So there might be some complexity in that that doesn't work with rustc_do_not_const_check.

[onestacked]

rustc_do_not_const_check does nothing here since it isn't yet in bootstrap, but i would think that ? should work here anyways.

[onestacked]

And really the body of the Step impl functions should work without #[rustc_do_not_const_check] anyways, I just added it because i thought i might try it.

[onestacked]

This commit now only implements const Step (and the internal RangeIteratorImpl) and that should work without #[rustc_do_not_const_check]

[onestacked]

@fee1-dead Adding #[rustc_allow_const_fn_unstable(const_try)] lets it build, but I think that it should work without that since the Step implementation is rustc_const_unstable (this first commit does not use rustc_do_not_const_check).

Since this is still waiting for rustc_do_not_const_check and I don't think adding more #[cfg(bootstrap)]'s is a good idea I'm marking this as blocked.
@rustbot blocked

[bors]

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