Skip to content
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

Merged
merged 1 commit into from Feb 17, 2018

Conversation

@eddyb
Copy link
Member

eddyb commented Jan 13, 2018

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 statics (which, again, are currently limited in that they can't be read at compile-time) and to runtime-only fns (not const fns).

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

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Jan 13, 2018

cc @rust-lang/lang @Kimundi - we didn't catch this before stabilization, will have to make a decision.

@bors try

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 13, 2018

⌛️ Trying commit 121499a with merge e15dd17...

bors added a commit that referenced this pull request Jan 13, 2018
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
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 13, 2018

☀️ Test successful - status-travis
State: approved= try=True

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Jan 13, 2018

@rust-lang/infra Can I get a crater run on this?

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 17, 2018

Crater run started (3ish hours ago, actually).

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jan 22, 2018

@Mark-Simulacrum results available?

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 22, 2018

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.

@alexreg

This comment has been minimized.

Copy link
Contributor

alexreg commented Jan 26, 2018

@Mark-Simulacrum Update, please?

@Mark-Simulacrum

This comment has been minimized.

Copy link
Member

Mark-Simulacrum commented Jan 26, 2018

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.

@aidanhs

This comment has been minimized.

Copy link
Member

aidanhs commented Jan 31, 2018

We've bitten the bullet and have got a disk with much more space - I anticipate the run succeeding now (just started).

@aidanhs

This comment has been minimized.

Copy link
Member

aidanhs commented Feb 4, 2018

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.

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Feb 4, 2018

Looks like all regressions are spurious

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Feb 4, 2018

@aidanhs @kennytm Thanks! I agree that there appear to only be spurious regressions.
This PR can only cause less code to compile, but there's no regressions due to compile errors.

@eddyb

This comment has been minimized.

Copy link
Member Author

eddyb commented Feb 4, 2018

@rfcbot pr merge

I'm proposing to merge this PR, retroactively restricting rvalue-to-'static promotion to not promote any copy through a dereference (for which we'd need intrusive points-to analyses post-miri).

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Feb 4, 2018

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.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Feb 6, 2018

Nominating so that I can badger @rust-lang/lang members into checking their boxes.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Feb 8, 2018

I checked for @nrc -- on the premise that he is not objecting but just busy.

@aidanhs

This comment has been minimized.

Copy link
Member

aidanhs commented Feb 8, 2018

Out of curiosity, can you give a small self-contained example of something that gets broken by this?

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 16, 2018

💔 Test failed - status-appveyor

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Feb 16, 2018

@bors retry #46903

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 16, 2018

⌛️ Testing commit 121499a with merge 24a82a9...

bors added a commit that referenced this pull request Feb 16, 2018
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
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 16, 2018

💔 Test failed - status-appveyor

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Feb 16, 2018

@bors retry #46903

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 16, 2018

⌛️ Testing commit 121499a with merge b6c10e4...

bors added a commit that referenced this pull request Feb 16, 2018
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
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 16, 2018

💔 Test failed - status-travis

@kennytm

This comment has been minimized.

Copy link
Member

kennytm commented Feb 17, 2018

@bors retry

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 17, 2018

⌛️ Testing commit 121499a with merge 5313e87...

bors added a commit that referenced this pull request Feb 17, 2018
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
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 17, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 5313e87 to master...

@bors bors merged commit 121499a into rust-lang:master Feb 17, 2018
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@alexreg

This comment has been minimized.

Copy link
Contributor

alexreg commented Feb 19, 2018

@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? :)

@eddyb eddyb deleted the eddyb:deref-danger branch Feb 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.