-
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
Properly deal with weak alias types as self types of impls #120780
Conversation
Reminder to myself: Check if the following code leads to a cycle error: #![feature(lazy_type_alias)]
struct I8<const F: i8>;
type Identity<T: ?Sized> = T;
impl Identity<I8<{ i8::MIN }>> {
fn foo(&self) {}
} Guillaume just sent me a document of them that records some issues encountered with the previous pre- |
Update: No, it doesn't lead to cycles. Everything works flawlessly and |
yea, the previous approach used full normalization, which causes issues. Just peeling away the weak aliases works around all of that. Sad that we need these custom normalization routines, but that's kinda the conclusion we always came to when we discussed these cases... |
3e9a8e5
to
1a0323c
Compare
Added an
Yea :/ and I'm pretty sure we need to add more of them if we want to emulate some of the existing behavior of eager type aliases. E.g. for #114220 I bet we don't want to properly normalize either. |
@bors r+ |
@@ -0,0 +1,18 @@ | |||
// check-pass |
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.
These comments now need an @
@bors r- ui tests now use |
🤦 👍 |
Let's wait till green to make sure I didn't mess up the new |
@bors r=oli-obk |
Properly deal with weak alias types as self types of impls Fixes rust-lang#114216. Fixes rust-lang#116100. Not super happy about the two ad hoc “normalization” implementations for weak alias types: 1. In `inherent_impls`: The “peeling”, normalization to [“WHNF”][whnf]: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. [rust-lang#97974](rust-lang#97974) followed the same approach. 2. In `constrained_generic_params`: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize *weak* alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective. Both have ad hoc overflow detection mechanisms. **Coherence** is handled in rust-lang#117164. r? `@oli-obk` or types [whnf]: https://en.wikipedia.org/wiki/Lambda_calculus_definition#Weak_head_normal_form
💔 Test failed - checks-actions |
@bors retry, empty log and possible apple-1 builder timeout |
I think the retry didn't register |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d3df8ff): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 639.783s -> 642.411s (0.41%) |
Expand weak alias types before collecting constrained/referenced late bound regions + refactorings Fixes rust-lang#114220. Follow-up to rust-lang#120780. r? `@oli-obk`
Rollup merge of rust-lang#121344 - fmease:lta-constr-by-input, r=oli-obk Expand weak alias types before collecting constrained/referenced late bound regions + refactorings Fixes rust-lang#114220. Follow-up to rust-lang#120780. r? `@oli-obk`
Fixes #114216.
Fixes #116100.
Not super happy about the two ad hoc “normalization” implementations for weak alias types:
inherent_impls
: The “peeling”, normalization to “WHNF”: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. #97974 followed the same approach.constrained_generic_params
: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize weak alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective.Both have ad hoc overflow detection mechanisms.
Coherence is handled in #117164.
r? @oli-obk or types