-
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
Don't promote to 'static the result of dereferences. #47408
Conversation
Don't promote to 'static the result of dereferences. **DO NOT MERGE** *(yet)* This is a **breaking change**, removing copies out of dereferences from rvalue-to-`'static` promotion. With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a `static`) or even if it can be interpreted (e.g. integer pointers). The alternative to this ban is defining at least *some* of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion. I'm primarily opening this PR with a conservative first approximation (e.g. `&(*r).a` is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering. r? @nikomatsakis
☀️ Test successful - status-travis |
@rust-lang/infra Can I get a crater run on this? |
Crater run started (3ish hours ago, actually). |
@Mark-Simulacrum results available? |
Probably Tuesday mid-day or Wednesday unfortunately; we have problems with crater downloading the wrong CI artifacts that took a couple days to resolve. Crater claims 22 hours left, but I don't really believe it. |
@Mark-Simulacrum Update, please? |
We have not yet resolved some problem in crater that uses us all available disk space. The problem hasn't been identified, so until it is, we can't move forward unfortunately. |
We've bitten the bullet and have got a disk with much more space - I anticipate the run succeeding now (just started). |
At long last! Crater results: http://cargobomb-reports.s3.amazonaws.com/pr-47408/index.html. 'Blacklisted' crates (spurious failures etc) can be found here. If you see any spurious failures not on the list, please make a PR against that file. |
Looks like all regressions are spurious |
@rfcbot pr merge I'm proposing to merge this PR, retroactively restricting rvalue-to- |
Team member @eddyb has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
Nominating so that I can badger @rust-lang/lang members into checking their boxes. |
I checked for @nrc -- on the premise that he is not objecting but just busy. |
Out of curiosity, can you give a small self-contained example of something that gets broken by this? |
💔 Test failed - status-appveyor |
⌛ Testing commit 121499a with merge 24a82a987f9f716fad83088470137c38badfc4c1... |
💔 Test failed - status-appveyor |
⌛ Testing commit 121499a with merge b6c10e42efef10877fc43c26a5712cd7f78d9533... |
💔 Test failed - status-travis |
@bors retry |
Don't promote to 'static the result of dereferences. This is a **breaking change**, removing copies out of dereferences from rvalue-to-`'static` promotion. With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a `static`) or even if it can be interpreted (e.g. integer pointers). One alternative to this ban is defining at least *some* of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion. **EDIT**: The other *may seem* to be to add some analysis which whitelists references-to-constant-values and assume any values produced by arbitrary computation to not be safe to promote dereferences thereof - but that means producing a reference from an associated constant or `const fn` would necessarily obscure it, and in the former case, this could still impact code that runs on stable today. What we do today to track "references to statics" only works because we restrict taking a reference to a `static` at all to other `static`s (which, again, are currently limited in that they can't be read at compile-time) and to runtime-only `fn`s (*not* `const fn`s). I'm primarily opening this PR with a conservative first approximation (e.g. `&(*r).a` is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering. r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
@nikomatsakis Maybe worth taking off the tags (especially FCP) now that this is closed/merged... unless there's a reason it should still be open? :) |
This is a breaking change, removing copies out of dereferences from rvalue-to-
'static
promotion.With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a
static
) or even if it can be interpreted (e.g. integer pointers).One alternative to this ban is defining at least some of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion.
EDIT: The other may seem to be to add some analysis which whitelists references-to-constant-values and assume any values produced by arbitrary computation to not be safe to promote dereferences thereof - but that means producing a reference from an associated constant or
const fn
would necessarily obscure it, and in the former case, this could still impact code that runs on stable today. What we do today to track "references to statics" only works because we restrict taking a reference to astatic
at all to otherstatic
s (which, again, are currently limited in that they can't be read at compile-time) and to runtime-onlyfn
s (notconst fn
s).I'm primarily opening this PR with a conservative first approximation (e.g.
&(*r).a
is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering.r? @nikomatsakis