-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Allow using generic trait methods in const fn
#79287
Conversation
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
This is absolutely great! A few points for clarity:
|
I've added more tests, but I'm not sure what you mean by this:
|
I added some text about the issue of using types that do not @bors r+ |
📌 Commit cb40684 has been approved by |
Do we have tests to ensure that this only works when a feature flag is set? |
We have https://github.com/rust-lang/rust/blob/6af388b25050bca26710be7e4030e17bf6d8d2f7/src/test/ui/rfc-2632-const-trait-impl/feature-gate.rs, but that only checks for impls, not actually using them. |
There are no const impls in libcore/std, so using one currently also requires defining one. I'll add a note to the tracking issue. |
…=oli-obk Allow using generic trait methods in `const fn` Next step for rust-lang#67792, this now also allows code like the following: ```rust struct S; impl const PartialEq for S { fn eq(&self, _: &S) -> bool { true } } const fn equals_self<T: PartialEq>(t: &T) -> bool { *t == *t } pub const EQ: bool = equals_self(&S); ``` This works by threading const-ness of trait predicates through trait selection, in particular through `ParamCandidate`, and exposing it in the resulting `ImplSource`. Since this change makes two bounds `T: Trait` and `T: ?const Trait` that only differ in their const-ness be treated like different bounds, candidate winnowing has been changed to drop the `?const` candidate in favor of the const candidate, to avoid ambiguities when both a const and a non-const bound is present.
…as-schievink Rollup of 10 pull requests Successful merges: - rust-lang#76829 (stabilize const_int_pow) - rust-lang#79080 (MIR visitor: Don't treat debuginfo field access as a use of the struct) - rust-lang#79236 (const_generics: assert resolve hack causes an error) - rust-lang#79287 (Allow using generic trait methods in `const fn`) - rust-lang#79324 (Use Option::and_then instead of open-coding it) - rust-lang#79325 (Reduce boilerplate with the `?` operator) - rust-lang#79330 (Fix typo in comment) - rust-lang#79333 (doc typo) - rust-lang#79337 (Use Option::map instead of open coding it) - rust-lang#79343 (Add my (`@flip1995)` work mail to the mailmap) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I think if you write the keywords in the wrong order "const impl PartialEq for S {" the compiler could give a bit better error message. |
See also: #79378 |
…trochenkov Recover on `const impl<> X for Y` `@leonardo-m` mentioned that `const impl Foo for Bar` could be recovered from in rust-lang#79287. I'm not sure about the error strings as they are, I think it should probably be something like the error that `expected_one_of_not_found` makes + the suggestion to flip the keywords, but I'm not sure how exactly to do that. Also, I decided not to try to handle `const unsafe impl` or `unsafe const impl` cause I figured that `unsafe impl const` would be pretty rare anyway (if it's even valid?), and it wouldn't be worth making the code more messy.
Is something like this supposed to work with this PR? Or is that something which might get implemented in a later stage? :) impl<T, U> const Into<U> for T
where
U: From<T>,
{
fn into(self) -> U {
U::from(self)
}
} I currently get this error
|
This is unimplemented as of now, but being looked into since around a week |
Oh, sorry. Thanks :) |
Next step for #67792, this now also allows code like the following:
This works by threading const-ness of trait predicates through trait selection, in particular through
ParamCandidate
, and exposing it in the resultingImplSource
.Since this change makes two bounds
T: Trait
andT: ?const Trait
that only differ in their const-ness be treated like different bounds, candidate winnowing has been changed to drop the?const
candidate in favor of the const candidate, to avoid ambiguities when both a const and a non-const bound is present.