typestate sees break as applying to the outermost loop

The following code compiles (as expected):

fn main() {
    let _x: uint = loop { };
}

However, this code does not, as if the break were breaking out of the outer loop:

fn main() {
    let _x: uint = loop { loop { break; } };
}

this may be a liveness bug?

@paulstansifer

Maybe, but I'm pretty sure I know what the bug is if it's in typestate. @paulstansifer , can you post the error message?

actually I think this is neither liveness nor typestate but rather typeck and something off in the (rather hokey) way that it tracks the notion of "bottom".

this is the error that I see:

/Users/nmatsakis/tmp/issue-2642.rs:2:19: 2:43 error: mismatched types: expected `uint` but found `()` (uint vs ())
/Users/nmatsakis/tmp/issue-2642.rs:2     let _x: uint = loop { loop { break; } };
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~

Yeah, not a typestate error. I can still take a look, though.

To be honest, I am not sure that the type system ought to be in the business of tracking bottom.

Oops, sorry folks. That's the same as the error I get.

It's really useful if you want to return from inside an otherwise infinite loop, which is what led me to this bug.

but why are you "assigning" the loop to a local variable in the first place?

it seems to me that loops and complex constructs that may or may not be bottom should just have unit type. Something like ret or what have you can still have bottom type.

I probably should've reduced it to an example that looks more like the code I'm interested in:

fn f() -> uint {
  loop {
    if some_cond { ret 8u; }
    loop { break; }
  }
}

In this case, we need bottom to acknowledge that nothing will ever fall off the end of the outer loop, preventing the need for a dummy, dead code ret statement.

I think I usually just use fail if I need to convince the compiler that some code will never run.

Yes, but the point of introducing loop was to make it possible to omit fails in some common cases... so I'm with Paul at least until I look at the typeck code and decide it's too hard to fix ;-)

Paul's example is more convincing. I guess we have to make it work due to the fact that loops are expressions and can appear in tail position in a block. sigh

Auto merge of rust-lang#2642 - Rageking8:followup-for-pr-2640, r=Ralf…

Merge pull request rust-lang#2642 from rust-lang/tshepang/sembr

Merge rust-lang#2642

Navigation Menu

Repository navigation

typestate sees `break` as applying to the outermost loop #2642

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

typestate sees break as applying to the outermost loop #2642

Description

Activity

nikomatsakis commented on Jun 18, 2012

catamorphism commented on Jun 18, 2012

nikomatsakis commented on Jun 18, 2012

nikomatsakis commented on Jun 18, 2012

catamorphism commented on Jun 18, 2012

nikomatsakis commented on Jun 18, 2012

paulstansifer commented on Jun 18, 2012

paulstansifer commented on Jun 18, 2012

nikomatsakis commented on Jun 18, 2012

nikomatsakis commented on Jun 18, 2012

paulstansifer commented on Jun 18, 2012

eholk commented on Jun 18, 2012

catamorphism commented on Jun 19, 2012

nikomatsakis commented on Jun 19, 2012

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

typestate sees `break` as applying to the outermost loop #2642