-
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
Add Clause::ConstArgHasType
#107965
Add Clause::ConstArgHasType
#107965
Conversation
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
bef61ae
to
68f6757
Compare
@bors try @rust-timer queue |
⌛ Trying commit 68f67579fdf91a0bdd108d513284bc0a9b6b0bdb with merge e660dc534275dfd10344eb9e5571f2003dc9001a... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (e660dc534275dfd10344eb9e5571f2003dc9001a): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never 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.
CyclesThis benchmark run did not return any relevant results for this metric. |
68f6757
to
76bf2e9
Compare
76bf2e9
to
944a84e
Compare
r? @compiler-errors although i have not yet had a chance to look over the diff so it probably is a little not great :< |
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.
Thanks @BoxyUwU
r=me after couple of nits
944a84e
to
dda8def
Compare
@bors r=compiler-errors |
📌 Commit dda8defca37ba66a11982511897835e559cd680b has been approved by It is now in the queue for this repository. |
dda8def
to
90c8d6b
Compare
@bors r=compiler-errors CI failed because the PR making |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (f4f5fc3): comparison URL. Overall result: ❌ regressions - no action needed@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.
CyclesThis benchmark run did not return any relevant results for this metric. |
This comment has been minimized.
This comment has been minimized.
…, r=BoxyUwU Suppress copy impl error when post-normalized type references errors Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization. ---- The const-generics test regressed recently due to rust-lang#107965, cc `@BoxyUwU.` * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails. * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
…, r=BoxyUwU Suppress copy impl error when post-normalized type references errors Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization. ---- The const-generics test regressed recently due to rust-lang#107965, cc ``@BoxyUwU.`` * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails. * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
…, r=BoxyUwU Suppress copy impl error when post-normalized type references errors Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization. ---- The const-generics test regressed recently due to rust-lang#107965, cc ```@BoxyUwU.``` * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails. * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
…, r=BoxyUwU Suppress copy impl error when post-normalized type references errors Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization. ---- The const-generics test regressed recently due to rust-lang#107965, cc ````@BoxyUwU.```` * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails. * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
…, r=BoxyUwU Suppress copy impl error when post-normalized type references errors Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization. ---- The const-generics test regressed recently due to rust-lang#107965, cc `````@BoxyUwU.````` * I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails. * It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
Currently the way that we check that a const arg has the correct type for the const param it is an argument for is by setting the expected type of
typeck
on the anon const of the argument to be the const param's type.In the future for a potential
min_generic_const_exprs
we will allow providing const arguments that do not have an associated anon const that can be typeck'd which will require us to actually check that the const argument has the correct type. While it would potentially be possible to just calleq
when creating substs this would not work if we support generics of the formconst N: T, T
(the const parameters type referencing generics declared after itself).Additionally having
ConstArgHasType
will allow us to potentially make progress on removing thety
field ofConst
which may be desirable. Once progress has been made on this,ConstArgHasType
will also be helpful in ensuring we do not make mistakes in trait/impl checking by declaring functions with the wrong const parameter types as the checks that the param env is compatible would catch it. (We have messed this up in the past, and with generic const parameter types these checks will get more complex)There is a document about the types of const generics that may provide some general information on this subject
This PR shouldn't have any impact on whether code compiles or not on stable, it primarily exists to make progress on unstable const generics features that are desirable.