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

Add error for ... in expressions #45773

Merged
merged 3 commits into from
Nov 10, 2017
Merged

Add error for ... in expressions #45773

merged 3 commits into from
Nov 10, 2017

Conversation

Badel2
Copy link
Contributor

@Badel2 Badel2 commented Nov 5, 2017

Follow-up to #44709
Tracking issue: #28237

  • Using ... in expressions was a warning, now it's an error
  • The error message suggests using .. or ..= instead, and explains the difference
  • Updated remaining occurrences of ... to ..=

r? petrochenkov

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@petrochenkov
Copy link
Contributor

I'm sad every time I have to @bors r+ this

@bors
Copy link
Contributor

bors commented Nov 5, 2017

📌 Commit 0419a3b has been approved by petrochenkov

@@ -106,7 +106,8 @@ impl AssocOp {
Token::OrOr => Some(LOr),
Token::DotDot => Some(DotDot),
Token::DotDotEq => Some(DotDotEq),
Token::DotDotDot => Some(DotDotEq), // remove this after SNAP
// DotDotDot is no longer supported, but we need some way to display the error
Token::DotDotDot => Some(DotDotEq),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

My main concern is that in order to show the error we need to parse the expression, so here I'm parsing Token::DotDotDot as AssocOp::DotDotEq, and in src/libsyntax/parse/parser.rs I check for Token::DotDotDot and AssocOp::DotDotEq to show the error. An alternative would be returning None here but then the expression would be incomplete (adding the generic "expected one of" error).

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm parsing Token::DotDotDot as AssocOp::DotDotEq

That's exactly what is needed for good error recovery.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice, thanks!

@kennytm kennytm added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 5, 2017
@Badel2 Badel2 mentioned this pull request Nov 5, 2017
@bors
Copy link
Contributor

bors commented Nov 6, 2017

⌛ Testing commit 0419a3b697be90d36efed6d91bee5c371e29f0a6 with merge c48637001106cd9eb78d037fb77aa7602d28f83c...

@bors
Copy link
Contributor

bors commented Nov 6, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Nov 6, 2017

Several run-pass/pretty tests failed, and one of them caused ICE.

run-pass/range_inclusive.rs
[01:22:25] ---- [pretty] run-pass/range_inclusive.rs stdout ----
[01:22:25] 	
[01:22:25] error: pretty-printing failed in round 1 revision None
[01:22:25] status: exit code: 101
[01:22:25] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "-" "-Zunstable-options" "--unpretty" "normal" "--target" "x86_64-unknown-linux-gnu" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/range_inclusive.stage2-x86_64-unknown-linux-gnu.pretty.aux" "-Crpath" "-O" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
[01:22:25] stdout:
[01:22:25] ------------------------------------------
[01:22:25] 
[01:22:25] ------------------------------------------
[01:22:25] stderr:
[01:22:25] ------------------------------------------
[01:22:25] error: `...` syntax cannot be used in expressions
[01:22:25]   --> <anon>:20:56
[01:22:25]    |
[01:22:25] 20 | fn return_range_to() -> RangeToInclusive<i32> { return ...1; }
[01:22:25]    |                                                        ^^^
[01:22:25]    |
[01:22:25]    = help: Use `..` if you need an exclusive range (a < b)
[01:22:25]    = help: or `..=` if you need an inclusive range (a <= b)
[01:22:25] 
[01:22:25] error: internal compiler error: unexpected panic
[01:22:25] 
[01:22:25] note: the compiler unexpectedly panicked. this is a bug.
[01:22:25] 
[01:22:25] note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
[01:22:25] 
[01:22:25] note: rustc 1.23.0-dev running on x86_64-unknown-linux-gnu
[01:22:25] 
[01:22:25] thread 'rustc' panicked at 'parse_prefix_range_expr: token DotDotDot is not DotDot/DotDotEq', /checkout/src/libsyntax/parse/parser.rs:3020:8
[01:22:25] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:22:25] 
[01:22:25] 
[01:22:25] ------------------------------------------
[01:22:25] 
[01:22:25] thread '[pretty] run-pass/range_inclusive.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2497:8
[01:22:25] note: Run with `RUST_BACKTRACE=1` for a backtrace.
run-pass/range_inclusive_gate.rs
[01:22:25] ---- [pretty] run-pass/range_inclusive_gate.rs stdout ----
[01:22:25] 	
[01:22:25] error: pretty-printing failed in round 1 revision None
[01:22:25] status: exit code: 101
[01:22:25] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "-" "-Zunstable-options" "--unpretty" "normal" "--target" "x86_64-unknown-linux-gnu" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/range_inclusive_gate.stage2-x86_64-unknown-linux-gnu.pretty.aux" "-Crpath" "-O" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
[01:22:25] stdout:
[01:22:25] ------------------------------------------
[01:22:25] // Copyright 2016 The Rust Project Developers. See the COPYRIGHT
[01:22:25] // file at the top-level directory of this distribution and at
[01:22:25] // http://rust-lang.org/COPYRIGHT.
[01:22:25] //
[01:22:25] // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
[01:22:25] // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
[01:22:25] // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
[01:22:25] // option. This file may not be copied, modified, or distributed
[01:22:25] // except according to those terms.
[01:22:25] 
[01:22:25] // Test that you only need the syntax gate if you don't mention the structs.
[01:22:25] 
[01:22:25] #![feature(inclusive_range_syntax)]
[01:22:25] 
[01:22:25] fn main() {
[01:22:25]     let mut count = 0;
[01:22:25]     for i in 0_usize...10 { assert!(i >= 0 && i <= 10); count += i; }
[01:22:25]     assert_eq!(count , 55);
[01:22:25] }
[01:22:25] 
[01:22:25] 
[01:22:25] ------------------------------------------
[01:22:25] stderr:
[01:22:25] ------------------------------------------
[01:22:25] error: `...` syntax cannot be used in expressions
[01:22:25]   --> <anon>:17:21
[01:22:25]    |
[01:22:25] 17 |     for i in 0_usize...10 { assert!(i >= 0 && i <= 10); count += i; }
[01:22:25]    |                     ^^^
[01:22:25]    |
[01:22:25]    = help: Use `..` if you need an exclusive range (a < b)
[01:22:25]    = help: or `..=` if you need an inclusive range (a <= b)
[01:22:25] 
[01:22:25] error: aborting due to previous error

