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

Using let pattern with ref results in 'mismatched types' when combined with 'panic!()' #118113

Open
Aaron1011 opened this issue Nov 20, 2023 · 2 comments · May be fixed by #118270
Open

Using let pattern with ref results in 'mismatched types' when combined with 'panic!()' #118113

Aaron1011 opened this issue Nov 20, 2023 · 2 comments · May be fixed by #118270
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Aaron1011
Copy link
Member

I tried this code:

struct Foo {
    bar: u8
}

fn main() {
    let Foo { ref bar } = panic!();
}

I expected to see this happen: The code should compile successfully by coercing the ! from panic!() to Foo.

Instead, this happened: rustc produces the following error:

error[E0308]: mismatched types
 --> src/main.rs:6:9
  |
6 |     let Foo { ref bar } = panic!();
  |         ^^^^^^^^^^^^^^^   -------- this expression has type `!`
  |         |
  |         expected `!`, found `Foo`
  |
  = note: expected type `!`
           found struct `Foo`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` (bin "playground") due to previous error

The code compiles successfully if the ref keyword is removed.

Meta

rustc --version --verbose:

rustc 1.76.0-nightly (2b603f95a 2023-11-12)
binary: rustc
commit-hash: 2b603f95a48f10f931a61dd208fe3e5ffd64e491
commit-date: 2023-11-12
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.4

@Aaron1011 Aaron1011 added the C-bug Category: This is a bug. label Nov 20, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 20, 2023
@Aaron1011 Aaron1011 added A-coercions Area: implicit and explicit `expr as Type` coercions and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Nov 20, 2023
@estebank estebank added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 21, 2023
@compiler-errors
Copy link
Member

For the record, this is also edition-2021 specific behavior. I assume this has to do with a difference between the implementation of panic_2015 and panic_2021.

@Aaron1011
Copy link
Member Author

Simplified further:

struct Foo {
    bar: u8
}

fn main() {
    let Foo { ref bar } = loop {};
}

This is because we avoid performing coercions when we have a ref binding:

if let Some(m) = ref_bindings {
// Somewhat subtle: if we have a `ref` binding in the pattern,
// we want to avoid introducing coercions for the RHS. This is
// both because it helps preserve sanity and, in the case of
// ref mut, for soundness (issue #23116). In particular, in
// the latter case, we need to be clear that the type of the
// referent for the reference that results is *equal to* the
// type of the place it is referencing, and not some
// supertype thereof.
let init_ty = self.check_expr_with_needs(init, Needs::maybe_mut_place(m));
if let Some(mut diag) = self.demand_eqtype_diag(init.span, local_ty, init_ty) {

Ideally, we would have a 'minimal coercions' method that just tries to apply Adjust::NeverToAny - however, this might require a lot of refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants