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

Reduce special treatment for zsts #67501

Merged
merged 13 commits into from
Jan 10, 2020
Merged

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Dec 21, 2019

@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 21, 2019
@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 21, 2019

r? @RalfJung

@rust-highfive rust-highfive assigned RalfJung and unassigned eddyb Dec 21, 2019
@rust-highfive

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 23, 2019

☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Dec 25, 2019

☔ The latest upstream changes (presumably #67596) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung
Copy link
Member

This is quite clever! I am conflicted. I don't like the weird condition in try_as_mplace very much, and I don't like how this spreads values obtained by MemPlace::dangling, which I don't feel should even existing in the spec so I wonder why we have a hard time avoiding it here. On the other hand, I do like the simplifications this brings.

The previous uses of dangling, I think, were never actually observable by the program. Basically, what we should never do is call dangling and then later call to_ref. Could you add that in a doc-comment, and at least superficially audit the users of try_as_mplace accordingly?

Do you think there is any chance to also kill the other use of MemPlace::dangling, and then remove the dangling function entirely and inline it into try_as_mplace?

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 26, 2019

There are also two uses of dangling in miri for uses of call_function where the invoked function is statically known to have unit return value.

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 26, 2019

Even if we removed dangling, you could achieve the same effect via

OpTy::from(ImmTy::from(Scalar::zst(), layout)).try_as_mplace()

So I'm not sure what we'd have gained.

@RalfJung
Copy link
Member

There are also two uses of dangling in miri for uses of call_function where the invoked function is statically known to have unit return value.

Two? I remember one, for calling drop. But yeah, there's probably no good replacement for that.

This point still stands, though:

The previous uses of dangling, I think, were never actually observable by the program. Basically, what we should never do is call dangling and then later call to_ref. Could you add that in a doc-comment, and at least superficially audit the users of try_as_mplace accordingly?

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 26, 2019

Two? I remember one, for calling drop. But yeah, there's probably no good replacement for that.

Two in miri, and one in the miri engine (the one for drop)

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 26, 2019

Basically, what we should never do is call dangling and then later call to_ref.

That feels impossible to uphold and I don't see what we'd gain. Do you want to prevent (&() as *const () as usize) / 2 to fail because the value is a pointer but (&*&() as *const () as usize) / 2 to succeed? Because this is I think what would happen with the current PR with the appropriate feature gates.

@RalfJung
Copy link
Member

RalfJung commented Dec 26, 2019

We'd gain not baking these fake dangling pointers into the implemented semantics of the Abstract Machine in an observable way. Or rather, that's a property that we currently have, and I do not want to lose it.

@RalfJung
Copy link
Member

(Dang, looks like GH stopped sending email notifications for force-pushes. So please let me know when this is ready for review again.)

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 26, 2019

We'd gain not baking these fake dangling points into the implemented semantics of the Abstract Machine in an observable way.

I can poison the MemPlace when it is created via dangling and make as_ref panic if the MemPlace is poisoned.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-7 of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-12-26T22:55:28.0677629Z ##[command]git remote add origin https://github.com/rust-lang/rust
2019-12-26T22:55:28.0877646Z ##[command]git config gc.auto 0
2019-12-26T22:55:28.0958304Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2019-12-26T22:55:28.1003323Z ##[command]git config --get-all http.proxy
2019-12-26T22:55:28.1157041Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/67501/merge:refs/remotes/pull/67501/merge

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 27, 2019

I addressed all the review comments.

at least superficially audit the users of try_as_mplace accordingly?

I did the audit and found no problematic cases. All cases are either Operand uses, so we'll definitely read later or write to the memory, but want to have the address back for anything other than getting the backing memory.

@bors

This comment has been minimized.

@RalfJung
Copy link
Member

RalfJung commented Jan 9, 2020

Just a couple nits. r=me with those fixed.

@oli-obk
Copy link
Contributor Author

oli-obk commented Jan 9, 2020

@bors r=RalfJung

@bors
Copy link
Contributor

bors commented Jan 9, 2020

📌 Commit c5c4fa8 has been approved by RalfJung

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 9, 2020
Centril added a commit to Centril/rust that referenced this pull request Jan 10, 2020
Centril added a commit to Centril/rust that referenced this pull request Jan 10, 2020
bors added a commit that referenced this pull request Jan 10, 2020
Rollup of 6 pull requests

Successful merges:

 - #66463 (Point at opaque and closure type definitions in type errors)
 - #67501 (Reduce special treatment for zsts)
 - #67820 (Parse the syntax described in RFC 2632)
 - #67922 (rustc_ast_lowering: misc cleanup & rustc dep reductions)
 - #68071 (Extend support of `_` in type parameters)
 - #68073 (expect `fn` after `const unsafe` / `const extern`)

Failed merges:

r? @ghost
@bors bors merged commit c5c4fa8 into rust-lang:master Jan 10, 2020
@RalfJung
Copy link
Member

@oli-obk Miri broke in a rollup containing this PR, and this seems like the likely culprit. Could you prepare a fixup PR?

@oli-obk
Copy link
Contributor Author

oli-obk commented Jan 10, 2020

on it

@oli-obk oli-obk deleted the test-slice-patterns branch January 10, 2020 09:26
bors added a commit that referenced this pull request Jan 13, 2020
Don't try to force_ptr pointers to zsts

r? @RalfJung

cc @wesleywiser

This is required to fix miri after #67501 broke it. The reason only miri sees this is that it uses validation on values during interpretation and not just on the final value of constants, which never contain such values.
wesleywiser added a commit to wesleywiser/rust that referenced this pull request Feb 21, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Feb 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants