Stream: t-compiler/rust-analyzer

Topic: shadowing primitives

Florian Diebold (Jun 14 2019 at 19:13, on Zulip):

Hrm... so apparently, you can define a module with the same name as a primitive, and types will still resolve to that primitive:
e.g. there's a str module in scope in liballoc's string module, so we don't currently resolve str correctly there in types

Florian Diebold (Jun 14 2019 at 19:13, on Zulip):

in related news, I've got dot completions through Arcs working now, but the deref implementation of String still doesn't work because of the above ;)

Florian Diebold (Jun 14 2019 at 19:17, on Zulip):

I think this worked correctly before rust-analyzer#1352... shouldn't be too hard to fix though

Florian Diebold (Jun 14 2019 at 19:20, on Zulip):

although... since you can apparently shadow primitives with structs, that may make it more complicated :/

matklad (Jun 14 2019 at 19:21, on Zulip):

hm, what does str::len even mean if you have a str module?

matklad (Jun 14 2019 at 19:22, on Zulip):

perhaps shadowing is working, but some other missing bit (like pub) in nares accidently exports shadowed name?

matklad (Jun 14 2019 at 19:24, on Zulip):

this basically makes no sense:

matklad (Jun 14 2019 at 19:26, on Zulip):

wait, it's even worse than that:

Florian Diebold (Jun 14 2019 at 19:37, on Zulip):

I'm scared to look up in rustc how this works

matklad (Jun 14 2019 at 19:38, on Zulip):

I guess, I'll be spelling str as <str> from now on :-)

Florian Diebold (Jun 14 2019 at 19:39, on Zulip):

still, it might be better to err on the side of preferring the primitive instead of the module...

matklad (Jun 14 2019 at 19:40, on Zulip):

that's true, yeah. Basically, we should stick the primiteves map in front, and comment-out the shadowing test

matklad (Jun 14 2019 at 19:41, on Zulip):

hm, not, I fear we need to handles this at least somewhat properly: std has str and i32 modules

Florian Diebold (Jun 14 2019 at 19:43, on Zulip):

I don't know how much resolving them correctly within std matters though... especially since they're not a problem if they're referred to by full name

matklad (Jun 14 2019 at 19:44, on Zulip):

I think if you just move primites in front, the no longer will be resolved by a full nam

matklad (Jun 14 2019 at 19:54, on Zulip):

submitted :D

Pascal (Jun 14 2019 at 20:06, on Zulip):

haha, that's pretty weird. i'm surprised it's able to find is_empty! (i guess in is_empty is just calls s.len() or <s as str>::len() so it uses the actual type of s not the mod)

Vadim Petrochenkov (Jun 14 2019 at 22:10, on Zulip):

Sigh, this is a backward compatibility thing.
See the comment in for how the fallback to primitive types work.

matklad (Jun 15 2019 at 12:46, on Zulip):

I like how Go (I think) dodges this issue. They basically have an #[lang = "i32"] existential type i32; somewhere in the standard library, which should guarantee the same code-path in name resolution. That is, I know they have primitives declared in the stdlib, I don't know if this is what is actually used by name resolution.

Last update: Jul 27 2021 at 21:15UTC