@Badel2
Copy link
Contributor Author

Badel2 commented Nov 6, 2017

I'm confused. The error says that line 20 of range_inclusive.rs is ... when it was changed to ..=:

fn return_range_to() -> RangeToInclusive<i32> { return ..=1; }

@petrochenkov
Copy link
Contributor

@Badel2
The error may refer to the pretty-printed version of range_inclusive.rs which still may have ... if some code in pretty-printing wasn't updated.

Could you also add a test checking that if ... is actually written (...b and a ... b), then recovery works and no ICE happens.

@Badel2
Copy link
Contributor Author

Badel2 commented Nov 6, 2017

I have added a parse-fail test, but I can't find the pretty-printing code. The closest I got is the code for ranges in patterns, but I can't find the one for expressions.

RangeEnd::Included => self.s.word("...")?,

@petrochenkov
Copy link
Contributor

@Badel2
That's HIR pretty-printing.
There's also AST pretty-printing in libsyntax/print/pprust.rs and it's AST pretty-printing which is tested by pretty tests.
This line in particular looks suspicious

self.s.word("...")?;

@kennytm kennytm 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 Nov 6, 2017
@Badel2
Copy link
Contributor Author

Badel2 commented Nov 6, 2017

@petrochenkov Thanks! I hope it's fixed now.

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 6, 2017

📌 Commit c0addf6 has been approved by petrochenkov

@Badel2
Copy link
Contributor Author

Badel2 commented Nov 6, 2017

That's strange, in my machine I run ./x.py test src/test/parse-fail/ and it works... According to the logs it only detected the first error. I have no idea why :)

@petrochenkov
Copy link
Contributor

I see why only the first error is detected, the test is missing

// compile-flags: -Z parse-only -Z continue-parse-after-error

, but it should fail locally as well.

(-Z continue-parse-after-error allows reporting multiple errors during parsing phase, -Z parse-only is the only thing that differs parse-fail tests from compile-fail tests (less work for the compiler)).

@Badel2
Copy link
Contributor Author

Badel2 commented Nov 6, 2017

@petrochenkov Same result, it fails on travis but it works on my machine. I haven't run ./x.py clean since the first commit 3 days ago, so maybe I'm using an outdated tool or something.

self.err_dotdotdot_syntax(self.span);
}

debug_assert!([token::DotDot, token::DotDotEq].contains(&self.token),
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like this debug_assert may be firing on CI.
IIRC, these kinds of asserts are enabled on PR merge, but disabled by default for local builds.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, for some reason I thought the code would stop executing after the err.emit(). Now it all makes sense. Thank you very much!

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Nov 7, 2017

📌 Commit b81a7b3 has been approved by petrochenkov

@kennytm kennytm 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 Nov 7, 2017
@bors
Copy link
Contributor

bors commented Nov 10, 2017

⌛ Testing commit b81a7b3 with merge d5ff0e6...

bors added a commit that referenced this pull request Nov 10, 2017
Add error for `...` in expressions

Follow-up to #44709
Tracking issue: #28237

* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`

r? petrochenkov
@bors
Copy link
Contributor

bors commented Nov 10, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing d5ff0e6 to master...

@bors bors merged commit b81a7b3 into rust-lang:master Nov 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

6 participants