missing_const_for_fn: consider constness of instance
#14759
Conversation
rustbot
added
the
S-waiting-on-review
| if let ty::FnDef(fn_def_id, fn_substs) = *fn_ty.kind() { | ||
| let fn_def_id = match Instance::try_resolve(cx.tcx, cx.typing_env(), fn_def_id, fn_substs) { | ||
| Ok(Some(fn_inst)) => fn_inst.def_id(), | ||
| Ok(None) => return Err((span, format!("cannot resolve instance for {func:?}").into())), |
There was a problem hiding this comment.
Not being able to resolve to an instance doesn't mean the function can't be const. Not sure what the syntax is but there should be some way to constrain the type to implement the trait as a const trait.
There was a problem hiding this comment.
I don't see how to do that.
I think this is still better to get false negatives rather than false positives, especially when none of the tested cases fails because of this change. There were also no lintcheck misses.
There was a problem hiding this comment.
I think the current form of const traits is recentish so I wouldn't expect many uses. Can you just add a comment about this doesn't handle where predicates?
There was a problem hiding this comment.
I think the current form of const traits is recentish so I wouldn't expect many uses. Can you just add a comment about this doesn't handle where predicates?
I don't understand how where predicates could be used, and where in this situation, so I have a hard time understanding where to put this comment and what to put in it.
There was a problem hiding this comment.
@Jarcho Any suggestion on the comment to add? I'm still confused about what you meant here.
There was a problem hiding this comment.
If the syntax for it hasn't changed it's T: ~const Trait.
There was a problem hiding this comment.
Comment added, a false negative example added as well.
When determining when a function or method can be called from a `const` context, the determination must be made on the instance, not on the declaration. This makes a difference, for example, with `const_trait` traits whose implementations may or may not be `const`.
samueltardieu
force-pushed
the
issue-14658
branch
from
62311c7 to
43b7d87
Compare
When determining when a function or method can be called from a
constcontext, the determination must be made on the instance, not on the declaration. This makes a difference, for example, withconst_traittraits whose implementations may or may not beconst.changelog: [
missing_const_for_fn]: when checking if a function or method can be called from aconstcontext, look at the concrete implementation rather than at the trait definitionFixes #14658
r? @Jarcho