Skip to content

Rust fails to coerce to a fn pointer when passing an array as an argument to a generic function. #136420

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

Open
theemathas opened this issue Feb 2, 2025 · 2 comments · May be fixed by #140283
Open
Assignees
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@theemathas
Copy link
Contributor

theemathas commented Feb 2, 2025

I tried this code:

fn foo() {}
fn bar() {}

fn main() {
    let _a = if true { foo } else { bar };
    let _b = vec![foo, bar];
    let _c = [foo, bar];
    d(if true { foo } else { bar });
    e(vec![foo, bar]);
    f([foo, bar]);
}

fn d<T>(_: T) {}
fn e<T>(_: Vec<T>) {}
fn f<T>(_: [T; 2]) {}

I expected the six lines to either all compile or all error. Instead, only the f([foo, bar]) line fails, with the following error:

error[E0308]: mismatched types
  --> src/main.rs:10:7
   |
10 |     f([foo, bar]);
   |     - ^^^^^^^^^^ expected `[fn() {foo}; 2]`, found `[fn(); 2]`
   |     |
   |     arguments to this function are incorrect
   |
   = note: expected array `[fn() {foo}; 2]`
              found array `[fn(); 2]`
note: function defined here
  --> src/main.rs:15:4
   |
15 | fn f<T>(_: [T; 2]) {}
   |    ^    ---------

For more information about this error, try `rustc --explain E0308`.

For some reason, it's failing to coerce the function items into function pointers, but only when an array is being passed to a generic function.

Discovered by @xero-lib

Meta

Issue reproducible on the playground with stable rust 1.84.1, and nightly rust 1.86.0-nightly (2025-02-01 8239a37f9c0951a037cf)

@rustbot labels +A-inference +A-coercions

@theemathas theemathas added the C-bug Category: This is a bug. label Feb 2, 2025
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-coercions Area: implicit and explicit `expr as Type` coercions A-inference Area: Type inference labels Feb 2, 2025
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Feb 4, 2025
@Noratrieb Noratrieb removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 1, 2025
@adwinwhite
Copy link
Contributor

adwinwhite commented Apr 14, 2025

The cause is that f's type parameter is resolved during the coercion of the first element, rather than based on the final type of the array. Refer to fcx.coerce in CoerceMany::coerce_inner.

@adwinwhite
Copy link
Contributor

@rustbot claim

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 A-inference Area: Type inference C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants