Stream: t-compiler/wg-rls-2.0

Topic: assoc_items


Jeremy Kolb (Mar 01 2019 at 19:24, on Zulip):

When I see something like

path segment "new" resolved to non-module Struct(Struct { id: StructId(0) }), but is not last

What does the but is not last refer to?

Jeremy Kolb (Mar 01 2019 at 19:34, on Zulip):

during resolution

Florian Diebold (Mar 01 2019 at 19:41, on Zulip):

I think there's an off-by-one in that log message ;) so you have e.g. Foo::new(), and it's saying that Foo resolved to some struct, not a module, so it's stopping the resolution at that point (if this happens for an import, it's an error, but in an expression we can continue resolving it during type inference)

Jeremy Kolb (Mar 01 2019 at 19:44, on Zulip):

I was wondering that too

Jeremy Kolb (Mar 01 2019 at 19:45, on Zulip):

I'm basically trying to resolve Foo::new()

Jeremy Kolb (Mar 01 2019 at 19:45, on Zulip):

well figure out why it doesn't resolve

Florian Diebold (Mar 01 2019 at 20:03, on Zulip):

It's handled during type inference, like method calls. We just don't handle it for goto def. Probably, we need another side table during type inference where we write resolutions of associated items, and then use that for goto def (I wrote a bit about that here: https://github.com/rust-analyzer/rust-analyzer/issues/832#issuecomment-463751288 )

Jeremy Kolb (Mar 01 2019 at 20:15, on Zulip):

So we need a side table for type inference or one for goto def?

Florian Diebold (Mar 01 2019 at 21:00, on Zulip):

A side table for type inference to write information that goto def can then use ;)

Florian Diebold (Mar 01 2019 at 21:00, on Zulip):

(and by side table I really just mean a hash map, like the ones for method and field resolutions)

Jeremy Kolb (Mar 01 2019 at 21:06, on Zulip):

Yep. I have one going from ExprId to Function but infer_expr doesn't seem to get called

Jeremy Kolb (Mar 01 2019 at 21:07, on Zulip):

Maybe we need to use inference if name_ref.syntax().parent().and_then(ast::PathSegment::cast)

Jeremy Kolb (Mar 01 2019 at 21:08, on Zulip):

in goto def

Florian Diebold (Mar 01 2019 at 21:25, on Zulip):

reference_definition calls type inference if it sees a method or field access, it should probably do the same if it can't resolve a path

Jeremy Kolb (Mar 01 2019 at 21:27, on Zulip):

Ok i'll try it if name resolution fails

Jeremy Kolb (Mar 01 2019 at 21:33, on Zulip):

so infer_expr doesn't really know anything about the "receiver" since this is a call expr and not really a method right?

Jeremy Kolb (Mar 01 2019 at 21:44, on Zulip):

@Florian Diebold I'm assuming that I write to the hash table in infer_expr if we're looking at Expr:Call. How do I get the Function I need? I think I need to find an ImplBlock::Method?

Florian Diebold (Mar 01 2019 at 21:44, on Zulip):

I think you write to the hash table when you're looking at the Expr::Path already

Florian Diebold (Mar 01 2019 at 21:45, on Zulip):

it might be an associated constant as well, it doesn't really matter if it's called or what else is done with it afterwards

Florian Diebold (Mar 01 2019 at 21:47, on Zulip):

so basically at the end of infer_path_expr, you may have a Resolution::Def(some_module_def), and then you can save that

Florian Diebold (Mar 01 2019 at 21:47, on Zulip):

by the way, I just notice that we basically convert the ImplItem::Method into a ModuleDef::Function there, which feels... weird

Florian Diebold (Mar 01 2019 at 21:48, on Zulip):

but I guess if you just interpret ModuleDef as 'things that could be in a module' as opposed to 'things that are in a module', it's fine

Jeremy Kolb (Mar 01 2019 at 21:53, on Zulip):

Should I be saving the path instead of the expr? I guess this is more of a path to associated thing map

Jeremy Kolb (Mar 01 2019 at 21:53, on Zulip):

