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

E0267 is used twice in different struct_span_err calls #63712

Closed
estebank opened this issue Aug 19, 2019 · 4 comments · Fixed by #63780
Closed

E0267 is used twice in different struct_span_err calls #63712

estebank opened this issue Aug 19, 2019 · 4 comments · Fixed by #63780
Assignees
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@estebank
Copy link
Contributor

estebank commented Aug 19, 2019

The following code

Closure => {
struct_span_err!(self.sess, span, E0267, "`{}` inside of a closure", name)
.span_label(span, "cannot break inside of a closure")
.emit();
}
AsyncClosure => {
struct_span_err!(self.sess, span, E0267, "`{}` inside of an async block", name)
.span_label(span, "cannot break inside of an async block")
.emit();
}

Should either assign a new error code to the AsyncClosure case, or move the common code to a closure and call it from those two branches to avoid using the same error code twice:

warning: diagnostic code E0267 already used
   --> <::syntax::diagnostics::macros::struct_span_err macros>:3:6
    |
1   | / ($ session : expr , $ span : expr , $ code : ident , $ ($ message : tt) *) =>
2   | | ({
3   | |      __diagnostic_used ! ($ code) ; $ session . struct_span_err_with_code
    | |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4   | |      ($ span , & format ! ($ ($ message) *) , $ crate :: errors ::
5   | |       DiagnosticId :: Error (stringify ! ($ code) . to_owned ()) ,)
6   | |  })
    | |___- in this expansion of `struct_span_err!`
    |
   ::: src/librustc_passes/loops.rs:181:17
    |
181 |                   struct_span_err!(self.sess, span, E0267, "`{}` inside of an async block", name)
    |                   ------------------------------------------------------------------------------- in this macro invocation
    |
note: previous invocation
   --> <::syntax::diagnostics::macros::struct_span_err macros>:3:6
    |
1   | / ($ session : expr , $ span : expr , $ code : ident , $ ($ message : tt) *) =>
2   | | ({
3   | |      __diagnostic_used ! ($ code) ; $ session . struct_span_err_with_code
    | |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4   | |      ($ span , & format ! ($ ($ message) *) , $ crate :: errors ::
5   | |       DiagnosticId :: Error (stringify ! ($ code) . to_owned ()) ,)
6   | |  })
    | |___- in this expansion of `struct_span_err!`
    |
   ::: src/librustc_passes/loops.rs:176:17
    |
176 |                   struct_span_err!(self.sess, span, E0267, "`{}` inside of a closure", name)
    |                   -------------------------------------------------------------------------- in this macro invocation

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

@estebank estebank added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 19, 2019
@awaitlink
Copy link
Contributor

awaitlink commented Aug 20, 2019

@rustbot claim

I'm not sure why it's closure in Closure but async block in AsyncClosure, shouldn't it be async closure? If there's a reason for this difference I'd say a new error code is better?

@estebank
Copy link
Contributor Author

It seems to me that calling it an async closure instead would be reasonable. It would also be nice to point at the def_span(block.span) like it's done here:

if let Node::Block(block) = self.hir_map.find(loop_id).unwrap() {
struct_span_err!(self.sess, e.span, E0696,
"`continue` pointing to a labeled block")
.span_label(e.span,
"labeled blocks cannot be `continue`'d")
.span_note(block.span,
"labeled block the continue points to")
.emit();

That way the output wouldn't be

error[E0267]: `continue` inside of an async block
 --> src/main.rs:6:9
  |
6 |         continue;
  |         ^^^^^^^^ cannot break inside of an async block

but rather

error[E0267]: `continue` inside of an `async` closure
 --> src/main.rs:6:9
  |
5 | let _ = async || {
  |         -------- enclosing `async` closure
6 |         continue;
  |         ^^^^^^^^ cannot `continue` inside of an `async` closure

@awaitlink
Copy link
Contributor

It appears that there is a good reason for calling it async block, for example this is what I got to (I'm using the Span of hir::ExprKind::Closure):

Regular closure:

error[E0267]: `break` inside of a closure
  --> $DIR/E0267.rs:5:18
   |
LL |     let _ = || { break; };
   |             --   ^^^^^ cannot `break` inside of a closure
   |             |
   |             enclosing closure

Async closure (note: closure block is highlighted, not the closure itself):

error[E0267]: `break` inside of an `async` closure
  --> $DIR/E0267.rs:7:24
   |
LL |     let _ = async || { break; };
   |                      --^^^^^---
   |                      | |
   |                      | cannot `break` inside of an `async` closure
   |                      enclosing `async` closure

Async block:

error[E0267]: `break` inside of an `async` closure
  --> $DIR/async-block-control-flow-static-semantics.rs:35:9
   |
LL |       async {
   |  ___________-
LL | |         break 0u8;
   | |         ^^^^^^^^^ cannot `break` inside of an `async` closure
LL | |     };
   | |_____- enclosing `async` closure

So in this case leaving it as async block makes sense?

@estebank
Copy link
Contributor Author

That's fine.

@bors bors closed this as completed in 3a1eb34 Aug 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. 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.

3 participants