Skip to content

Never consider int and float vars for FnPtr candidates #109896

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

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Comment on lines +1008 to 1009
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only case I can think of that could still cause issues, I just hope this was already always ambiguous anyway 🤞.

Copy link
Member Author

@Noratrieb Noratrieb Apr 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to call a method on a ty infer var but that caused errors in typeck about not being able to do that

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if obligation.predicate.skip_binder().self_ty().is_ty_var() {

_: Trait is always ambiguous, and similarly treating fresh vars here is also fine here, since we'll only get those from freshening ty vars.

Copy link
Member

@eddyb eddyb Apr 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to call a method on a ty infer var but that caused errors in typeck about not being able to do that

Yeah, that's what I ran into as well, when trying to reproduce it w/o floats.

AFAIK you can't get it to pick a trait based on method name alone, without something like Default::default().method() or <_>::method but those give up too early because of how ambiguous they are, only int/float inference vars go farther (because they represent an unresolved choice in a small finite set of types etc.).

The fuzzier ideas I've had would involve guiding inference, but _: FnPtr will never succeed early enough to taint inference, and blocking inference would likely require associated types etc. - and the moment you pin down a trait, FnPtr can only affect it through a blanket impl of your choice, which would also apply to all the existing types too (before FnPtr was added).

EDIT: @compiler-errors' reply while I was playing around with more ideas for potential triggers, kind of invalidates all of those silly ideas, so yeah don't mind me, heh.

}
}
Expand Down
12 changes: 6 additions & 6 deletions compiler/rustc_trait_selection/src/traits/select/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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,
}

Expand Down
10 changes: 10 additions & 0 deletions tests/ui/fn/fn-ptr-trait-int-float-infer-var.rs
Original file line number Diff line number Diff line change
@@ -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();
}