Normalize labeled and unlabeled breaks #39864

cramertj · 2017-02-15T22:53:19Z

Part of #39849.

rust-highfive · 2017-02-15T22:53:26Z

r? @eddyb

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

cramertj · 2017-02-15T22:53:34Z

r? @nikomatsakis

cramertj · 2017-02-16T07:31:03Z

Now fixes #37576. I'll add a compile-fail test for unlabeled break in while conditions tomorrow.

nikomatsakis

This looks nice! I left some nits, mostly about comments I'd like to see, but the main thing that I think is missing are more targeted tests:

We need a test for the new error (i.e., while break)
We need regression tests for the various cases listed on It is not intuitive which loop is broken out from in loop { while break {} } #37576, specifically in this comment
- we just need to show we do decent things here
We need a test using a labeled break applied to the while loop itself (i.e., 'a: while break 'a { }), which I believe your PR now enables.
- Ideally, we'd try to test the liveness/CFG, but I'm not 100% sure how best to do that and not overly concerned. The most important thing is to show that it doesn't execute the body of the loop ever (i.e., that the MIR control flow is working out OK).
Similarly some tests for something like while let None = break { } and 'a: while let None = break 'a { }

Make sense?

nikomatsakis · 2017-02-16T14:48:10Z

src/librustc/cfg/construct.rs

