@Florian Diebold @Jonas Schievink [he/him] lets spit this off into a separate topic
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)
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?
That is, insterad of AstId (which is a position in syntax) we can use position in the item tree.
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).
I agree, did we ever try making
HirFileId::FileId contain the crate?
Crate won't be enough -- I think it needs to be a Module
ah, because of
Hm, I guess that's complicated. There are really two uses for HirFileId
I think the first one has to have the shape it has today.
The second one though feels like it should made unambigious