Stream: t-compiler/rust-analyzer

Topic: ItemScope types vs PerNsGlobImports


kev (Jan 01 2021 at 18:45, on Zulip):

Hi,

I was wondering what the PerNSGlobImports is used for?

An example I had was the following:

mod foo {
   use bar::*;
}

mod bar {
 use std::*;
 fn hello() {}
}

In the code there are two glob imports, so my original idea was that each module/container would get a PerNsGlobImport struct to populate. This is wrong however, since there is only one PerNsGlobImport on the DefCollector.

kev (Jan 01 2021 at 18:47, on Zulip):

I also noticed that PerNsGlobImport does interact with the ItemScope here, whereby which also has it's own namespace for types, values and macros: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_def/src/item_scope.rs#L203

The above method seems to check each of the types, value, namespaces in the ItemScope and then dependending on whether the import type is Named/Glob it will remove or insert into the Glob Imports

kev (Jan 01 2021 at 18:51, on Zulip):

Hmm I guess the part where the dots are not connected for me, is the purpose for PerNSGlobImports and why there seems to be only one per DefCollector/Crate

Florian Diebold (Jan 01 2021 at 19:10, on Zulip):

PerNsGlobImports just keeps track of which names in each module come from a glob import, so that they can be properly shadowed by named imports. You're right that there's just one per crate, but note that each of the sets in PerNsGlobImports contains module/name combinations

Florian Diebold (Jan 01 2021 at 19:11, on Zulip):

it could be one set of names per module, but it's just more efficient (probably) to have one big set of module/name pairs

kev (Jan 01 2021 at 19:17, on Zulip):

Florian Diebold said:

it could be one set of names per module, but it's just more efficient (probably) to have one big set of module/name pairs

Oh I see that makes sense. Thank you very much

Once I've done researching the function name issue. Will look into how the following is distinguished:

```rust
fn hello() {
use foo::*
}

fn world() {
use bar::*
}
Florian Diebold (Jan 01 2021 at 19:18, on Zulip):

they're not. we don't handle local imports at all yet

kev (Jan 01 2021 at 19:20, on Zulip):

Florian Diebold said:

they're not. we don't handle local imports at all yet

Oh I see, when they are implemented I guess the key would be ContainedID instead of LocalModuleID or something similar

Florian Diebold (Jan 01 2021 at 19:23, on Zulip):

maybe. local imports won't be resolved within the CrateDefMap of the surrounding crate, there'll be a separate def map for the function

kev (Jan 01 2021 at 19:26, on Zulip):

Florian Diebold said:

maybe. local imports won't be resolved within the CrateDefMap of the surrounding crate, there'll be a separate def map for the function

Oh right, this makes sense to me since local imports cannot be accessed via external crates where modules can be.

Florian Diebold (Jan 01 2021 at 19:31, on Zulip):

yes, and we don't want to look into item bodies if we don't have to. See rust-analyzer#1165 and rust-analyzer#5922 for some notes about that

kev (Jan 01 2021 at 19:37, on Zulip):

Florian Diebold said:

yes, and we don't want to look into item bodies if we don't have to. See rust-analyzer#1165 and rust-analyzer#5922 for some notes about that

Ahh right 5922 makes sense to me from what I can understand, thanks for the link

Last update: Jul 26 2021 at 13:30UTC