-                let expr_exit = self.add_ast_node(expr.id, &[cond_exit]); // 3
+
+                // Create expr_exit without pred (cond_exit)
+                let expr_exit = {


can we not just do self.add_ast_node(expr.id, &[])?

nikomatsakis · 2017-02-16T14:49:32Z

src/librustc/cfg/construct.rs

+                    let data = CFGNodeData::AST(id);
+                    self.graph.add_node(data)
+                };
+
                self.loop_scopes.push(LoopScope {


It's worth adding a comment here indicating that we want to be sure and push LoopScope onto loop_scopes so that they are in scope when evaluating cond

nikomatsakis · 2017-02-16T14:53:47Z

src/librustc/hir/lowering.rs

+    fn lower_label(&mut self, label: Option<(NodeId, Spanned<Ident>)>) -> hir::Label {
+        match label {
+            Some((id, label_ident)) => hir::Label {
+                ident: Some(label_ident),
                loop_id: match self.expect_full_def(id) {


doesn't have to be done, and also doesn't have to be done in this PR, but as we mentioned on IRC I think i'd prefer to make this an Option type rather than using DUMMY_NODE_ID. No need to reinvent null.

My concern with that is that there are a lot of places that handle HIR for which it would just be a bug for it to be None. None/DUMMY_NODE_ID should be caught by the loops pass. I'm really starting to think that the loops pass should just be pulled into lowering, if possible.

nikomatsakis · 2017-02-16T14:56:37Z

src/librustc/hir/lowering.rs

@@ -79,6 +80,8 @@ pub struct LoweringContext<'a> {
    impl_items: BTreeMap<hir::ImplItemId, hir::ImplItem>,
    bodies: FxHashMap<hir::BodyId, hir::Body>,

+    loop_scopes: Vec<NodeId>,


Maybe we should make this an Option<Vec<NodeId>>? then it can start as None, and with_new_loop_scopes can insert Some(vec![]). This would ensure that all loop scope manipulation happens within the context of a with_new_loop_scopes() call (but other calls, such as with_loop_scope, would want to either ignore None or fail with bug!; not sure which). Do you think this makes sense?

Context is that I always get a bit nervous about the possibility of latent bugs where we are pushing loop scopes and things in places we don't expect and those pushes never get observed. I guess since the loops pass comes later and looks for surprises, this isn't such a big concern here, so maybe it's not worth the effort.

I don't think it needs to be None, since in both of the cases its used, its absence will be obvious:

In the unlabeled case, .last() will return None

In the labeled case, the label will not be found

Both of these result in DUMMY_NODE_ID.

nikomatsakis · 2017-02-16T14:57:26Z

src/librustc/hir/lowering.rs

@@ -1660,10 +1699,13 @@ impl<'a> LoweringContext<'a> {
                    hir::ExprPath(self.lower_qpath(e.id, qself, path, ParamMode::Optional))
                }
                ExprKind::Break(opt_ident, ref opt_expr) => {
-                    hir::ExprBreak(self.lower_label(e.id, opt_ident),
+                    hir::ExprBreak(
+                        self.lower_label(opt_ident.map(|ident| (e.id, ident))),
                                   opt_expr.as_ref().map(|x| P(self.lower_expr(x))))


Nit: funny indentation here

nikomatsakis · 2017-02-16T14:58:30Z

src/librustc/hir/lowering.rs

@@ -1804,9 +1846,14 @@ impl<'a> LoweringContext<'a> {
                    //     }
                    //   }

+                    let (body, break_expr, sub_expr) = self.with_loop_scope(e.id, |this| (


worth a comment here about the condition being within the while let loop

nikomatsakis · 2017-02-16T14:58:50Z

src/librustc/hir/mod.rs

@@ -1033,8 +1033,7 @@ pub enum LoopSource {

 #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)]
 pub struct Label {
-    pub span: Span,
-    pub name: Name,
+    pub ident: Option<Spanned<Ident>>,


worth a comment explaining when this is None

nikomatsakis · 2017-02-16T14:59:05Z

src/librustc/hir/mod.rs

@@ -1033,8 +1033,7 @@ pub enum LoopSource {

 #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)]
 pub struct Label {
-    pub span: Span,
-    pub name: Name,
+    pub ident: Option<Spanned<Ident>>,
    pub loop_id: NodeId


worth a comment explaining that this is DUMMY_NODE_ID in the case of error (or, better yet, changing the type)

nikomatsakis · 2017-02-16T15:00:11Z

src/librustc_mir/build/scope.rs

+                   .rev()
+                   .filter(|loop_scope| loop_scope.extent == label)
+                   .next()
+            .unwrap_or_else(|| span_bug!(span, "no enclosing loop scope found?"))


Nit: inconsistent indentation; either align all to 4-space, or align the unwrap_or_else with the other lines

nikomatsakis · 2017-02-16T15:08:55Z

Also, travis CI is reporting that the error code is a duplicate:

https://travis-ci.org/rust-lang/rust/jobs/202150799#L423

nikomatsakis · 2017-02-17T01:12:31Z

src/librustc/hir/lowering.rs

@@ -1699,8 +1728,16 @@ impl<'a> LoweringContext<'a> {
                    hir::ExprPath(self.lower_qpath(e.id, qself, path, ParamMode::Optional))
                }
                ExprKind::Break(opt_ident, ref opt_expr) => {
+                    let label_result = if self.is_in_loop_condition && opt_ident.is_none() {


Nit: Seems worth a comment pointing at the issue where this was discussed.

nikomatsakis · 2017-02-17T01:15:13Z

Two test failures on travis:

failures:
    [compile-fail] compile-fail/borrowck/borrowck-lend-flow-loop.rs
    [compile-fail] compile-fail/resolve-label.rs

nikomatsakis · 2017-02-17T20:21:45Z

Started a crater run from 48bc082 to c2fc0902af3cba5a7645786900bf6a351c39dd77.

nikomatsakis · 2017-02-18T02:14:54Z

nikomatsakis · 2017-02-18T02:15:08Z

@cramertj I didn't investigate those yet -- often they are just false errors.

nikomatsakis · 2017-02-18T02:20:26Z

OK, all the failures were timeouts, except for errors in clippy that result from the HIR having changed to make the Label non-optional (cc @Manishearth).

@cramertj -- I wonder if we should rename Label to something like Destination? After all, there is always a "label" even if the break had no label...? At minimum it seems to merit a comment. =)

cramertj · 2017-02-18T02:21:49Z

@nikomatsakis Destination or Target seem fine to me.

nikomatsakis · 2017-02-18T02:22:33Z

@cramertj, ok -- if you want to squash/rebase, go ahead. And feel free to change Label to something else, or else just give it a comment like "in the HIR, all breaks/continues are labeled explicitly, even if user didn't write one" or something so we can "justify" the name. =)

nikomatsakis · 2017-02-18T02:22:45Z

but basically r=me

cramertj · 2017-02-18T02:22:58Z

Okay. I'll do that right away.

nikomatsakis · 2017-02-18T10:08:37Z

src/librustc_passes/diagnostics.rs

@@ -248,4 +248,6 @@ register_diagnostics! {
    E0472, // asm! is unsupported on this target
    E0561, // patterns aren't allowed in function pointer types
    E0571, // `break` with a value in a non-`loop`-loop
+    E0583, // `break` with no label in the condition of a `while` loop
+    E0584, // `continue` with no label in the condition of a `while` loop


I was thinking that

(a) maybe it makes sense to have just one condition code here ("break or continue with no label in the condition of a while loop")

and

(b) given that we do technically accept while break { } in some situations (only if in another loop, etc), it is probably a good idea to write a more extended explanation and in particular to show an example of how to add a label (i.e., 'a: while break 'a { })

What do you think?

For (a), it seems fine to me either way. I'll merge them if you think that'd be simpler.

For (b), I'm happy to write a more extended error explanation (assuming you mean using register_long_diagnostics!).

bors · 2017-02-24T11:18:15Z

⌛ Testing commit 6f0447b with merge d84b197...

Normalize labeled and unlabeled breaks Part of #39849.

bors · 2017-02-24T12:34:05Z

💔 Test failed - status-travis

cramertj · 2017-02-25T01:03:15Z

Error linking-- the failing test is for#25185. Seems spurious. Can someone retry this or add it to a rollup? Is there any better way for me to try to get this through? It got r+'d six days ago.

alexcrichton · 2017-02-25T06:38:13Z

@bors: retry

osx linker segfault OSX linker segfaulting on Travis #38878

…tsakis Normalize labeled and unlabeled breaks Part of rust-lang#39849.

Rollup of 28 pull requests - Successful merges: #39859, #39864, #39888, #39903, #39905, #39914, #39945, #39950, #39953, #39961, #39980, #39988, #39993, #39995, #40019, #40020, #40022, #40024, #40025, #40026, #40027, #40031, #40035, #40037, #40038, #40064, #40069, #40086 - Failed merges: #39927, #40008, #40047

bors · 2017-02-25T15:00:38Z

⌛ Testing commit 6f0447b with merge 1572bf1...

…tsakis Add catch {} to AST Part of rust-lang#39849. Builds on rust-lang#39864.

Add catch {} to AST Part of #39849. Builds on #39864.

rust-highfive assigned eddyb Feb 15, 2017

rust-highfive assigned nikomatsakis and unassigned eddyb Feb 15, 2017

nikomatsakis requested changes Feb 16, 2017

View reviewed changes

cramertj force-pushed the normalize-breaks branch from 1049ae5 to 948cbf3 Compare February 16, 2017 16:45

nikomatsakis reviewed Feb 17, 2017

View reviewed changes

cramertj force-pushed the normalize-breaks branch 2 times, most recently from 4116cc2 to c2fc090 Compare February 17, 2017 18:52

nikomatsakis approved these changes Feb 17, 2017

View reviewed changes

cramertj mentioned this pull request Feb 17, 2017

Add catch {} to AST #39921

Merged

cramertj force-pushed the normalize-breaks branch from c2fc090 to d5ac679 Compare February 18, 2017 02:56

Normalize labeled and unlabeled breaks

5205e2f

cramertj force-pushed the normalize-breaks branch from d5ac679 to 206e1d8 Compare February 18, 2017 02:58

nikomatsakis reviewed Feb 18, 2017

View reviewed changes

Properly implement labeled breaks in while conditions

4d65622

cramertj force-pushed the normalize-breaks branch from 206e1d8 to 59ce986 Compare February 18, 2017 20:29

Add tests for control flow in while condition

56e519d

bors added a commit that referenced this pull request Feb 24, 2017

Auto merge of #39864 - cramertj:normalize-breaks, r=nikomatsakis

d84b197

Normalize labeled and unlabeled breaks Part of #39849.

eddyb added a commit to eddyb/rust that referenced this pull request Feb 25, 2017

Rollup merge of rust-lang#39864 - cramertj:normalize-breaks, r=nikoma…

2cf3aa7

…tsakis Normalize labeled and unlabeled breaks Part of rust-lang#39849.

eddyb mentioned this pull request Feb 25, 2017

Rollup of 29 pull requests #40089

Closed

eddyb added a commit to eddyb/rust that referenced this pull request Feb 25, 2017

Rollup merge of rust-lang#39864 - cramertj:normalize-breaks, r=nikoma…

ad9079b

…tsakis Normalize labeled and unlabeled breaks Part of rust-lang#39849.

eddyb mentioned this pull request Feb 25, 2017

Rollup of 28 pull requests #40091

Merged

bors merged commit 6f0447b into rust-lang:master Feb 25, 2017

TimNN mentioned this pull request Mar 3, 2017

Rustc scoping regression #40235

Closed

cramertj mentioned this pull request Mar 7, 2017

It is not intuitive which loop is broken out from in loop { while break {} } #37576

Closed

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Mar 8, 2017

Rollup merge of rust-lang#39921 - cramertj:add-catch-to-ast, r=nikoma…

cd9e0e7

…tsakis Add catch {} to AST Part of rust-lang#39849. Builds on rust-lang#39864.

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Mar 9, 2017

Rollup merge of rust-lang#39921 - cramertj:add-catch-to-ast, r=nikoma…

ded49bc

…tsakis Add catch {} to AST Part of rust-lang#39849. Builds on rust-lang#39864.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Mar 10, 2017

Rollup merge of rust-lang#39921 - cramertj:add-catch-to-ast, r=nikoma…

4b7c16a

…tsakis Add catch {} to AST Part of rust-lang#39849. Builds on rust-lang#39864.

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Mar 10, 2017

Rollup merge of rust-lang#39921 - cramertj:add-catch-to-ast, r=nikoma…

e2d3770

…tsakis Add catch {} to AST Part of rust-lang#39849. Builds on rust-lang#39864.

bors added a commit that referenced this pull request Mar 14, 2017

Auto merge of #39921 - cramertj:add-catch-to-ast, r=nikomatsakis

6f10e2f

Add catch {} to AST Part of #39849. Builds on #39864.

cramertj deleted the normalize-breaks branch September 21, 2017 16:10

kennytm mentioned this pull request May 18, 2018

'a: while break 'a{} results in illigal instruction #50856

Closed

varkor mentioned this pull request May 19, 2018

Fix illegal instruction error when breaking within condition of labelled while loop #50877

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normalize labeled and unlabeled breaks #39864

Normalize labeled and unlabeled breaks #39864

cramertj commented Feb 15, 2017

rust-highfive commented Feb 15, 2017

cramertj commented Feb 15, 2017

cramertj commented Feb 16, 2017

nikomatsakis left a comment •

edited

Loading

nikomatsakis Feb 16, 2017

cramertj Feb 16, 2017

nikomatsakis Feb 16, 2017

nikomatsakis Feb 16, 2017

cramertj Feb 16, 2017

nikomatsakis Feb 16, 2017

cramertj Feb 16, 2017 •

edited

Loading

nikomatsakis Feb 16, 2017

nikomatsakis Feb 16, 2017

nikomatsakis Feb 16, 2017

nikomatsakis Feb 16, 2017

nikomatsakis Feb 16, 2017

nikomatsakis commented Feb 16, 2017

nikomatsakis Feb 17, 2017

nikomatsakis commented Feb 17, 2017

nikomatsakis commented Feb 17, 2017

nikomatsakis commented Feb 18, 2017 •

edited

Loading

nikomatsakis commented Feb 18, 2017

nikomatsakis commented Feb 18, 2017 •

edited

Loading

cramertj commented Feb 18, 2017 •

edited

Loading

nikomatsakis commented Feb 18, 2017

nikomatsakis commented Feb 18, 2017

cramertj commented Feb 18, 2017

nikomatsakis Feb 18, 2017

cramertj Feb 18, 2017

bors commented Feb 24, 2017

bors commented Feb 24, 2017

cramertj commented Feb 25, 2017

alexcrichton commented Feb 25, 2017

bors commented Feb 25, 2017

Normalize labeled and unlabeled breaks #39864

Normalize labeled and unlabeled breaks #39864

Conversation

cramertj commented Feb 15, 2017

rust-highfive commented Feb 15, 2017

cramertj commented Feb 15, 2017

cramertj commented Feb 16, 2017

nikomatsakis left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cramertj Feb 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Feb 16, 2017

Choose a reason for hiding this comment

nikomatsakis commented Feb 17, 2017

nikomatsakis commented Feb 17, 2017

nikomatsakis commented Feb 18, 2017 • edited Loading

nikomatsakis commented Feb 18, 2017

nikomatsakis commented Feb 18, 2017 • edited Loading

cramertj commented Feb 18, 2017 • edited Loading

nikomatsakis commented Feb 18, 2017

nikomatsakis commented Feb 18, 2017

cramertj commented Feb 18, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Feb 24, 2017

bors commented Feb 24, 2017

cramertj commented Feb 25, 2017

alexcrichton commented Feb 25, 2017

bors commented Feb 25, 2017

nikomatsakis left a comment •

edited

Loading

cramertj Feb 16, 2017 •

edited

Loading

nikomatsakis commented Feb 18, 2017 •

edited

Loading

nikomatsakis commented Feb 18, 2017 •

edited

Loading

cramertj commented Feb 18, 2017 •

edited

Loading