Rollup merge of #68941 - Aaron1011:fix/imported-span, r=petrochenkov

Properly handle Spans that reference imported SourceFiles

Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. This currently has no visible consequences, since these
kinds of spans don't currently seem to be emitted anywhere. However,
there's no reason that we couldn't start using such spans in
diagnostics.

This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:

* 'Local' spans, which reference non-imported SourceFiles, are encoded
  exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
  with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.

To support this change, I've also made the following modifications:

* `DefId` and related structs are now moved to `rustc_span`. This allows
  us to use a `CrateNum` inside `SourceFile`. `CrateNum` has special
handling during deserialization (it gets remapped to be the proper
`CrateNum` from the point of view of the current compilation session),
so using a `CrateNum` instead of a plain integer 'workaround type' helps
to simplify deserialization.
* The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.

0 files changed, 0 insertions, 0 deletions