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

Change unreachable pattern ICEs to warnings #39127

Merged

Conversation

Projects
None yet
7 participants
@canndrew
Copy link
Contributor

canndrew commented Jan 17, 2017

Allow code with unreachable ? and for patterns to compile.
Add some tests.

Change unreachable patterns ICEs to warnings
Allow code with unreachable `?` and `for` patterns to compile.
Add some tests.
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 17, 2017

r? @arielb1

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

@canndrew

This comment has been minimized.

Copy link
Contributor Author

canndrew commented Jan 17, 2017

Ugh, bloody make tidy. Every single time.

@canndrew

This comment has been minimized.

Copy link
Contributor Author

canndrew commented Jan 17, 2017

So to summarise: An unreachable pattern in a ForLoopDesugar is now a warning instead of a span_bug!. An unreachable pattern in a TryDesugar is nothing, not even a warning (because it should be fine to ? a Result<!, T>). ? now desguars to a match expression which has #[allow(unreachable_patterns)] and #[allow(unreachable_code)] on it.

@eddyb

This comment has been minimized.

Copy link
Member

eddyb commented Jan 17, 2017

@@ -1833,8 +1835,12 @@ impl<'a> LoweringContext<'a> {
ExprKind::Try(ref sub_expr) => {
// to:
//
// #[allow(unreachable_patterns)]

This comment has been minimized.

@nikomatsakis

nikomatsakis Jan 17, 2017

Contributor

Hmm, so, this #[allow(unreachable_patterns)] annotation presumably affects the <expr>, right? That seems unfortunate. i.e., if I do (match { ... })?, do we still see warnings from the inner match?

This comment has been minimized.

@canndrew

canndrew Jan 18, 2017

Author Contributor

Good point, I'll need to look into this :/

This comment has been minimized.

@arielb1

arielb1 Jan 18, 2017

Contributor

Can't you key things directly on the MatchSource?

This comment has been minimized.

@canndrew

canndrew Jan 18, 2017

Author Contributor

I still seem to get warnings without these. At least the unreachable_code attribute seems to have an effect. I was thinking I'll change the code to this:

match Carrier::translate(<expr>) {
    #[allow(unused)]
    Ok(val) => val,
    #[allow(unused)]
    Err(err) => return Carrier::from_error(From::from(err)),
}

This comment has been minimized.

@arielb1

arielb1 Jan 18, 2017

Contributor

The unreachable_code attribute is indeed fine - no user-defined code exists under it. It's the unreachable_patterns attribute that is the problem - could you check why is it needed?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jan 17, 2017

r? @nikomatsakis (I'm assuming @arielb1 doesn't have time)

@durka

This comment has been minimized.

Copy link
Contributor

durka commented Jan 17, 2017

Wait, do expr-level #[allow] annotations work? Last I checked, they have no effect.

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Jan 18, 2017

I do have time.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jan 19, 2017

@arielb1 ok :) either way. In any case, I think we both agree that we should try to avoid having warnings get squelched in user code somehow. I agree with the suggestion of using the MatchSource to squelch the lints, does that not work?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jan 19, 2017

@canndrew I just want to clarify something. Given #39151, is this PR necessary for backwards compatibility? I'm trying to assess the priority of landing it with respect to the release timeline.

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Jan 19, 2017

@nikomatsakis

The PR is required. #39151 just gates the uninhabitableness of references, it does not revert the changes for matching Result<X, Void>.

val_ident,
val_pat.id,
attrs));
let val_block = P(self.block_expr(val_expr));

This comment has been minimized.

@arielb1

arielb1 Jan 19, 2017

Contributor

Do we need the block_expr/expr_block pair?

This comment has been minimized.

@canndrew

canndrew Jan 20, 2017

Author Contributor

No.. for some reason I thought we did.

canndrew added some commits Jan 20, 2017

@canndrew

This comment has been minimized.

Copy link
Contributor Author

canndrew commented Jan 20, 2017

Sorry for spamming travis.

I've now changed the try desugaring to this:

match Carrier::translate(<expr>) {
    Ok(val) => #[allow(unreachable_code)] val,
    Err(err) => #[allow(unreachable_code)] return Carrier::from_error(From::from(err)),
}

That seems to be all we need to crush the warnings.

// Ok(val) => {
// #[allow(unreachable_code)]
// val
// }
// Err(err) => return Carrier::from_error(From::from(err))

This comment has been minimized.

@arielb1

arielb1 Jan 20, 2017

Contributor

nit: update the comment here (including the absence of BlockExpr/ExprBlock pair.

let val_expr = P(self.expr_ident_with_attrs(e.span,
val_ident,
val_pat.id,
From::from(attrs.clone())));

This comment has been minimized.

@arielb1

arielb1 Jan 20, 2017

Contributor

I prefer ThinVec::from, but whatever you want.

hir::MatchSource::TryDesugar => {
span_bug!(pat.span, "unreachable try pattern")
},
hir::MatchSource::TryDesugar => {}

This comment has been minimized.

@arielb1

arielb1 Jan 20, 2017

Contributor

A comment would be nice, for example:

// unreachable patterns in a try expression occur when one of the Result
// variants is uninhabited, and should cause a warning.
@arielb1
Copy link
Contributor

arielb1 left a comment

nice modulo comment nits.

canndrew added some commits Jan 21, 2017

@arielb1

This comment has been minimized.

Copy link
Contributor

arielb1 commented Jan 22, 2017

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 22, 2017

📌 Commit 0aad529 has been approved by arielb1

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 22, 2017

⌛️ Testing commit 0aad529 with merge 98c3128...

bors added a commit that referenced this pull request Jan 22, 2017

Auto merge of #39127 - canndrew:unreachable-pattern-errors-into-warni…
…ngs, r=arielb1

Change unreachable pattern ICEs to warnings

Allow code with unreachable `?` and `for` patterns to compile.
Add some tests.
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jan 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing 98c3128 to master...

@bors bors merged commit 0aad529 into rust-lang:master Jan 22, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.