-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Add help message about function pointers #105552
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cjgillot (or someone else) soon. Please see the contribution instructions for more information. |
r? rust-lang/diagnostics |
Ah, i forgot to run the test suite 😅. |
@rustbot author When you are ready for the review, please use |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
476adb8
to
59ebb65
Compare
@rustbot ready |
src/test/ui/higher-rank-trait-bounds/hrtb-exists-forall-fn.stderr
Outdated
Show resolved
Hide resolved
305abb8
to
bfdfb85
Compare
r? @compiler-errors I'll review this soon |
src/test/ui/fn/fn-item-type.rs
Outdated
//~| different `fn` items always have unique types, even if their signatures are the same | ||
//~| change the expected type to be function pointer | ||
//~| if the expected type is due to type inference, cast the expected `fn` to a function pointer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did these notes go? Is there a good reason they disappeared?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The note about fn items being unique is still there, however the rest of the deleted notes are making a suggestion that would not result in working code.
If you follow the advice of casting to function pointers (in this example), this is the result
error[E0308]: arguments to this function are incorrect
--> cases/1.rs:19:5
|
19 | eq(foo::<u8> as fn(isize) -> isize, bar::<u8> as fn(isize) -> isize);
| ^^
|
note: expected `*const _`, found fn pointer
--> cases/1.rs:19:8
|
19 | eq(foo::<u8> as fn(isize) -> isize, bar::<u8> as fn(isize) -> isize);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: expected raw pointer `*const _`
found fn pointer `fn(isize) -> isize`
note: expected `*const _`, found fn pointer
--> cases/1.rs:19:41
|
19 | eq(foo::<u8> as fn(isize) -> isize, bar::<u8> as fn(isize) -> isize);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: expected raw pointer `*const _`
found fn pointer `fn(isize) -> isize`
note: function defined here
--> /home/mperez/projects/rustlang/library/core/src/ptr/mod.rs:1827:8
|
1827 | pub fn eq<T: ?Sized>(a: *const T, b: *const T) -> bool {
| ^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
So while the note might be useful for some cases, it wouldn't be a good suggestion in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll come up with a couple other similar cases real quick to see if it might be a good/useful suggestion there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm still having a hard time understanding why this suggestion is incorrect for this UI test. Why are you pointing at std::ptr::eq
when the UI test defines its own fn eq<T>(x: T, y: T) {}
?
For the record, this code works:
fn eq<T: Eq>(a: T, b: T) {}
fn a() {}
fn b() {}
fn main() {
eq(a as fn(), b as fn());
// ^^^^^^^ ^^^^^^^
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You were right. I mistakenly didn't include the locally defined fn eq
when verifying the output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So can we bring this suggestion back then?
5588693
to
7ae4704
Compare
@rustbot ready |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still pretty sad that we're not even vaguely suggesting to use as
to turn a FnDef into a FnPtr. We should be nudging the user to do something even if it's not always a structured suggestion they can apply.
src/test/ui/fn/fn-item-type.rs
Outdated
//~| different `fn` items always have unique types, even if their signatures are the same | ||
//~| change the expected type to be function pointer | ||
//~| if the expected type is due to type inference, cast the expected `fn` to a function pointer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm still having a hard time understanding why this suggestion is incorrect for this UI test. Why are you pointing at std::ptr::eq
when the UI test defines its own fn eq<T>(x: T, y: T) {}
?
For the record, this code works:
fn eq<T: Eq>(a: T, b: T) {}
fn a() {}
fn b() {}
fn main() {
eq(a as fn(), b as fn());
// ^^^^^^^ ^^^^^^^
}
29caebf
to
a67f653
Compare
@compiler-errors Please advise on
|
9d3785b
to
0e6e5d6
Compare
- On compiler-error's suggestion of moving this lower down the stack, along the path of `report_mismatched_types()`, which is used by `rustc_hir_analysis` and `rustc_hir_typeck`. - update ui tests, add test - add suggestions for references to fn pointers - modify `TypeErrCtxt::same_type_modulo_infer` to take `T: relate::Relate` instead of `Ty`
0e6e5d6
to
1e22280
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine for now, though I left a few follow-up notes I'd like to see in a future PR, perhaps.
@@ -8,17 +8,15 @@ LL | eq(foo::<u8>, bar::<u8>); | |||
| | |||
= note: expected fn item `fn(_) -> _ {foo::<u8>}` | |||
found fn item `fn(_) -> _ {bar::<u8>}` | |||
= note: different `fn` items always have unique types, even if their signatures are the same | |||
= help: change the expected type to be function pointer `fn(isize) -> isize` | |||
= help: if the expected type is due to type inference, cast the expected `fn` to a function pointer: `foo::<u8> as fn(isize) -> isize` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- When we have two FnDefs, we should mention that the user can use an
as
to turn them into pointers.
@@ -84,12 +76,11 @@ LL | eq(foo::<u8>, bar::<u8> as fn(isize) -> isize); | |||
| | |||
= note: expected fn item `fn(_) -> _ {foo::<u8>}` | |||
found fn pointer `fn(_) -> _` | |||
= help: change the expected type to be function pointer `fn(isize) -> isize` | |||
= help: if the expected type is due to type inference, cast the expected `fn` to a function pointer: `foo::<u8> as fn(isize) -> isize` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- When we expect a FnDef, and find a FnPtr, we should mention that the user can use an
as
to turn the def into a pointer. Since the span will be pointing at the ptr, not the def, this can't be a suggestion, but it's still worth noting.
I'm inclined to merge this as-is since it's been quite a lot of back-and-forth and I don't want to keep you waiting. If you're free, then please work on the follow-ups in an additional PR, and if you're not, let me know so I can make the changes myself 😃 @bors r+ rollup |
Not a problem! I appreciate all the help and patience you've given with this one. I can make the changes in a follow-up PR. |
Rollup of 9 pull requests Successful merges: - rust-lang#105552 (Add help message about function pointers) - rust-lang#106583 (Suggest coercion of `Result` using `?`) - rust-lang#106767 (Allow setting CFG_DISABLE_UNSTABLE_FEATURES to 0) - rust-lang#106823 (Allow fmt::Arguments::as_str() to return more Some(_).) - rust-lang#107166 (rustc_metadata: Support non-`Option` nullable values in metadata tables) - rust-lang#107213 (Add suggestion to remove if in let..else block) - rust-lang#107223 (`sub_ptr()` is equivalent to `usize::try_from().unwrap_unchecked()`, not `usize::from().unwrap_unchecked()`) - rust-lang#107227 (`new_outside_solver` -> `evaluate_root_goal`) - rust-lang#107232 (rustdoc: simplify settings popover DOM, CSS, JS) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…s, r=compiler-errors Improve fn pointer notes continuation of rust-lang#105552 r? `@compiler-errors`
Fix #102608