incr.comp.: Possible cross-session instability in DefPath

[michaelwoerister]

It seems problematic to me that DefPathData (the components of a DefPath) use Ident for storing their string fields because Ident contains SyntaxContext, which, if I understand it correctly, is a monotonically increasing interning key/ID. As a consequence, changing something somewhere involving a new SyntaxContext might have non-local effects, as the u32 in there possibly gets shifted for all subsequent Idents. This would be unfortunate because avoiding issues of this kind is the reason we introduced DefPath for in the first place.

My question is: Why do we even use Ident here in the first place? Wouldn't InternedString or Symbol be sufficient? DefPath already has a mechanism for disambiguating things that have the same string value (see DisambiguatedDefPathData).

cc @jseyfried and the rest of @rust-lang/compiler

[eddyb]

I am confused, I thought it's always been InternedString? Did it get changed accidentally?

[michaelwoerister]

Did it get changed accidentally?

It was introduced in 3eb235b. But I don't think it makes sense for DefPath to interact with macro hygiene. We should just change it back if nothing started to rely on having Ident in the meantime.

@jseyfried, can you tell us what the motivation for this change was (just with respect to DefPathData)?

[nikomatsakis]

I believe it should be InternedString. This should not (I think) affect hygiene.