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

Deduplicate some code between miri and const prop #64419

Merged
merged 15 commits into from
Sep 28, 2019

Conversation

wesleywiser
Copy link
Member

@rust-highfive

This comment has been minimized.

src/librustc_mir/interpret/eval_context.rs Outdated Show resolved Hide resolved
src/librustc_mir/interpret/place.rs Outdated Show resolved Hide resolved
src/librustc_mir/interpret/step.rs Outdated Show resolved Hide resolved
@rust-highfive

This comment has been minimized.

@bors

This comment has been minimized.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 13, 2019
@wesleywiser wesleywiser force-pushed the const_prop_use_ecx branch 2 times, most recently from cfd0efd to 13bb10a Compare September 14, 2019 11:18
@oli-obk
Copy link
Contributor

oli-obk commented Sep 14, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Sep 14, 2019

📌 Commit 13bb10a17c2572b0c5ecdda9aad4f792c300c28a 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 14, 2019
@rust-highfive

This comment has been minimized.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 14, 2019

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 14, 2019
@wesleywiser
Copy link
Member Author

Fixed by adding #![allow(const_err)] to the offending run-fail tests.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 14, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Sep 14, 2019

📌 Commit 0b333ef 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 14, 2019
Centril added a commit to Centril/rust that referenced this pull request Sep 14, 2019
…li-obk

Deduplicate some code between miri and const prop

r? @oli-obk
@Centril
Copy link
Contributor

Centril commented Sep 14, 2019

Failed in #64461 (comment), @bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 14, 2019
@wesleywiser
Copy link
Member Author

I think I understand what's going on but not what to do about it:

  • The ICE is happening on wasm32-unkown-unknown
  • The ICE occurs when we we process this MIR statement: _4 = &mut (_1.1: core::option::Option<process::ChildStdin>)
  • process:ChildStdin is just an AnonPipe

    rust/src/libstd/process.rs

    Lines 230 to 232 in 60895fd

    pub struct ChildStdin {
    inner: AnonPipe
    }
  • AnonPipe is an uninhabited Void type on wasm32
    pub struct AnonPipe(Void);
  • So InterpCx::mplace_field(base, field) sees this as base.layout
TyLayout { 
    ty: process:Child,
    details: LayoutDetails { 
        variants: Single { index: 0 }, 
        fields: Union(0), 
        abi: Uninhabited, 
        largest_niche: None, 
        align: AbiAndPrefAlign { abi: Align { pow2: 0 }, pref: Align { pow2: 0} }, size: Size { raw: 0 } 
}

@oli-obk
Copy link
Contributor

oli-obk commented Sep 16, 2019

Heh, that's a bug in the miri engine. The reason we never encountered it before (and never will in const eval) is that we have very few tests around the various ways to do UB in const eval.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=eaade80ea70ed29998b57c9aa11e4050 shows the ICE on stable. I'll open an issue and we'll fix it there. Until then... a possible workaround may be to remove variables of uninhabited type from the list of variables to const prop

@bors
Copy link
Contributor

bors commented Sep 28, 2019

⌛ Testing commit dd486dd with merge ab3bd45112a1ac58136d4f6aa2cbcbf672450299...

Centril added a commit to Centril/rust that referenced this pull request Sep 28, 2019
…li-obk

Deduplicate some code between miri and const prop

r? @oli-obk
@Centril
Copy link
Contributor

Centril commented Sep 28, 2019

@bors retry rolled up... (don't ask why...)

@bors
Copy link
Contributor

bors commented Sep 28, 2019

⌛ Testing commit dd486dd with merge a6f3ffb269ab0e067c2df49e118a13fc037be236...

@wesleywiser
Copy link
Member Author

I fixed the mir-opt test that was failing on the noopt builder and ran the rest of the test suite locally with optimize-test = false and didn't see any other errors.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 28, 2019

@bors r+

@bors
Copy link
Contributor

bors commented Sep 28, 2019

📌 Commit ba2d6c4 has been approved by oli-obk

@@ -1,3 +1,5 @@
// compile-flags: -O
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this warn in debug mode too?

Copy link
Member

Choose a reason for hiding this comment

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

@oli-obk Just in case this has been overlooked: we should always run the constant-folding pass and only commit the results when optimizations are enabled (although maybe we shouldn't care about optimization level at all?).

Copy link
Contributor

Choose a reason for hiding this comment

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

That's what we do, the differences arise because the MIR differs and thus different lints are reported

@bors
Copy link
Contributor

bors commented Sep 28, 2019

⌛ Testing commit ba2d6c4 with merge 488381c...

bors added a commit that referenced this pull request Sep 28, 2019
Deduplicate some code between miri and const prop

r? @oli-obk
@bors
Copy link
Contributor

bors commented Sep 28, 2019

☀️ Test successful - checks-azure
Approved by: oli-obk
Pushing 488381c to master...

@@ -389,6 +389,10 @@ pub enum UnsupportedOpInfo<'tcx> {
/// Free-form case. Only for errors that are never caught!
Unsupported(String),

/// FIXME(#64506) Error used to work around accessing projections of
/// uninhabited types.
UninhabitedValue,
Copy link
Member

Choose a reason for hiding this comment

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

Why is "unsupported" the right category for this?

Copy link
Member Author

Choose a reason for hiding this comment

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

To me, it seemed similar to some of the other "unsupported" cases like ReadForeignStatic, NoMirFor, DerefFunctionPointer, OutOfTls etc in that it represents allowed behavior in a valid program that simply isn't implemented (or can't be implemented) in miri. I dismissed InvalidProgramInfo because this doesn't indicate an invalid program, however reading the doc comment, it sounds like that may actually be a more appropriate classification. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

Looks like @oli-obk is already working on removing this again so whatever.

frame.locals[local].access()
}

/// Called before a `StaticKind::Static` value is accessed.
Copy link
Member

Choose a reason for hiding this comment

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

Please specify what "access" means here. Is this called when the address of a static is taken? Or just on reads/writes?

Copy link
Member Author

Choose a reason for hiding this comment

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

I will double check and improve the comment in the other open PR I have but I believe this is just on reads/writes.

@@ -132,7 +132,7 @@ impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> {
///
/// There is no separate `eval_rvalue` function. Instead, the code for handling each rvalue
/// type writes its results directly into the memory specified by the place.
fn eval_rvalue_into_place(
pub fn eval_rvalue_into_place(
Copy link
Member

@RalfJung RalfJung Oct 9, 2019

Choose a reason for hiding this comment

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

Oh, why this? We're trying to keep a clean interface for the interpreter, that'll never work if everyone just adds pub whenever they feel like it. :(

Copy link
Member

Choose a reason for hiding this comment

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

Looking at the const_prop changes, it seems like what happened is that const_prop moved up a layer or two of the interpreter abstractions. Shouldn't that mean that while some new operations need to be public now, some of the previously used one can be made private? If you could scan the functions that const_prop no longer needs and make them private, that would make me much less concerned about this change. :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Shouldn't that mean that while some new operations need to be public now, some of the previously used one can be made private?

Yes, I think you're correct. I'll do that in the other PR as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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.

8 participants