-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature gates for for
and ?
in consts
#87237
Conversation
This comment has been minimized.
This comment has been minimized.
maybe #86857 helps here? |
In theory, yeah, this works: #![feature(const_refs_to_cell)]
#![feature(const_mut_refs)]
#![feature(const_fn_trait_bound)]
#![feature(const_trait_impl)]
trait Iter: Copy + Sized {
type Item: Copy;
fn next(&mut self) -> Option<Self::Item>;
#[default_method_body_is_const]
fn count(mut self) -> usize {
let mut count = 0;
while self.next().is_some() {
count += 1;
}
count
}
}
#[derive(Copy, Clone)]
struct ConstIter {
next: Option<u8>,
}
impl const Iter for ConstIter {
type Item = u8;
fn next(&mut self) -> Option<u8> {
match self.next {
Some(val) => {
self.next = val.checked_add(1);
Some(val)
}
None => None,
}
}
}
const _: () = {
let c = ConstIter { next: Some(0) }.count();
if c != 256 {
[()][4];
}
}; ...but it requires a lot of feature gates and |
Then I would say we don't add a const_for feature gate, we can start figuring out const iterators without it. |
But we'll need one eventually, right? Why not add it now? |
Yea. Just right now it doesn't really get us anything actionable. I guess as long as we have a canary test showing the behaviour of the feature gate it should be ok to have an unusable feature gate. Just thought it unusual. |
☔ The latest upstream changes (presumably #83484) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #86998) made this pull request unmergeable. Please resolve the merge conflicts. |
#86853 is a PR which might have some overlap with the try-operator part of this. My goal there was to try and constify the most trivial conversion impls to enable basic usage with |
Yes, these tracking issues are pretty hard to discover |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants | ||
--> $DIR/const-for.rs:5:14 | ||
| | ||
LL | for _ in 0..5 {} | ||
| ^^^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should start printing the function's name in the diagnostic. Very uninformative this error XD
@bors r+ |
📌 Commit c5a29f9 has been approved by |
☀️ Test successful - checks-actions |
Constify ?-operator for Result and Option Try to make `?`-operator usable in `const fn` with `Result` and `Option`, see rust-lang#74935 . Note that the try-operator itself was constified in rust-lang#87237. TODO * [x] Add tests for const T -> T conversions * [x] cleanup commits * [x] Remove `#![allow(incomplete_features)]` * [?] Await decision in rust-lang#86808 - I'm not sure * [x] Await support for parsing `~const` in bootstrapping compiler * [x] Tracking issue(s)? - rust-lang#88674
These operations seems relatively straightforward to support, and only seem to be blocked on
impl const Trait
.I have included a working test for
const_try
, butconst_for
is currently unusable without reimplementing every single defaultedIterator
method, so I didn't do that.(both features still need tracking issues before this is merged)