sorry: would it make more sense that the path is the key

Florian Diebold (Mar 01 2019 at 21:56, on Zulip):

I think in some weird edge cases the same paths might resolve to different items even in the same function...

Florian Diebold (Mar 01 2019 at 21:56, on Zulip):

on the other hand, we ideally want all the intermediate resolutions as well

Florian Diebold (Mar 01 2019 at 21:57, on Zulip):

still, it should be keyed on the expression I think

Jeremy Kolb (Mar 01 2019 at 21:57, on Zulip):

well the issue is that the expression is not acccessible from that point

Jeremy Kolb (Mar 01 2019 at 21:58, on Zulip):

and the other caller infer_pat doesn't have one passed in either

Florian Diebold (Mar 01 2019 at 21:58, on Zulip):

oh, I think it should be fine to just pass the ExprId to infer_path_expr

Florian Diebold (Mar 01 2019 at 21:59, on Zulip):

oh, it's called by pattern inference as well, right...

Jeremy Kolb (Mar 01 2019 at 21:59, on Zulip):

yeah

Florian Diebold (Mar 01 2019 at 22:00, on Zulip):

we do want to save the resolution in the pattern case as well

Florian Diebold (Mar 01 2019 at 22:02, on Zulip):

we might return the resolved item as well as the type... or pass a callback to infer_path_expr that writes the resolution to the right place... or pass some enum wrapping ExprId or PatId... not sure what the nicest approach is

Jeremy Kolb (Mar 01 2019 at 22:49, on Zulip):

@Florian Diebold I chose the latter for now

Jeremy Kolb (Mar 01 2019 at 23:21, on Zulip):

think i have something that works for associated functions

Jeremy Kolb (Mar 01 2019 at 23:37, on Zulip):

PR is up

Jeremy Kolb (Mar 06 2019 at 13:22, on Zulip):

@Florian Diebold we don't currently do anything with that PatId. should we right now?

Florian Diebold (Mar 06 2019 at 13:25, on Zulip):

I guess if you use an associated constant in a pattern, we should?

matklad (Mar 06 2019 at 13:28, on Zulip):

Are associated constants even allowed in patterns? How would you check pattern disjointess?

Florian Diebold (Mar 06 2019 at 13:41, on Zulip):

inherent associated constants don't have that problem @matklad https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9881a070f75f0458cdb51f1513f2a2dc

Jeremy Kolb (Mar 06 2019 at 13:45, on Zulip):

looks like that answers the question

Florian Diebold (Mar 06 2019 at 14:07, on Zulip):

associated consts of a trait do indeed not work in patterns

matklad (Mar 06 2019 at 14:08, on Zulip):

Hm, they do work? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8e3658e31e3c73457a827151b59527b9

Florian Diebold (Mar 06 2019 at 14:22, on Zulip):

Yeah if the self type is known, I meant something like this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1f70f60dbd38fce55af7159795fca16b

Jeremy Kolb (Mar 06 2019 at 15:04, on Zulip):

So in the match we're actually in a PathPat not a Pat. I can't seem to get the PatId from the PathPat

Jeremy Kolb (Mar 06 2019 at 16:41, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/pull/942

Jeremy Kolb (Mar 06 2019 at 16:46, on Zulip):

It will also give information on associated functions but I think that should be correct even if the compiler rejects it

matklad (Mar 06 2019 at 17:13, on Zulip):

@Jeremy Kolb there's From<PathPat> for Pat` impl

Jeremy Kolb (Mar 06 2019 at 19:30, on Zulip):

That's on the ast side. I don't think it helps

Florian Diebold (Mar 06 2019 at 19:33, on Zulip):

the PathPat you have there is an ast::PathPat, right? you can turn that into an ast::Pat and get the PatId from the body source map (pretty much like it's done in the expr case)

Jeremy Kolb (Mar 06 2019 at 19:34, on Zulip):

ah right. i missed that

Jeremy Kolb (Mar 06 2019 at 19:41, on Zulip):

much better

Last update: Nov 12 2019 at 17:05UTC