Disambiguate between SourceFiles from different crates even if they have the same path This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate: 1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`. 2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`. 3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents. This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created. Another, more involved, approach might be to merge the `src` and the `external_src` field. Fixes #85955 |
||
|---|---|---|
| .. | ||
| analyze_source_file | ||
| lev_distance | ||
| source_map | ||
| symbol | ||
| analyze_source_file.rs | ||
| caching_source_map_view.rs | ||
| crate_disambiguator.rs | ||
| def_id.rs | ||
| edition.rs | ||
| fatal_error.rs | ||
| hygiene.rs | ||
| lev_distance.rs | ||
| lib.rs | ||
| source_map.rs | ||
| span_encoding.rs | ||
| symbol.rs | ||
| tests.rs | ||