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

Confusing 'unreachable code' error message when macro is involved #64590

Closed
Aaron1011 opened this issue Sep 18, 2019 · 1 comment · Fixed by #64592
Closed

Confusing 'unreachable code' error message when macro is involved #64590

Aaron1011 opened this issue Sep 18, 2019 · 1 comment · Fixed by #64592
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Aaron1011
Copy link
Member

This code:

macro_rules! early_return {
    () => {
        return ()
    }
}

fn main() {
    return early_return!();
}

Gives the following warning:

warning: unreachable expression
 --> src/main.rs:8:5
  |
8 |     return early_return!();
  |     ^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unreachable_code)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 0.40s
     Running `target/debug/playground`

This warning is misleading - it suggests that the entire return statement, including the call to early_return!() is unreachable.

This also occurs in the more 'obviously wrong' case of:

fn main() {
    return return;
}

In general, it could be hard to decide what kind of warning message to generate. I think there are two things we could do to improve error messages in most cases:

  1. If the root cause of the unreachable lint (e.g. whatever produces a !) was generated by a macro, explicitly indicate this in the warning. This should help make it clear to the user that there is hidden control flow going on.
  2. Add special handling for return statements. If possible, try to detect that the cause of the unreachability was 'inside' of the return, and add a note pointing directly at it (e.g. 'the expression ' unconditionally diverges')
@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 18, 2019
@PvdBerg1998
Copy link

PvdBerg1998 commented Sep 19, 2019

Updating to todays nightly, all my async functions where the last expression diverges (because they should return before that) emit unreachable expression warnings. Since it regressed recently, maybe this issue is more relevant than #61798 where I posted originally.

Centril added a commit to Centril/rust that referenced this issue Sep 19, 2019
… r=Centril

Point at original span when emitting unreachable lint

Fixes rust-lang#64590

When we emit an 'unreachable' lint, we now add a note pointing at the
expression that actually causes the code to be unreachable (e.g.
`return`, `break`, `panic`).

This is especially useful when macros are involved, since a diverging
expression might be hidden inside of a macro invocation.
@bors bors closed this as completed in 822393d Sep 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants