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.

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));