-
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
Supress niches in coroutines to avoid aliasing violations #129313
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
I'm of the opinion that we do the latter (fix the tests, fix it the right way later when we can). But also it would be nice if we actually knew how bad this would affect layout sizes in practice... I have no idea how to gather that information, though. |
I blessed the failing tests. async-drop for some reason seems quite badly affected. But that is an unstable feature. |
Since we haven't heard from our reviewer, let's re-roll. Also maybe it helps to get more people to take a look -- this is primarily about |
I wanna think about this so r? compiler-errors please bother me if i dont review this in a few days!! |
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.
Yeah, this seems necessary to do until we implement UnsafePinned
correctly. I guess if people complain about this, we could gate this behind miri or something.
@bors r+ rollup=never |
…r-errors Supress niches in coroutines to avoid aliasing violations As mentioned [here](rust-lang#63818 (comment)), using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes [Miri errors in practice](rust-lang/miri#3780). The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we *do* use niches in coroutines. So I see two options: - We guard this behavior behind a `-Z` flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence... - (What this PR does right now.) We temporarily adjust the coroutine layout logic and the associated tests until the proper fix lands. The "proper fix" here is to wrap fields that other fields can point to in [`UnsafePinned`](rust-lang#125735) and make `UnsafePinned` suppress niches; that would then still permit using niches of *other* fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable. `@compiler-errors` any opinion? Also who else should be Cc'd here?
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
…r-errors Supress niches in coroutines to avoid aliasing violations As mentioned [here](rust-lang#63818 (comment)), using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes [Miri errors in practice](rust-lang/miri#3780). The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we *do* use niches in coroutines. So I see two options: - We guard this behavior behind a `-Z` flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence... - (What this PR does right now.) We temporarily adjust the coroutine layout logic and the associated tests until the proper fix lands. The "proper fix" here is to wrap fields that other fields can point to in [`UnsafePinned`](rust-lang#125735) and make `UnsafePinned` suppress niches; that would then still permit using niches of *other* fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable. `@compiler-errors` any opinion? Also who else should be Cc'd here?
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (7f4b270): 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)Results (primary -0.9%)This 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: 757.221s -> 754.658s (-0.34%) |
Relevant upstream PR: rust-lang/rust#129313: Supress niches in coroutines to avoid aliasing violations #129313 Resolves #3512 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
As mentioned here, using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes Miri errors in practice.
The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we do use niches in coroutines. So I see two options:
-Z
flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence...UnsafePinned
and makeUnsafePinned
suppress niches; that would then still permit using niches of other fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable.@compiler-errors any opinion? Also who else should be Cc'd here?