Move rustc_hir::def_id to rustc_span::def_id

[Aaron1011]

This will allow HygieneData to refer to DefId and DefIndex, which
will enable proper serialization of Span hygiene information.

This also reduces the number of things imported from rustc_hir, which
might make it easier to remove dependencies on it.

[Aaron1011]

This will break most tools - I'll submit follow-up PRs if this PR is merged.

[petrochenkov]

This is pretty radical.

As I mentioned on discord, I'd prefer to have a proof-of-concept implementation of metadata encoding/decoding (using tables for translating between DefIds and ExpnIds) before making infrastructural changes like using DefId in ExpnId directly.

The proof-of-concept implementation can move def_id.rs to rustc_span if it turns out more convenient than the tables, but still reexport DefId from rustc_hir to avoid extensive changes until we are sure they are necessary.

[bors]

☔ The latest upstream changes (presumably #68133) made this pull request unmergeable. Please resolve the merge conflicts.

[Aaron1011]

As I mentioned on discord, I'd prefer to have a proof-of-concept implementation of metadata encoding/decoding (using tables for translating between DefIds and ExpnIds) before making infrastructural changes like using DefId in ExpnId directly.

Wouldn't this effectively require importing the HygieneData of every dependency in our own HygieneData? If we want to convert a DefId into an ExpnId during deserialization, we need to import the corresponding ExpnData into our own HygieneData table, since an ExpnId has no concept of a 'source crate'.

This will result in each crate in the graph having a progressively larger HygieneData, with the last crate compiled having a HygieneData containing every single ExpnData every deserialized.

We could try to maintain a notion of 'local ExpnData' vs 'foreign ExpnData', and avoid re-serializing the ExpnData when it could be deserialized from an upstream crate. However, this seems much more complicated than just making ExpnIds proper 'def items', which could re-use the existing cstore_impl logic to handle data from other crates.

[petrochenkov]

This will result in each crate in the graph having a progressively larger HygieneData, with the last crate compiled having a HygieneData containing every single ExpnData every deserialized.

Exactly.
That's ok and expected, that's how we build the first version that 1) is as simple as possible and can be built quickly, 2) is functionally correct, and 3) works and can be tested.
Then we write tests checking that cross-crate hygiene 2.0 works as expected and we actually got what we wanted.
After that we can start measuring the concrete numbers and perhaps thinking about optimizations.
That's my line of though at least.

[petrochenkov]

@Aaron1011
Could you limit this PR to only moving the def_id.rs file and keeping a pub use in its previous place?

[Aaron1011]

@petrochenkov: I ended up needing to make this change in #68941, so this PR may no longer be necessary.

[petrochenkov]

@Aaron1011
I'm in process of reviewing #68941 and if moving def_id.rs is indeed a pre-requisite for it, then I'd prefer to land it here as a separate PR because it's mechanical and will make reviewing #68941 easier.

[Aaron1011]

@petrochenkov: Updated

[petrochenkov]

r=me with commits squashed.

[Aaron1011]

@petrochenkov: Squashed

[petrochenkov]

@bors r+

[bors]

📌 Commit 619051e has been approved by petrochenkov