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

regression: #[forbid(unreachable_code)] incompatible with the Try ('?') operator #76053

Open
ghost opened this issue Aug 29, 2020 · 4 comments
Open
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ghost
Copy link

ghost commented Aug 29, 2020

I tried this code:

#![forbid(unreachable_code)]

#[allow(dead_code)] // Remove warning.
fn foo() -> Option<()> {
    Some(0)?;
    None // Just so it doesn't emit error here.
}

Both on debug and release it generates an error saying that #[allow(unreachable_code)] was overridden by the #[forbid(...)] attribute, while pointing at the "try" expression.

Meta

rustc --version --verbose:

rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-pc-windows-msvc
release: 1.46.0
LLVM version: 10.0
@ghost ghost added the C-bug Category: This is a bug. label Aug 29, 2020
@LeSeulArtichaut
Copy link
Contributor

According to Godbolt this is the case since 1.22.0 where the Try trait was implemented on Option.

@LeSeulArtichaut
Copy link
Contributor

This bug can also be reproduced with a Result:

#![forbid(unreachable_code)]

#[allow(dead_code)] // Remove warning.
fn foo() -> Result<(), ()> {
    Ok(0)?;
    Err(()) // Just so it doesn't emit error here.
}

Which allows to find out that this regressed in 1.16.0.

@LeSeulArtichaut LeSeulArtichaut added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 29, 2020
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 29, 2020
@jyn514 jyn514 added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Aug 29, 2020
@spastorino
Copy link
Member

Assigning P-low as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@spastorino spastorino added P-low Low priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Sep 2, 2020
@ghost ghost changed the title #[forbid(unreachable_code)] incompatible with the Try ('?') operator regression: #[forbid(unreachable_code)] incompatible with the Try ('?') operator Oct 20, 2020
rursprung added a commit to rust-embedded-community/tb6612fng-rs that referenced this issue Nov 28, 2023
a new warning was caused by the `?` operator as it contains
`#[allow(unreachable_code)]`, which clashes with the previous `forbid`
rule.

as `forbid` does not allow `deny` to override it this would cause a
compile error, however due to a compiler bug this was previously not
reported at all and has now been changed to a warning in a recent(-ish)
version of rustc and will eventually become a compile error.

with `deny` it's still possible to use `allow`, thus there's no warning

see also rust-lang/rust#76053

thanks @jannic
@Dylan-DPC Dylan-DPC added E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. and removed regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Sep 6, 2024
@Dylan-DPC
Copy link
Member

This code now compiles fine, we just need a test added against this to close the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants