Rollup merge of #109896 - Nilstrieb:integers-are-not-fn-ptrs-remember…

…-this-dear-transmuter, r=compiler-errors

Never consider int and float vars for `FnPtr` candidates

This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope.

For integers it shouldn't be a problem in practice so I wasn't able to add a test.

I'm not sure whether there could be more issues hidden in the shadows as mentioned in the issue, but this should at least fix the problematic regression immediately.

fixes #109892

r? oli-obk

compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs

@@ -998,8 +998,14 @@ impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> {
             | ty::Alias(..)
             | ty::Param(..)
             | ty::Bound(..)
-            | ty::Error(_) => {}
-            ty::Infer(_) => {
+            | ty::Error(_)
+            | ty::Infer(
+                ty::InferTy::IntVar(_)
+                | ty::InferTy::FloatVar(_)
+                | ty::InferTy::FreshIntTy(_)
+                | ty::InferTy::FreshFloatTy(_),
+            ) => {}
+            ty::Infer(ty::InferTy::TyVar(_) | ty::InferTy::FreshTy(_)) => {
                 candidates.ambiguous = true;
             }
         }

compiler/rustc_trait_selection/src/traits/select/mod.rs

@@ -177,14 +177,14 @@ struct TraitObligationStack<'prev, 'tcx> {
 }
 
 struct SelectionCandidateSet<'tcx> {
-    // A list of candidates that definitely apply to the current
-    // obligation (meaning: types unify).
+    /// A list of candidates that definitely apply to the current
+    /// obligation (meaning: types unify).
     vec: Vec<SelectionCandidate<'tcx>>,
 
-    // If `true`, then there were candidates that might or might
-    // not have applied, but we couldn't tell. This occurs when some
-    // of the input types are type variables, in which case there are
-    // various "builtin" rules that might or might not trigger.
+    /// If `true`, then there were candidates that might or might
+    /// not have applied, but we couldn't tell. This occurs when some
+    /// of the input types are type variables, in which case there are
+    /// various "builtin" rules that might or might not trigger.
     ambiguous: bool,
 }
 

tests/ui/fn/fn-ptr-trait-int-float-infer-var.rs

@@ -0,0 +1,10 @@
+// check-pass
+trait MyCmp {
+    fn cmp(&self) {}
+}
+impl MyCmp for f32 {}
+
+fn main() {
+    // Ensure that `impl<F: FnPtr> Ord for F` is never considered for int and float infer vars.
+    0.0.cmp();
+}