-
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
Implement generic const items #113522
Implement generic const items #113522
Conversation
This comment has been minimized.
This comment has been minimized.
some thoughts without looking at the PR:
It should not,
ideally yes, but I think this is something with can deal with later. Const evaluation with invalid bounds is generally somewhat meh rn and not something you have to deal with in this PR. |
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.
Some preliminary remarks on this PR.
I disagree with @lcnr about splitting into multiple PRs. Having a single PR makes it much easier to check the global consistency of the implementation. The PR is already neatly split into consistent commits, which makes this practical. We can have multiple assigned reviewers on this single PR + 1 coordinating the review.
I'm available for the AST+HIR+nameres part.
tests/ui/suggestions/missing-lifetime-in-assoc-const-type.stderr
Outdated
Show resolved
Hide resolved
It was my understanding that adding a new feature gate only needs a lang team member who's ok with it, not a lang team FCP (MCPs have been discontinued). I also think that this feature is ok to review in one PR, but I will likely ask some general things to happen in other PRs and this one to be rebased over them. |
☔ The latest upstream changes (presumably #113646) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
53d06c1
to
4465212
Compare
const CREATE<T: ~const Create>: T = T::create(); | ||
|
||
pub const K0: i32 = CREATE::<i32>; | ||
pub const K1: i32 = CREATE; // arg inferred | ||
|
||
#[const_trait] | ||
trait Create { | ||
fn create() -> Self; | ||
} | ||
|
||
impl const Create for i32 { | ||
fn create() -> i32 { | ||
4096 | ||
} | ||
} |
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.
impl Create for u32 {
fn create() -> u32 {
println!("foobar");
42
}
}
will probably still compile (modulo the inference example), and then die in const eval. We'll need to interpret ~const
(or just const
) bounds as always-const, instead of maybe-const in const items. This can happen in a follow up though.
cc @fee1-dead
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.
Ooh this is interesting. This should probably happen during astconv when ~const
gets desugared into generic params for the trait. And in this case the generic param should just be host = false
(disabling the host effect thus making this a const trait bound)
I think this would fit nicely into the PR where constness is removed from TraitPredicate
.
Rebased, CI green & none of the PRs rolled up in #114181 (pending) should lead to any kind of conflict 🤞 |
@bors r=cjgillot |
☀️ Test successful - checks-actions |
Finished benchmarking commit (04abc37): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 649.861s -> 649.942s (0.01%) |
@fmease: a few perf regressions there, is that expected? Any ideas how to mitigate them? |
The regressions are somewhat expected (we're doing more work per const item). While I've expected a benchmark like I'm looking into it. Maybe we can short-circuit in some places. |
@rustbot label: +perf-regression-triaged |
Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? `@calebcartwright` or `@ytmimi`
Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? ``@calebcartwright`` or ``@ytmimi``
Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? ```@calebcartwright``` or ```@ytmimi```
Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? ````@calebcartwright```` or ````@ytmimi````
Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? `````@calebcartwright````` or `````@ytmimi`````
Rollup merge of rust-lang#132540 - compiler-errors:gc, r=calebcartwright Do not format generic consts We introduced **nightly support** for generic const items in rust-lang#113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items. r? `````@calebcartwright````` or `````@ytmimi`````
This implements generic parameters and where-clauses on free and associated const items under the experimental feature gate
generic_const_items
. See rust-lang/lang-team#214.Tracking issue: #113521.
Fixes #104400.
This PR doesn't include rustfmt support as per nightly style procedure and it doesn't add rustdoc JSON support (see related Zulip topic).
CC @scottmcm @compiler-errors @WalterSmuts
r? @oli-obk
Resolved Questions
const ADD<const N: usize, const M: usize>: usize = N + M; ADD::<0, 1>
trigger the error generic parameters may not be used in const operations (which can be unlocked with#![feature(generic_const_exprs)]
). Currently it doesn't. Or does this fall under this paragraph?const UNUSED: () = () where String: Copy;
(with#![feature(trivial_bounds)]
and withUNUSED
unused) succeed compilation? Currently it doesn't: evaluation of constant value failed // entering unreachable code