Uh oh!
There was an error while loading. Please reload this page.
MIR sanity check: validate types on assignment - #72796
Conversation
rust-highfive
commented
May 30, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
However, something is wrong: this ICEs. Looks like something with consts does not work right here? |
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
RalfJung
commented
May 31, 2020
Cc @lcnr (as const generics seem to be involved) |
Does this happen while building mir, if so, we probably didn't normalize the rhs yet. edit: you can also try running this with --verbose, which prints the actual debug repr instead of |
RalfJung
commented
May 31, 2020
I am seeing this after all optimizations have run, so it's not during MIR building. |
eddyb
commented
May 31, 2020
@RalfJung You don't see this in miri because the way you do monomorphization also normalizes. The MIR type-checker that runs as part of borrow-checking has to normalize types in a few places in order to work, but what it does involves capturing all of the constraints on lifetimes resulting from normalizing and equating types. I guess you can probably just use |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Btw you can make this cheaper by implementing TypeFolder instead, which is only a few lines longer, and doing early returns in the type-visiting method based on flags (which are precomputed so they're basically free) that tell you if there are any erasable lifetimes or normalizable consts (for example, you could choose more things to do/look for).
Although you still have that reference "normalization" aspect, hmpf.
There was a problem hiding this comment.
I understood maybe half of that so I think I'll leave this to someone else...
Uh oh!
There was an error while loading. Please reload this page.
Now we get a different failure: The confusing part is that this looks like it's the same type on both sides.^^ |
rust-highfive
commented
May 31, 2020
The job Click to expand the log.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 |
running with |
RalfJung
commented
Jun 1, 2020
@matthewjasper unfortunately, bootstrap fails to even build with those flags... gives |
RalfJung
commented
Jun 1, 2020
I passed the flags by modifying Looks like vs |
Uh oh!
There was an error while loading. Please reload this page.
This comment has been minimized.
This comment has been minimized.
Uh oh!
There was an error while loading. Please reload this page.
bors
commented
Jun 22, 2020
☀️ Try build successful - checks-azure |
rust-timer
commented
Jun 22, 2020
Queued 5e7db3c429dc362ffac291de89f7b045b674bfc9 with parent 1a4e2b6, future comparison URL. |
rust-timer
commented
Jun 22, 2020
Finished benchmarking try commit (5e7db3c429dc362ffac291de89f7b045b674bfc9): comparison url. |
RalfJung
commented
Jun 22, 2020
Ah lol, the extra check of layouts are really equal if the types are equal actually is measurable for the CTFE stress test. |
RalfJung
commented
Jun 24, 2020
Okay @matthewjasper I think this is finally ready for review. |
| "encountered `Assign` statement with overlapping memory", | ||
| ); | ||
| match &statement.kind { | ||
| StatementKind::Assign(box (dest, rvalue)) => { |
There was a problem hiding this comment.
As a follow up we should also check function calls and DropAndReplace
There was a problem hiding this comment.
SetDiscriminant can also get checked as to whether the type has the mentioned discriminant id and whether the local's type is actually an enum
matthewjasper
commented
Jun 27, 2020
@bors r+ |
bors
commented
Jun 27, 2020
📌 Commit 35911ee has been approved by |
…ewjasper MIR sanity check: validate types on assignment This expands the MIR validation added by @jonas-schievink in rust-lang#72093 to also check that on an assignment, the types of both sides match. Cc @eddyb@oli-obk
…ewjasper MIR sanity check: validate types on assignment This expands the MIR validation added by @jonas-schievink in rust-lang#72093 to also check that on an assignment, the types of both sides match. Cc @eddyb@oli-obk
…arth Rollup of 10 pull requests Successful merges: - rust-lang#72796 (MIR sanity check: validate types on assignment) - rust-lang#73243 (Add documentation to point to `File::open` or `OpenOptions::open` instead of `is_file` to check read/write possibility) - rust-lang#73525 (Prepare for LLVM 11) - rust-lang#73672 (Adds a clearer message for when the async keyword is missing from a f…) - rust-lang#73708 (Explain move errors that occur due to method calls involving `self` (take two)) - rust-lang#73758 (improper_ctypes: fix remaining `Reveal:All`) - rust-lang#73763 (errors: use `-Z terminal-width` in JSON emitter) - rust-lang#73796 (replace more `DefId`s with `LocalDefId`) - rust-lang#73797 (fix typo in self-profile.md) - rust-lang#73809 (Add links to fs::DirEntry::metadata) Failed merges: r? @ghost
bors
commented
Jun 28, 2020
jonas-schievink
commented
Jun 29, 2020
This has broken the bootstrap with |
RalfJung
commented
Jun 30, 2020
@jonas-schievink what exactly is the command for that again? Might be worth adding a comment in the file explaining this. |
jonas-schievink
commented
Jun 30, 2020
I think it's |
This expands the MIR validation added by @jonas-schievink in #72093 to also check that on an assignment, the types of both sides match.
Cc @eddyb@oli-obk