coverage: Dismantle map_data.rs by moving its responsibilities elsewhere

[Zalathar]

This is a series of incremental changes that combine to let us get rid of coverageinfo/map_data.rs, by moving all of its responsibilities into more appropriate places.

Some of the notable consequences are:

• We once again build the per-CGU file table on the fly while preparing individual covfun records, instead of building the whole table up-front. The up-front approach was introduced by coverage: Emit the filenames section before encoding per-function mappings #117042 to work around various other problems in generating the covmap/covfun records, but subsequent cleanups have made that approach no longer necessary.
• Expression conversion and mapping-region conversion are now performed directly in mapgen::covfun, which should make future changes easier.
• We no longer insert unused function instances into the same map that is also used to track used function instances. This helps to decouple the handling of used vs unused functions.

---

There should be no meaningful change to compiler output. The file table is no longer sorted, because reordering it would invalidate the file indices stored in individual covfun records, but the table order should still be deterministic (albeit arbitrary).

There are some subsequent cleanups that I intend to investigate, but this is enough change for one PR.

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Zalathar]

One of the big enablers for this was #134029, which made map_data no longer responsible for identifying unused counter/expression IDs.

[jieyouxu]

r? jieyouxu

[Zalathar]

I don't remember exactly why I reversed the order in the first place, but I think it had something to do with wanting to change the relative order of some other bits of code that happened to be intertwined with the construction of the file table.

Those intertwinings have been dissolved by other changes, so now there's no particular reason to avoid the more “natural” ordering of steps.

[Zalathar]

I noticed that IndexSet::insert_full exists, which does precisely what I want when interacting with the global file table (diff).

[jieyouxu]

@Zalathar could you elaborate on

The file table is no longer sorted, because reordering it would invalidate the file indices stored in individual covfun records, but the table order should still be deterministic (albeit arbitrary).

So what is the deterministic order?

[jieyouxu]

Thanks, this LGTM overall, I just have some nits.

And also would be very cool if you could include a brief comment on the table order.

[Zalathar]

Addressed review feedback (diff).

[Zalathar]

My argument for the global file table being deterministic relies on MIR traversal during codegen (within a single CGU) also being deterministic.

I believe that's the case, but I've created a Zulip thread to see if anyone disagrees.

[jieyouxu]

Thanks. All other changes LGTM, just waiting on confirmation if we can rely on the traversal order (or whatever order) to be deterministic.

r=me if that is indeed the case -- that we can rely on the traversal order being guaranteed deterministic, unless it only happens to currently be that way, but is subject to changes.

[Zalathar]

OK, even though I'm confident that the traversal order is deterministic, I ended up adding a layer of sorting (by symbol name) so that changes to stable-hashing won't influence the order of the global file table, which can be observed by coverage test snapshots (diff).

(Redacting this detail in the tests themselves would be annoying, because it's embedded in the bytes of each individual covfun record.)

[Zalathar]

@rustbot ready

[jieyouxu]

Thanks, the changes LGTM.

[jieyouxu]

@bors r+

[bors]

📌 Commit 541d4e8 has been approved by jieyouxu

It is now in the queue for this repository.

[marxin]

@Zalathar
Can you please address the following rustc-dev-guide orphan links:

error: Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/map_data/struct.FunctionCoverage.html
    ┌─ llvm-coverage-instrumentation.md:199:56
    │
199 │   expression ID is passed through to the corresponding [`FunctionCoverage`]
    │                                                        ^^^^^^^^^^^^^^^^^^^^ Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/map_data/struct.FunctionCoverage.html

error: Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.add_unused_functions.html
    ┌─ llvm-coverage-instrumentation.md:287:1
    │
287 │ [`add_unused_functions()`][add-unused-functions]:
    │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/coverageinfo/mapgen/fn.add_unused_functions.html

error: Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.TraverseCoverageGraphWithLoops.html
    ┌─ llvm-coverage-instrumentation.md:447:1
    │
447 │ [`TraverseCoverageGraphWithLoops`][traverse-coverage-graph-with-loops]
    │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/coverage/graph/struct.TraverseCoverageGraphWithLoops.html

error: Server returned 404 Not Found for https://doc.rust-lang.org/nightly/nightly-rustc/rustc_interface/queries/struct.Query.html