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

Do not ICE when matching an uninhabited enum's field #69753

Merged

Conversation

pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Mar 6, 2020

Fix #69191

@rust-highfive
Copy link
Collaborator

r? @davidtwco

(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 Mar 6, 2020
@Centril
Copy link
Contributor

Centril commented Mar 6, 2020

cc @RalfJung

@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

The reason the test is written in that manner is that I had played with a few other methods of fixing this bug; one in particular messed around with the logic here:

let present_first = match present_first {
present_first @ Some(_) => present_first,
// Uninhabited because it has no variants, or only absent ones.
None if def.is_enum() => return tcx.layout_raw(param_env.and(tcx.types.never)),
// if it's a struct, still compute a layout so that we can still compute the
// field offsets
None => Some(VariantIdx::new(0)),
};
let is_struct = !def.is_enum() ||
// Only one variant is present.
(present_second.is_none() &&
// Representation optimizations are allowed.
!def.repr.inhibit_enum_layout_opt());
if is_struct {

where I was trying to replace the def.is_enum() logic in the match with something that instead checked !is_struct from the boolean defined below that match.

Long story short, that approach didn't work; but when I was working on it, I was worried enough about the handling of #[repr(C)] and #[repr(<int-type>)] that I wanted explicit test variants that checked those cases.

@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

Either @oli-obk or @eddyb would be suitable candidates for reviewing this.

@pnkfelix pnkfelix added beta-nominated Nominated for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2020
@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

(also, the reason that the code doesn't just unconditionally throw_ub! even for fields that are within range is that doing so would break a regression test from #64506.)

I'm sure there is a better solution to this problem, in terms of handling the scenario in a more disciplined manner. I laid out three different choices on zulip, but this is the one I felt most confident about being good enough to backport to beta in the short term. (Because all it does it injects a throw_ub! invocation immediately before something that would otherwise cause the compiler to ICE.)

@oli-obk
Copy link
Contributor

oli-obk commented Mar 6, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Mar 6, 2020

📌 Commit 9712fa4 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 Mar 6, 2020
@RalfJung
Copy link
Member

RalfJung commented Mar 6, 2020

bors r+

FWIW, I don't think this is the right fix. At the very least we should add a comment saying FIXME temporary hack to work around incoherence between layout computation and MIR building.

In other words, I consider it quite reasonable to ICE when MIR building says "get field 0 of that variant", but consulting that variant's layout says "nope there are no fields here". This also has to cause issues in codegen, which likely already carries a comparable hack. So is every backend supposed to separately carry hacks working around what is ultimately an issue in the middle-end?

@oli-obk
Copy link
Contributor

oli-obk commented Mar 6, 2020

It is not the correct fix, I agree, but this is getting into stable soon. I am opening a workspace locally later today to start working on a real fix

@oli-obk
Copy link
Contributor

oli-obk commented Mar 6, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Mar 6, 2020

📌 Commit 40809b0 has been approved by oli-obk

Centril added a commit to Centril/rust that referenced this pull request Mar 6, 2020
…ited-enum-field, r=oli-obk

Do not ICE when matching an uninhabited enum's field

Fix rust-lang#69191
@eddyb

This comment has been minimized.

@eddyb
Copy link
Member

eddyb commented Mar 6, 2020

@bors rollup=never (just to make it easier to cancel this PR if we get a different fix going)

@eddyb
Copy link
Member

eddyb commented Mar 6, 2020

@bors r- (in favor of #69768)

@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 Mar 6, 2020
@bors
Copy link
Contributor

bors commented Mar 6, 2020

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented Mar 6, 2020

📌 Commit b4422fb has been approved by oli

@bors
Copy link
Contributor

bors commented Mar 6, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

Also, assuming this does end up in nightly, its fine for it to be part of a rollup.

@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

@bors rollup+

@pnkfelix
Copy link
Member Author

pnkfelix commented Mar 6, 2020

@bors p=9

@nikomatsakis nikomatsakis added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Mar 6, 2020
@nikomatsakis
Copy link
Contributor

Discussed in today's design meeting, decided to accept this change for beta backport.

@pietroalbini
Copy link
Member

@bors treeclosed-

@bors
Copy link
Contributor

bors commented Mar 6, 2020

⌛ Testing commit b4422fb with merge 24b67c42c7ed3b589eb21be5d8ead7f646a16038...

@rust-highfive
Copy link
Collaborator

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.

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 @rust-lang/infra. (Feature Requests)

@bors
Copy link
Contributor

bors commented Mar 6, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 6, 2020
@pietroalbini
Copy link
Member

@bors retry

@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 Mar 6, 2020
@bors
Copy link
Contributor

bors commented Mar 6, 2020

⌛ Testing commit b4422fb with merge 2890b37...

@bors
Copy link
Contributor

bors commented Mar 6, 2020

☀️ Test successful - checks-azure
Approved by: oli
Pushing 2890b37 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 6, 2020
@bors bors merged commit 2890b37 into rust-lang:master Mar 6, 2020
@pietroalbini pietroalbini removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Mar 9, 2020
bors added a commit that referenced this pull request Mar 9, 2020
[stable] Release 1.42.0

This PR prepares the release artifacts of Rust 1.42.0, and cherry-picks the following PRs:

* #69754: Update deprecation version to 1.42 for Error::description
* #69753: Do not ICE when matching an uninhabited enum's field
* #69522 / #69853: error_derive_forbidden_on_non_adt: be more graceful
* #68598:  Fix null synthetic_implementors error

In addition, the release notes are updated to include the remaining compatibility notes.

r? @Centril
bors added a commit that referenced this pull request Mar 9, 2020
[stable] Release 1.42.0

This PR prepares the release artifacts of Rust 1.42.0, and cherry-picks the following PRs:

* #69754: Update deprecation version to 1.42 for Error::description
* #69753: Do not ICE when matching an uninhabited enum's field
* #69522 / #69853: error_derive_forbidden_on_non_adt: be more graceful
* #68598:  Fix null synthetic_implementors error

In addition, the release notes are updated to include the remaining compatibility notes.

r? @Centril
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. 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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

beta regression: ICE on Tried to access field 0 of union Layout
10 participants