Actually @Esteban Küber let's discuss here =)
In particular, @Esteban Küber, I think the data that is being stored in
node_method_def_id table is also available from the
we currently call
which then invokes
write_resolution which stores
method.def_idinto that table
I'll leave comments on the PR, anyhow
If that is the case, it should be easy to change
And it's great that then we won't have any extra perf/mem-use hit
What about the function
not sure what you mean by that, @Esteban Küber ?
That one is a bit hackier than I'd like, because at that point we no longer have the PathSegment anymore
you mean inspecting the snippet?
Yeah I'm not sure what's better there
Rigth now I'm imagining this could still give false suggestions
It looks like you are testing that there are generic parameters
but I think that may not be enough
I guess that it's probably true that one of the parameters needs to be constrained
even if the connection to the return type might not be direct
so perhaps it is correct as is
I believe the common case will be only one of the available type params needs to be constrained, as the rest are being properly inferred. There are three follow up things to do for that PR to be perfect: look at the current resolved type for all type params, do that even when the turbofish is being used already, and finally try to perform some global evaluation to try to infer what the appropriate type would be. I am not handling any of those cases yet under the assumption that 1) the common case will only involve a single type param (suspect assumption), 2) that this will have the most benefit for newcomers that do not yet know about the turbofish syntax, 3) that doing those things will be hard and 4) landing a smaller improvement sooner is better than a full solution later.
@nikomatsakis I feel that https://github.com/rust-lang/rust/pull/65951 is as ready as it will be in the short term for merging. The outstanding comments seem like something I should tackle but wouldn't want them to block the landing of the PR.