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.
This commit is contained in:
Nilstrieb 2023-04-03 15:23:08 +00:00
parent d0eed58a1e
commit ca79b82c6c
3 changed files with 24 additions and 8 deletions

View File

@ -998,8 +998,14 @@ fn assemble_candidates_for_fn_ptr_trait(
| 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;
}
}

View File

@ -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,
}

View File

@ -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();
}