Stream: t-compiler/help

Topic: point at method call PR #65951


nikomatsakis (Dec 11 2019 at 21:29, on Zulip):

Actually @Esteban Küber let's discuss here =)

nikomatsakis (Dec 11 2019 at 21:34, on Zulip):

In particular, @Esteban Küber, I think the data that is being stored innode_method_def_id table is also available from the type_dependent_defs table

nikomatsakis (Dec 11 2019 at 21:35, on Zulip):

we currently call write_method_call

nikomatsakis (Dec 11 2019 at 21:35, on Zulip):

which then invokes write_resolution which stores method.def_idinto that table

nikomatsakis (Dec 11 2019 at 21:35, on Zulip):

I'll leave comments on the PR, anyhow

Esteban Küber (Dec 11 2019 at 21:38, on Zulip):

If that is the case, it should be easy to change

Esteban Küber (Dec 11 2019 at 21:38, on Zulip):

And it's great that then we won't have any extra perf/mem-use hit

Esteban Küber (Dec 11 2019 at 21:39, on Zulip):

What about the function foo()foo<T>() case?

nikomatsakis (Dec 11 2019 at 21:39, on Zulip):

not sure what you mean by that, @Esteban Küber ?

Esteban Küber (Dec 11 2019 at 21:39, on Zulip):

That one is a bit hackier than I'd like, because at that point we no longer have the PathSegment anymore

Esteban Küber (Dec 11 2019 at 21:39, on Zulip):

one sec

nikomatsakis (Dec 11 2019 at 21:39, on Zulip):

you mean inspecting the snippet?

Esteban Küber (Dec 11 2019 at 21:40, on Zulip):

https://github.com/rust-lang/rust/pull/65951/files#diff-0e12890ad498e250783f40f88a8b8ec6R1997-R2042

Esteban Küber (Dec 11 2019 at 21:40, on Zulip):

yep

nikomatsakis (Dec 11 2019 at 21:40, on Zulip):

Yeah I'm not sure what's better there

nikomatsakis (Dec 11 2019 at 21:40, on Zulip):

Rigth now I'm imagining this could still give false suggestions

nikomatsakis (Dec 11 2019 at 21:40, on Zulip):

It looks like you are testing that there are generic parameters

nikomatsakis (Dec 11 2019 at 21:41, on Zulip):

but I think that may not be enough

nikomatsakis (Dec 11 2019 at 21:43, on Zulip):

well

nikomatsakis (Dec 11 2019 at 21:44, on Zulip):

I guess that it's probably true that one of the parameters needs to be constrained

nikomatsakis (Dec 11 2019 at 21:44, on Zulip):

even if the connection to the return type might not be direct

nikomatsakis (Dec 11 2019 at 21:44, on Zulip):

so perhaps it is correct as is

Esteban Küber (Dec 12 2019 at 01:26, on Zulip):

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.

Esteban Küber (Dec 12 2019 at 23:53, on Zulip):

@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.

Last update: Sep 18 2020 at 21:00UTC