Skip to content

Miri: unsized locals and by-value dyn traits #59780

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 7 commits into from
Apr 11, 2019

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Apr 7, 2019

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 7, 2019
RalfJung added 2 commits April 8, 2019 10:29
typos

Co-Authored-By: RalfJung <post@ralfj.de>
@oli-obk
Copy link
Contributor

oli-obk commented Apr 8, 2019

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 8, 2019

📌 Commit 4d79d39 has been approved by oli-obk

@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-review Status: Awaiting review from the assignee but also interested parties. labels Apr 8, 2019
Centril added a commit to Centril/rust that referenced this pull request Apr 8, 2019
@RalfJung
Copy link
Member Author

@bors p=1 needed to make Miri work again

Miri's toolstate is green but that is a bug.

@bors
Copy link
Collaborator

bors commented Apr 11, 2019

⌛ Testing commit 4d79d39 with merge 3de0106...

bors added a commit that referenced this pull request Apr 11, 2019
Miri: unsized locals and by-value dyn traits

r? @oli-obk
Cc @eddyb

Fixes rust-lang/miri#449
// We have to implement all "object safe receivers". Currently we
// support built-in pointers (&, &mut, Box) as well as unsized-self. We do
// not yet support custom self types.
// Also see librustc_codegen_llvm/abi.rs and librustc_codegen_llvm/mir/block.rs.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These paths may be outdated.

@bors
Copy link
Collaborator

bors commented Apr 11, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: oli-obk
Pushing 3de0106 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 11, 2019
@bors bors merged commit 4d79d39 into rust-lang:master Apr 11, 2019
@rust-highfive
Copy link
Contributor

📣 Toolstate changed by #59780!

Tested on commit 3de0106.
Direct link to PR: #59780

💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Apr 11, 2019
Tested on commit rust-lang/rust@3de0106.
Direct link to PR: <rust-lang/rust#59780>

💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
@RalfJung RalfJung deleted the miri-unsized branch June 10, 2019 11:04
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 6, 2022
…i-obk

interpret: remove support for unsized_locals

I added support for unsized_locals in rust-lang#59780 but the current implementation is a crude hack and IMO definitely not the right way to have unsized locals in MIR. It also [causes problems](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Missing.20Layout.20Check.20in.20.60interpret.2Foperand.2Ers.60.3F). and what codegen does is unsound and has been for years since clearly nobody cares (so I hope nobody actually relies on that implementation and I'll be happy if Miri ensures they do not). I think if we want to have unsized locals in Miri/MIR we should add them properly, either by having a `StorageLive` that takes metadata or by having an `alloca` that returns a pointer (making the ptr indirection explicit) or something like that.

So, this PR removes the `LocalValue::Unallocated` hack. It adds `Immediate::Uninit`, for several reasons:
- This lets us still do fairly little work in `push_stack_frame`, in particular we do not actually have to create any allocations.
- If/when I remove `ScalarMaybeUninit`, we will need something like this to have an "optimized" representation of uninitialized locals. Without this we'd have to put uninitialized integers into the heap!
- const-prop needs some way to indicate "I don't know the value of this local'; it used to use `LocalValue::Unallocated` for that, now it can use `Immediate::Uninit`.

There is still a fundamental difference between `LocalValue::Unallocated` and `Immediate::Uninit`: the latter is considered a regular local that you can read from and write to, it just has a more optimized representation when compared with an actual `Allocation` that is fully uninit. In contrast, `LocalValue::Unallocated`  had this really odd behavior where you would write to it but not read from it. (This is in fact what caused the problems mentioned above.)

While at it I also did two drive-by cleanups/improvements:
- In `pop_stack_frame`, do the return value copying and local deallocation while the frame is still on the stack. This leads to better error locations being reported. The old errors were [sometimes rather confusing](https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Cron.20Job.20Failure.202022-06-24/near/287445522).
- Deduplicate `copy_op` and `copy_op_transmute`.

r? `@oli-obk`
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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