Stream: t-compiler/rust-analyzer

Topic: Assigning IDs to things

matklad (Apr 26 2021 at 15:32, on Zulip):

@Florian Diebold @Jonas Schievink [he/him] lets spit this off into a separate topic

matklad (Apr 26 2021 at 15:33, on Zulip):

It seems that, overall, we arrived at this scheme for ids more or less universally:

type id = (id of enclosing thing, position in the parent)

matklad (Apr 26 2021 at 15:47, on Zulip):

One annoying exception here is AstId and bdfs. I wonder if we can get rid of those? It seems like they perhaps belong to ItemTree level?

matklad (Apr 26 2021 at 15:48, on Zulip):

That is, insterad of AstId (which is a position in syntax) we can use position in the item tree.

matklad (Apr 26 2021 at 15:50, on Zulip):

Another annoying exception is HirFileId. It's root variant, HirFileId::FileId is sadly ambigious -- the same file might be included twice in the crate graph. I sort-of wish that HirFileId uniquely identified the source file (and a (HirFileId, SyntaxNode) pair uniquely identified a syntax node).

Florian Diebold (Apr 26 2021 at 15:56, on Zulip):

I agree, did we ever try making HirFileId::FileId contain the crate?

matklad (Apr 26 2021 at 15:58, on Zulip):


matklad (Apr 26 2021 at 15:58, on Zulip):

Crate won't be enough -- I think it needs to be a Module

Florian Diebold (Apr 26 2021 at 15:59, on Zulip):


Jonas Schievink [he/him] (Apr 26 2021 at 16:03, on Zulip):

ah, because of #[path]

matklad (Apr 26 2021 at 16:05, on Zulip):

Hm, I guess that's complicated. There are really two uses for HirFileId

matklad (Apr 26 2021 at 16:05, on Zulip):

I think the first one has to have the shape it has today.

The second one though feels like it should made unambigious

Florian Diebold (Apr 26 2021 at 16:09, on Zulip):


Last update: Jul 24 2021 at 20:45UTC