Skip to content

try-blocks and label-break-value do not work together. #72483

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
jonhoo opened this issue May 23, 2020 · 3 comments · Fixed by #72581
Closed

try-blocks and label-break-value do not work together. #72483

jonhoo opened this issue May 23, 2020 · 3 comments · Fixed by #72581
Assignees
Labels
C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. F-label_break_value `#![feature(label_break_value)]` F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jonhoo
Copy link
Contributor

jonhoo commented May 23, 2020

I've been playing around with label-break-value today, and it comes in super handy in async blocks. However, it seems to run into issues when combined with the try_blocks feature.

I tried this code:

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: {
            Err(())?;
            break 'foo;
        }
    };
}

I expected to see this happen: the code should compile just fine.

Instead, this happened:

error[E0695]: unlabeled `break` inside of a labeled block
 --> src/main.rs:6:20
  |
6 |             Err(())?;
  |                    ^ `break` statements that would diverge to or through a labeled block need to bear a label

error: aborting due to previous error

This is a continuation of the discussion here. As @ciphergoth pointed out, this code (following the syntactic sugar from the label-break-value RFC) compiles:

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: loop {
            break {
                Err(())?;
                break 'foo;
            }
        }
    };
}

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (a74d1862d 2020-05-14)

This issue has been assigned to @samrat via this comment.

@jonhoo jonhoo added the C-bug Category: This is a bug. label May 23, 2020
@jonas-schievink jonas-schievink added F-try_blocks `#![feature(try_blocks)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. requires-nightly This issue requires a nightly compiler in some way. F-label_break_value `#![feature(label_break_value)]` and removed F-try_blocks `#![feature(try_blocks)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 23, 2020
@nikomatsakis
Copy link
Contributor

So the error is generated here

if self.require_label_in_labeled_block(e.span, &label, "break") {
// If we emitted an error about an unlabeled break in a labeled
// block, we don't need any further checking for this break any more
return;

if I had to guess, I would assume that this function

fn require_label_in_labeled_block(
&mut self,
span: Span,
label: &Destination,
cf_type: &str,
) -> bool {

ought to be modified to check whether the span.is_desugaring(QuestionMark) and, if so, not to emit the error. (See is_desugaring rust docs for a bit more info.)

@nikomatsakis nikomatsakis added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels May 23, 2020
@nikomatsakis
Copy link
Contributor

Tagged as E-mentor since there are some instructions above.

@samrat
Copy link
Contributor

samrat commented May 23, 2020

@rustbot claim

@rustbot rustbot self-assigned this May 23, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 26, 2020
…eled-block, r=davidtwco

Allow unlabeled breaks from desugared `?` in labeled blocks

`?` is desugared into a `break` targeting the innermost `try` scope in which it resides. The `break` however will not have a label. https://github.com/rust-lang/rust/blob/master/src/librustc_ast_lowering/expr.rs#L1560

Since the `target` of the `break` is known, the compiler should not complain about an unlabeled jump for `break`s desugared from `?`.

Closes rust-lang#72483
@bors bors closed this as completed in 5fb7210 May 27, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. F-label_break_value `#![feature(label_break_value)]` F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants