The exact source code text in the `SourceMap` is not tracked for incremental compilation. Accessing it and changing behaviour depending on this text is bound to cause issues with incremental compilation. Accesses to the `source_map` should therefore be audited, to remove access to such untracked information. As the main use for these is diagnostics (accessing the exact source code, adjusting a span...). As a consequence, we don't expect ICEs or miscompilations. The worse that could happen is weird diagnostics. Are fine: - accesses that happen *before* incremental compilation kicks in: parsing, macro expansion, AST passes, lowering, name resolution... - accesses that are hashed in `impl HashStable for Span`: filename, line number, column number... - accesses in rustdoc, clippy, rustfmt, as they don't use rustc's incremental compilation. Steps: 1. create a query `source_map: () -> &'tcx SourceMap`, marked `eval_always` and `no_hash`; 2. for each access to `tcx.sess.source_map()` (there are many), determine if it looks at the source code text; 2.2 if it does, see below; 2.1. if it does not: leave it as it, wrap this access in a method on `TyCtxt` in `rustc_middle::ty::context` and document why this access is fine. When an untracked access to the source code is found, there are three options, in order: - try to replace the logic with one based on information available in the HIR; - add the required information to the HIR and use it, it's meant for this sort of things; - replace `tcx.sess.source_map()` by `tcx.source_map(())`, which will force the query system to recompute everything properly. Note: there are many of such accesses. A quick grep counted ~300. We do not expect a single contributor to audit all of them at once. Do not hesitate to contact @cjgillot on zulip if necessary. <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_ASSIGN_START --> <!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mdx97"}$$TRIAGEBOT_ASSIGN_DATA_END --> <!-- TRIAGEBOT_ASSIGN_END --> <!-- TRIAGEBOT_END -->