You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rollup merge of rust-lang#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 commit comments