Rollup merge of #77992 - nagisa:thaw-coverage-instrumentation, r=wesleywiser

instrument-coverage: try our best to not ICE instrument-coverage was ICEing for me on some code, in particular code that had devirtualized paths from standard library. Instrument coverage probably has no bussiness dictating which paths are valid and which aren't so just feed it everything and whatever and let tooling deal with other stuff. For example, with this commit we can generate coverage hitpoints for these interesting paths: * `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore * `/home/.../src/library/core/lib.rs` – devirtualized version of above * `<inline asm>`, `<anon>` and many similar synthetic paths Even if those paths somehow get to the instrumentation pass, I'd much rather get hits for these weird paths and hope some of them work (as would be the case for devirtualized path to libcore), rather than have compilation fail entirely.

Author: JohnTitor

compiler/rustc_mir/src/transform/instrument_coverage.rs

@@ -22,9 +22,7 @@ use rustc_middle::ty::query::Providers;
 use rustc_middle::ty::TyCtxt;
 use rustc_span::def_id::DefId;
 use rustc_span::source_map::original_sp;
-use rustc_span::{
- BytePos, CharPos, FileName, Pos, RealFileName, SourceFile, Span, Symbol, SyntaxContext,
-};
+use rustc_span::{BytePos, CharPos, Pos, SourceFile, Span, Symbol, SyntaxContext};
 
 use std::cmp::Ordering;
 
@@ -549,13 +547,7 @@ impl<'a, 'tcx> Instrumentor<'a, 'tcx> {
  let mir_body = &self.mir_body;
  let body_span = self.body_span();
  let source_file = source_map.lookup_source_file(body_span.lo());
- let file_name = match &source_file.name {
- FileName::Real(RealFileName::Named(path)) => Symbol::intern(&path.to_string_lossy()),
- _ => bug!(
- "source_file.name should be a RealFileName, but it was: {:?}",
- source_file.name
- ),
- };
+ let file_name = Symbol::intern(&source_file.name.to_string());
 
  debug!("instrumenting {:?}, span: {}", def_id, source_map.span_to_string(body_span));