syntax: allow negative integer literal expression to be interpolated as pattern #42886

durka · 2017-06-24T18:29:10Z

petrochenkov · 2017-06-24T19:20:52Z

src/libsyntax/parse/parser.rs

@@ -1661,6 +1661,8 @@ impl<'a> Parser<'a> {

    /// matches '-' lit | lit
    pub fn parse_pat_literal_maybe_minus(&mut self) -> PResult<'a, P<Expr>> {
+        maybe_whole_expr!(self);


This line permits much more that just negative integer literals, now PatKind::Lit and PatKind::Range can contain arbitrary expressions.
I'm not sure that later compilation stages are prepared to deal with them, but there's a chance that it will "just work" and passing an arbitrary expression through expr matcher will be equivalent to passing it through a constant.

There are two ways to proceed, I think:

Conservative way: add a check to ast_validation ensuring that only paths, literals and literals with minus are accepted in PatKind::Lit and PatKind::Range.

Non-conservative way: extend the language and permit passing arbitrary expressions to literal/range patterns through expr matchers, make sure it doesn't cause ICEs etc, make @rust-lang/lang aware of this change.

In any case tests for passing arbitrary expressions are required.

Indeed it causes ICEs. Conservative approach sounds good to me for this patch.

Should the check be in ast_validation or right here in parse_pat_literal_maybe_minus?

These kinds of things are usually checked in ast_validation because AST fragments can be produced by procedural macros as well (and parser checks won't help in this case).

@petrochenkov OK, not quite sure what to do. I added the check to ast_validation but I am hitting this ICE in a lint before it even gets there.

Should I just remove the ICE, letting any expression through that lint and have validation catch it later, or add the validation check here (does procedural macro generated code go through lints?) (also then we'd have a lint emitting an error -- is that bad?)?

durka · 2017-06-27T16:15:38Z

I added the check to ast_validation and a test that 1+1 doesn't slip through. Just to make sure the user doesn't miss the message, it prints the error twice and an unrelated one from typeck as well (but seriously wtf is going on).

petrochenkov · 2017-06-27T18:25:52Z

src/librustc_passes/ast_validation.rs

+        match expr.node {
+            ExprKind::Lit(_) => {}
+            ExprKind::Unary(UnOp::Neg, ref inner)
+                if match inner.node { ExprKind::Lit(_) => true, _ => false } => {}


ExprKind::Path is permitted as well, Travis fails due to this.

durka · 2017-06-27T18:38:39Z

Some dependency edges must be missing since I was able to rebuild locally.

…

On Tue, Jun 27, 2017 at 2:26 PM, Vadim Petrochenkov < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/librustc_passes/ast_validation.rs <#42886 (comment)>: > @@ -93,6 +93,17 @@ impl<'a> AstValidator<'a> { } } } + + /// matches '-' lit | lit (cf. parser::Parser::parse_pat_literal_maybe_minus) + fn check_expr_within_pat(&self, expr: &Expr) { + match expr.node { + ExprKind::Lit(_) => {} + ExprKind::Unary(UnOp::Neg, ref inner) + if match inner.node { ExprKind::Lit(_) => true, _ => false } => {} ExprKind::Path is permitted as well, Travis fails due to this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42886 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n8N2yN4vyFPhl-5ku8OOUBkGTrLZks5sIUlHgaJpZM4OEZep> .

…as pattern

est31 · 2017-06-28T18:12:37Z

src/test/compile-fail/patkind-litrange-no-expr.rs

+    Pos = 1,
+    Neg = -1,
+    Arith = 1 + 1, //~ ERROR arbitrary expressions aren't allowed in patterns
+                   //~^ ERROR arbitrary expressions aren't allowed in patterns


cc @arielb1 -- you wanted to get pinged when I find duplicated error messages.

Nah this is caused by there being 2 uses of $value in the macro.

durka · 2017-06-28T18:28:09Z

Sorry, I just realized it isn't really a duplicated message. It's generated twice because the macro generates two patterns containing $value.

…

On Wed, Jun 28, 2017 at 2:13 PM, est31 ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/test/compile-fail/patkind-litrange-no-expr.rs <#42886 (comment)>: > + + fn foo(value: i32) -> Option<$name> { + match value { + $( $value => Some($name::$variant), )* // PatKind::Lit + $( $value ... 42 => Some($name::$variant), )* // PatKind::Range + _ => None + } + } + } +} + +enum_number!(Change { + Pos = 1, + Neg = -1, + Arith = 1 + 1, //~ ERROR arbitrary expressions aren't allowed in patterns + //~^ ERROR arbitrary expressions aren't allowed in patterns cc @arielb1 <https://github.com/arielb1> -- you wanted to get pinged when I find duplicated error messages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42886 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n_UEGWytfDB6dj4CGADAhhQe0jtqks5sIpe1gaJpZM4OEZep> .

jseyfried · 2017-06-28T23:33:31Z

Reviewed, r=me unless anyone objects.
Eventually, I think we should consider the negative to be part of the literal (cc @eddyb).

petrochenkov · 2017-06-29T07:31:32Z

@bors r+

bors · 2017-06-29T07:31:33Z

📌 Commit 0dfd9c3 has been approved by petrochenkov

arielb1 · 2017-06-29T08:38:13Z

@bors rollup

@jseyfried

syntax: allow negative integer literal expression to be interpolated as pattern Fixes rust-lang#42820. r? @jseyfried

Rollup of 12 pull requests - Successful merges: #42219, #42831, #42832, #42884, #42886, #42901, #42919, #42920, #42946, #42953, #42955, #42958 - Failed merges:

Since rust-lang#42886, macros can create "nonstandard" PatKind::Lit patterns, that contain path expressions instead of the usual literal expr. These can cause trouble, including ICEs. We *could* map these nonstandard patterns to PatKind::Path patterns during HIR lowering, but that would be much effort for little gain, and I think is too risky for beta. So let's just forbid them during AST validation. Fixes rust-lang#43250.

@eddyb

ast_validation: forbid "nonstandard" literal patterns Since #42886, macros can create "nonstandard" PatKind::Lit patterns, that contain path expressions instead of the usual literal expr. These can cause trouble, including ICEs. We *could* map these nonstandard patterns to PatKind::Path patterns during HIR lowering, but that would be much effort for little gain, and I think is too risky for beta. So let's just forbid them during AST validation. Fixes #43250. beta-nominating because regression. r? @eddyb

Since rust-lang#42886, macros can create "nonstandard" PatKind::Lit patterns, that contain path expressions instead of the usual literal expr. These can cause trouble, including ICEs. We *could* map these nonstandard patterns to PatKind::Path patterns during HIR lowering, but that would be much effort for little gain, and I think is too risky for beta. So let's just forbid them during AST validation. Fixes rust-lang#43250.

rust-highfive assigned jseyfried Jun 24, 2017

durka force-pushed the pplmm-mwe branch from 946abe4 to d895ebc Compare June 24, 2017 18:54

petrochenkov reviewed Jun 24, 2017

View reviewed changes

Mark-Simulacrum added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 24, 2017

durka force-pushed the pplmm-mwe branch from d895ebc to b30f7b4 Compare June 27, 2017 16:12

petrochenkov reviewed Jun 27, 2017

View reviewed changes

syntax: allow negative integer literal expression to be interpolated …

0dfd9c3

…as pattern

durka force-pushed the pplmm-mwe branch from b30f7b4 to 0dfd9c3 Compare June 27, 2017 18:39

est31 reviewed Jun 28, 2017

View reviewed changes

arielb1 pushed a commit to arielb1/rust that referenced this pull request Jun 29, 2017

Rollup merge of rust-lang#42886 - durka:pplmm-mwe, r=petrochenkov

effd1e0

syntax: allow negative integer literal expression to be interpolated as pattern Fixes rust-lang#42820. r? @jseyfried

arielb1 mentioned this pull request Jun 29, 2017

Rollup of 12 pull requests #42964

Merged

bors added a commit that referenced this pull request Jun 29, 2017

Auto merge of #42964 - arielb1:rollup, r=arielb1

7acce37

Rollup of 12 pull requests - Successful merges: #42219, #42831, #42832, #42884, #42886, #42901, #42919, #42920, #42946, #42953, #42955, #42958 - Failed merges:

bors merged commit 0dfd9c3 into rust-lang:master Jun 29, 2017

est31 mentioned this pull request Jul 15, 2017

ICE: "encountered errors lowering pattern: [ConstEval(ConstEvalErr { ... kind: NonConstPath })]" #43250

Closed

arielb1 mentioned this pull request Aug 13, 2017

ast_validation: forbid "nonstandard" literal patterns #43844

Merged

petrochenkov mentioned this pull request Dec 1, 2017

ty macro arguments can be used as traits in impls #46438

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

syntax: allow negative integer literal expression to be interpolated as pattern #42886

syntax: allow negative integer literal expression to be interpolated as pattern #42886

durka commented Jun 24, 2017

petrochenkov Jun 24, 2017

durka Jun 25, 2017

durka Jun 25, 2017

petrochenkov Jun 25, 2017

durka Jun 25, 2017

durka Jun 26, 2017 •

edited

Loading

durka commented Jun 27, 2017

petrochenkov Jun 27, 2017

durka commented Jun 27, 2017 via email

est31 Jun 28, 2017

arielb1 Jul 30, 2017 •

edited

Loading

durka commented Jun 28, 2017 via email

jseyfried commented Jun 28, 2017

petrochenkov commented Jun 29, 2017

bors commented Jun 29, 2017

arielb1 commented Jun 29, 2017

syntax: allow negative integer literal expression to be interpolated as pattern #42886

syntax: allow negative integer literal expression to be interpolated as pattern #42886

Conversation

durka commented Jun 24, 2017

petrochenkov Jun 24, 2017

Choose a reason for hiding this comment

durka Jun 25, 2017

Choose a reason for hiding this comment

durka Jun 25, 2017

Choose a reason for hiding this comment

petrochenkov Jun 25, 2017

Choose a reason for hiding this comment

durka Jun 25, 2017

Choose a reason for hiding this comment

durka Jun 26, 2017 • edited Loading

Choose a reason for hiding this comment

durka commented Jun 27, 2017

petrochenkov Jun 27, 2017

Choose a reason for hiding this comment

durka commented Jun 27, 2017 via email

est31 Jun 28, 2017

Choose a reason for hiding this comment

arielb1 Jul 30, 2017 • edited Loading

Choose a reason for hiding this comment

durka commented Jun 28, 2017 via email

jseyfried commented Jun 28, 2017

petrochenkov commented Jun 29, 2017

bors commented Jun 29, 2017

arielb1 commented Jun 29, 2017

durka Jun 26, 2017 •

edited

Loading

arielb1 Jul 30, 2017 •

edited

Loading