-
Notifications
You must be signed in to change notification settings - Fork 13.4k
error[E0308]: mismatched types expected fn pointer, found fn item
#121830
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Interesting. The PR in question (#118247) does come with deliberate breaking changes that were found not to be an issue in crater runs. However I find this particular code being broken surprising.1 Here’s a few more test cases (the ones that #![allow(unused)]
type One = for<'a> fn(&'a (), &'a ());
type Two = for<'a, 'b> fn(&'a (), &'b ());
fn f(x: One) {
let y: Two = x; // okay
let arr = [x, x]; // okay
let _: [Two; 2] = arr; // okay
let _: [Two; 2] = [x, x]; // fails (regression)
[y, x]; // fails (regression)
[x, y]; // fails (regression)
same(x, y); // okay
[x, y as _]; // fails (regression)
}
fn same<T>(_: T, _: T) {} So it almost seems to me like this is some special logic around arrays that can’t handle the new situation after #118247. Perhaps either it’s some handling specifically of functions/function pointers in array expressions; or perhaps generally handling of subtyping there, as we have two distinct types now that are subtypes of each other. Ah wait, here’s another test for that: [(x,), (y,)]; // okay
let x_: (One,) = (x,);
let y_: (Two,) = (y,);
[x_, y_]; // okay Okay, so it’s more like specifically functions in arrays that are handled weirdly. Maybe that special handling is related to the kind of logic that powers fn f() {}
fn g() {}
fn main() {
let x = [f, g];
} to compile successfully, deducing the type didn’t that also work with fn same<T>(_: T, _: T) {}
fn f() {}
fn g() {}
fn main() {
same(f, g); // fails (expected, no regression here!)
match () {
_ => f,
_ => g, // works
};
} yes it did! So let’s test if it’s the same type One = for<'a> fn(&'a (), &'a ());
type Two = for<'a, 'b> fn(&'a (), &'b ());
fn f(x: One) {
let y: Two = x;
match 0 {
_ => x,
_ => y, // fails (regression)
};
} yes, indeed! So the issue is not in array-specific code, but specifically in the code that finds a good “common type” for function items / pointers in array expressions, Footnotes
|
But… funky behavior with function pointers in arrays isn’t new, apparently. type One = for<'a> fn(&'a ());
type Two = fn(&'static ());
// One is subtype of Two
fn same<T>(_: T, _: T) {}
// consistent behavior, same on stable and nightly
fn f(x: One) {
let y: Two = x;
[y, x]; // fails (also on stable, no regression)
same(y, x); // works
[(y,), (x,)]; // works
["", &String::new()]; // works
[&String::new(), ""]; // works, wait… how‽…
[(x,), (y,)]; // fails… as expected, if it takes the
// type of the first element as “correct” (also on stable, no regression)
same(x, y); // fails as expected (also on stable, no regression)
} I wonder if there’s an issue tracking this inconsistent behavior already. Similarly, this mirrors the original issue repro, but with analogous behavior that also fails on stable pub fn foo(_: &i32) {}
pub const _: [fn(&'static i32); 2] = [foo, foo]; // fails (also on stable, no regression)
|
expected fn pointer, found fn ite
expected fn pointer, found fn item
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
Uh oh!
There was an error while loading. Please reload this page.
Code
I tried this code:
I expected to see this happen: compile successfully
Instead, this happened:
Version it worked on
It most recently worked on:
nightly-2024-02-29
Version with regression
searched nightlies: from nightly-2024-02-28 to nightly-2024-03-01
regressed nightly: nightly-2024-03-01
searched commit range: c475e23...878c8a2
regressed commit: 878c8a2 cc @spastorino
bisected with cargo-bisect-rustc v0.6.8
Host triple: x86_64-unknown-linux-gnu
Reproduce with:
@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged
The text was updated successfully, but these errors were encountered: