Hrm... so apparently, you can define a module with the same name as a primitive, and types will still resolve to that primitive: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7a99a7ce7b6629098b5c2512cb4737c3
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
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 ;)
I think this worked correctly before rust-analyzer#1352... shouldn't be too hard to fix though
although... since you can apparently shadow primitives with structs, that may make it more complicated :/
hm, what does
str::len even mean if you have a
perhaps shadowing is working, but some other missing bit (like
pub) in nares accidently exports shadowed name?
this basically makes no sense: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=19456b91117b936d251da0925c3b687b
wait, it's even worse than that: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0117a00d98189990a2bd6efaa561f369
I'm scared to look up in rustc how this works
I guess, I'll be spelling
<str> from now on :-)
still, it might be better to err on the side of preferring the primitive instead of the module...
that's true, yeah. Basically, we should stick the primiteves map in front, and comment-out the shadowing test
hm, not, I fear we need to handles this at least somewhat properly: std has str and i32 modules
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
I think if you just move primites in front, the no longer will be resolved by a full nam
submitted https://github.com/dtolnay/rust-quiz/pull/20/files :D
haha, that's pretty weird. i'm surprised it's able to find
is_empty! (i guess in
is_empty is just calls
<s as str>::len() so it uses the actual type of s not the mod)
Sigh, this is a backward compatibility thing.
See the comment in https://github.com/rust-lang/rust/pull/32131/files for how the fallback to primitive types work.
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.