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

E0004 says "note: Option<i32> defined here" when it's not #101068

Closed
carols10cents opened this issue Aug 27, 2022 · 5 comments
Closed

E0004 says "note: Option<i32> defined here" when it's not #101068

carols10cents opened this issue Aug 27, 2022 · 5 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints P-medium Medium priority 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.

Comments

@carols10cents
Copy link
Member

carols10cents commented Aug 27, 2022

I just noticed this regression from 1.60 to 1.61 because TRPL reasons.

Code

Given the following code:

fn main() {
    let some_option_value: Option<i32> = None;
    let Some(x) = some_option_value;
}

The current output is:

error[E0005]: refutable pattern in local binding: `None` not covered
 --> src/main.rs:3:9
  |
3 |     let Some(x) = some_option_value;
  |         ^^^^^^^ pattern `None` not covered
  |
  = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
  = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
note: `Option<i32>` defined here
  = note: the matched value is of type `Option<i32>`
help: you might want to use `if let` to ignore the variant that isn't matched
  |
3 |     let x = if let Some(x) = some_option_value { x } else { todo!() };
  |     ++++++++++                                 ++++++++++++++++++++++

Notice especially this line:

note: `Option<i32>` defined here

Which... raises a few questions...

  1. I definitely did not define Option<i32> in this code, so I don't know why this note is saying I did
  2. Or is it saying that? The note doesn't point to what it thinks "here" is.
  3. What is this note trying to tell me about, really?

Ideally the output shouldn't have this line, I don't think.

Versions with regression

This problem started with 1.61 and still exists in 1.63.0, 1.64.0-beta.3, and nightly 2022-08-25 7480389.

@rustbot modify labels: +regression-untriaged

@carols10cents carols10cents added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 27, 2022
@rustbot rustbot added regression-untriaged Untriaged performance or correctness regression. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Aug 27, 2022
@obeis
Copy link
Contributor

obeis commented Aug 28, 2022

@rustbot claim

@apiraino
Copy link
Contributor

apiraino commented Aug 31, 2022

in case it's useful, the bisection points to the nightly-2022-03-09 and this rollup merge:

  commit[0] 2022-03-07UTC: Auto merge of #94706 - matthiaskrgr:rollup-l5erynr, r=matthiaskrgr
  commit[1] 2022-03-07UTC: Auto merge of #94709 - martingms:link-to-chunked-opt-pr, r=nnethercote
  commit[2] 2022-03-08UTC: Auto merge of #90887 - jackh726:issue-90729, r=nikomatsakis
  commit[3] 2022-03-08UTC: Auto merge of #94716 - RalfJung:miri, r=RalfJung
  commit[4] 2022-03-08UTC: Auto merge of #94734 - matthiaskrgr:rollup-28shqhy, r=matthiaskrgr
  commit[5] 2022-03-08UTC: Auto merge of #92260 - jyn514:less-python-logic, r=Mark-Simulacrum
  commit[6] 2022-03-08UTC: Auto merge of #94702 - b-naber:static-refs-mir, r=lcnr

two of the them are also rollups 🙄 I think the most likely is #94734 (possibly #94580?)

@apiraino
Copy link
Contributor

apiraino commented Sep 1, 2022

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

@rustbot rustbot added P-medium Medium priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Sep 1, 2022
@obeis obeis removed their assignment Dec 22, 2022
@Jules-Bertholet
Copy link
Contributor

Seems to have been fixed in 1.68: https://rust.godbolt.org/z/5no68WMPx

@rustbot label -regression-untriaged +regression-from-stable-to-stable

@rustbot rustbot added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-untriaged Untriaged performance or correctness regression. labels Jun 10, 2023
@apiraino
Copy link
Contributor

then I'm going to close this as fixed (feel free to reopen if you disagree)

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 P-medium Medium priority 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.
Projects
None yet
Development

No branches or pull requests

5 participants