Skip to content

Wrong underlined argument in tuple returned by function #117846

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

Closed
GuillaumeGomez opened this issue Nov 12, 2023 · 6 comments · Fixed by #122119
Closed

Wrong underlined argument in tuple returned by function #117846

GuillaumeGomez opened this issue Nov 12, 2023 · 6 comments · Fixed by #122119
Labels
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.

Comments

@GuillaumeGomez
Copy link
Member

GuillaumeGomez commented Nov 12, 2023

Code

fn get_arguments(data: &[u8]) -> (Vec<String>, &[u8]) {
    (Vec::new(), data)
}

let x = true;
let cmd = &[1, 2, 3, 4];
let (cmd, proc_args) = if x {
    get_arguments(cmd)
} else {
    (Vec::new(), &[])
};

Current output

error[E0277]: the size for values of type `[_]` cannot be known at compilation time
   --> src/unix/apple/macos/process.rs:581:10
    |
581 |     let (cmd, proc_args) = if x {
    |          ^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `[_]`
    = note: all local variables must have a statically known size
    = help: unsized locals are gated as an unstable feature

Desired output

error[E0277]: the size for values of type `[_]` cannot be known at compilation time
   --> src/unix/apple/macos/process.rs:581:10
    |
581 |     let (cmd, proc_args) = if x {
    |               ^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `[_]`
    = note: all local variables must have a statically known size
    = help: unsized locals are gated as an unstable feature

Rationale and extra context

It's underlining the wrong argument.

Other cases

No response

Anything else?

No response

@GuillaumeGomez GuillaumeGomez 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 Nov 12, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 12, 2023
@bjorn3
Copy link
Member

bjorn3 commented Nov 12, 2023

I'm getting an entirely different and much more helpful error:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8ef43273677bf72e3c82fb026cf4d1b8

error[E0308]: `if` and `else` have incompatible types
  --> src/main.rs:11:5
   |
8  |   let (cmd, proc_args) = if x {
   |  ________________________-
9  | |     get_arguments(cmd)
   | |     ------------------ expected because of this
10 | | } else {
11 | |     (Vec::new(), &[])
   | |     ^^^^^^^^^^^^^^^^^ expected `(Vec<String>, &[u8])`, found `(Vec<_>, &[_; 0])`
12 | | };
   | |_- `if` and `else` have incompatible types
   |
   = note: expected tuple `(Vec<String>, &[u8])`
              found tuple `(Vec<_>, &[_; 0])`

@compiler-errors
Copy link
Member

Are you sure you minimized the code correctly? Not sure how to repro the example you shared, @GuillaumeGomez.

@GuillaumeGomez
Copy link
Member Author

Arf, sorry about that... Also important to note, I'm using:

$ rustc --version
rustc 1.76.0-nightly (2c1b65ee1 2023-11-11)

I pushed the code with this issue here. However it requires a mac to enter this code.

Just running cargo check is enough to trigger it.

@compiler-errors
Copy link
Member

This should be re-minimized by someone who has a Mac then.

@rustbot label +E-needs-mcve

@rustbot rustbot added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Nov 12, 2023
@Noratrieb Noratrieb removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 14, 2023
@kpreid
Copy link
Contributor

kpreid commented Dec 25, 2023

Minimization:

fn issue_117846_repro() {
    let (cmd, _) = if true {
        produce() //
    } else {
        (Vec::new(), &[])
    };

    accept(&cmd);
}

fn produce() -> (Vec<String>, &'static [u8]) {
    todo!()
}

fn accept(cmd: &[String]) {}

Note that:

  • in all cases (including when I ran the original code), there is now a more sensible type error, and
  • the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch.

It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the Vec<String>, even though it's not the part of the tuple that has the type mismatch.

error[E0308]: `if` and `else` have incompatible types
 --> src/lib.rs:5:9
  |
2 |       let (cmd, _) = if true {
  |  ____________________-
3 | |         produce() //
  | |         --------- expected because of this
4 | |     } else {
5 | |         (Vec::new(), &[])
  | |         ^^^^^^^^^^^^^^^^^ expected `(Vec<String>, &[u8])`, found `(Vec<_>, &[_; 0])`
6 | |     };
  | |_____- `if` and `else` have incompatible types
  |
  = note: expected tuple `(Vec<String>, &[u8])`
             found tuple `(Vec<_>, &[_; 0])`

error[E0277]: the size for values of type `[String]` cannot be known at compilation time
 --> src/lib.rs:2:10
  |
2 |     let (cmd, _) = if true {
  |          ^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `[String]`
  = note: all local variables must have a statically known size
  = help: unsized locals are gated as an unstable feature

Tested on versions:

rustc 1.77.0-nightly (bf8716f1c 2023-12-24)
binary: rustc
commit-hash: bf8716f1cd6416266807706bcae0ecb2e51c9d4a
commit-date: 2023-12-24
host: x86_64-apple-darwin
release: 1.77.0-nightly
LLVM version: 17.0.6

rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-apple-darwin
release: 1.75.0
LLVM version: 17.0.6

@kpreid
Copy link
Contributor

kpreid commented Dec 25, 2023

@rustbot label -E-needs-mcve

@rustbot rustbot removed the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Dec 25, 2023
estebank added a commit to estebank/rust that referenced this issue Mar 7, 2024
estebank added a commit to estebank/rust that referenced this issue Mar 7, 2024
When gathering locals, we introduce a `Sized` obligation for each
binding in the pattern. *After* doing so, we typecheck the init
expression. If this has a type failure, we store `{type error}`, for
both the expression and the pattern. But later we store an inference
variable for the pattern.

We now avoid any override of an existing type on a hir node when they've
already been marked as `{type error}`, and on E0277, when it comes from
`VariableType` we silence the error in support of the type error.

Fix rust-lang#117846
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 7, 2024
Silence unecessary !Sized binding error

When gathering locals, we introduce a `Sized` obligation for each
binding in the pattern. *After* doing so, we typecheck the init
expression. If this has a type failure, we store `{type error}`, for
both the expression and the pattern. But later we store an inference
variable for the pattern.

We now avoid any override of an existing type on a hir node when they've
already been marked as `{type error}`, and on E0277, when it comes from
`VariableType` we silence the error in support of the type error.

Fix rust-lang#117846
estebank added a commit to estebank/rust that referenced this issue Mar 7, 2024
estebank added a commit to estebank/rust that referenced this issue Mar 7, 2024
When gathering locals, we introduce a `Sized` obligation for each
binding in the pattern. *After* doing so, we typecheck the init
expression. If this has a type failure, we store `{type error}`, for
both the expression and the pattern. But later we store an inference
variable for the pattern.

We now avoid any override of an existing type on a hir node when they've
already been marked as `{type error}`, and on E0277, when it comes from
`VariableType` we silence the error in support of the type error.

Fix rust-lang#117846.
estebank added a commit to estebank/rust that referenced this issue Mar 19, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 20, 2024
Silence unecessary !Sized binding error

When gathering locals, we introduce a `Sized` obligation for each
binding in the pattern. *After* doing so, we typecheck the init
expression. If this has a type failure, we store `{type error}`, for
both the expression and the pattern. But later we store an inference
variable for the pattern.

We now avoid any override of an existing type on a hir node when they've
already been marked as `{type error}`, and on E0277, when it comes from
`VariableType` we silence the error in support of the type error.

Fix rust-lang#117846
@bors bors closed this as completed in b1575b7 Mar 20, 2024
bors added a commit to rust-lang/miri that referenced this issue Mar 22, 2024
Silence unecessary !Sized binding error

When gathering locals, we introduce a `Sized` obligation for each
binding in the pattern. *After* doing so, we typecheck the init
expression. If this has a type failure, we store `{type error}`, for
both the expression and the pattern. But later we store an inference
variable for the pattern.

We now avoid any override of an existing type on a hir node when they've
already been marked as `{type error}`, and on E0277, when it comes from
`VariableType` we silence the error in support of the type error.

Fix rust-lang/rust#117846
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 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.

6 participants