SPIKE: Pipeline trace coverage analysis (do not merge)

[cds-amal]

This lives on a spike branch, a few features ahead of what's currently merged. We'll get to those changes in due course; I wanted to document and share what came out of this particular spike before the context fades (things fade fast these days).

What this is (and isn't)

I added pipeline trace instrumentation (gated behind TRACE=1) to the
compiler driver, which logs every event as it flows through the MIR visitor:
each call, allocation, type, and constant it encounters. The output is a
flat JSON array of TraceEvent values, one per observable step, written to
*.smir.trace.json alongside the main output. The implementation lives on
the spike/trace branch.

The point isn't to build a profiler or a debugger. It's to answer a specific
question: when I run the test suite, which visitor paths actually fire? And
(more importantly) which ones don't?

The tracer defines 11 event variants, one for each observable pipeline step:

Event	Visitor callback	What it records
ItemDiscovered	Phase 1	Mono item found via mono_collect or unevaluated const
BodyWalkStarted	Phase 2	Bookend: starting body analysis (with collection snapshot)
BodyWalkFinished	Phase 2	Bookend: finished body analysis (with collection snapshot)
FunctionCallResolved	visit_terminator	Call terminator resolved to a function instance
DropGlueResolved	visit_terminator	Drop terminator resolved to drop glue
ReifyFnPointerResolved	visit_rvalue	Rvalue::Cast(ReifyFnPointer) detected
AllocationCollected	visit_mir_const	ConstantKind::Allocated provenance walked
FnDefAsValue	visit_mir_const	ConstantKind::ZeroSized FnDef used as value
UnevaluatedConstDiscovered	visit_mir_const	ConstantKind::Unevaluated found
TypeCollected	visit_ty	Type collected by TyCollector
AssemblyStarted	Phase 3	Summary: total items, functions, allocs, types, spans

What the test suite actually exercises

I ran TRACE=1 against all 28 pre-existing integration tests and aggregated
the event counts. Here's the full picture:

Count	Event
2121	SpanResolved
775	TypeCollected
308	FnDefAsValue
307	FunctionCallResolved
296	AllocationCollected
291	ItemDiscovered
291	BodyWalkStarted
291	BodyWalkFinished
59	DropGlueResolved
28	AssemblyStarted
0	ReifyFnPointerResolved
0	UnevaluatedConstDiscovered

Two zeros. Two visitor paths that no integration test has ever exercised.

Gap 1: ReifyFnPointer casts (closed)

Path: visit_rvalue handling
Rvalue::Cast(CastKind::PointerCoercion(ReifyFnPointer))

This fires when a function item (which in Rust has a unique zero-sized type;
every function gets its own) is coerced into a fn(...) pointer. It's a
common enough pattern in real code, but none of our test programs happened
to do it.

Straightforward to close. reify-fn-pointer.rs uses an explicit type
annotation to force the cast:

let f: fn(i32, i32) -> i32 = add;

And the trace confirms we hit the path:

{
  "event": "ReifyFnPointerResolved",
  "item": "_ZN16reify_fn_pointer4main17h...E",
  "location": {
    "file": "tests/integration/programs/reify-fn-pointer.rs",
    "line": 14, "col": 34, "end_line": 14, "end_col": 37
  },
  "sym_kind": "normal",
  "sym_name": "_ZN16reify_fn_pointer3add17h...E"
}

Line 14, columns 34-37: that's the add on the right-hand side of the
assignment, exactly where the coercion happens.

Gap 2: unevaluated constants (open)

Path: visit_mir_const handling ConstantKind::Unevaluated

This is trickier. The handler would fire when the compiler leaves a constant
unevaluated in the monomorphized MIR, i.e., it hasn't been resolved to a
concrete value by the time stable MIR sees it. Our handler resolves the
constant's DefId to a mono item and enqueues it for transitive discovery.

I wrote unevaluated-const.rs with associated constants in generic contexts
(S::STEP via trait impls) and const generic parameters
(make_array::<4>()), hoping to produce an unevaluated constant at the MIR
level. On the pinned nightly (2024-11-29), the compiler eagerly evaluates
everything during monomorphization; constants show up as Allocated or
Ty(Value(...)), never Unevaluated. The trace confirms: zero
UnevaluatedConstDiscovered events.

The test exercises const-adjacent pipeline paths and documents the gap, but
doesn't close it.

The open question

ConstantKind::Unevaluated is part of the stable MIR API; the rustc team
put it there, so it's a valid state that consumers must handle. Our handler
is correct: it resolves the constant's DefId to a mono item and enqueues it
for transitive discovery. The question isn't whether to keep it (of course we
keep it), but whether we can actually test it.

On the pinned nightly (2024-11-29), I haven't been able to produce an
Unevaluated constant in monomorphized MIR. Associated constants, const
generics, const expressions in generic contexts: the compiler eagerly
evaluates all of them during monomorphization. I don't know the rustc
internals well enough to say whether there's a specific program shape,
compiler flag, or different nightly version that would leave a constant
unevaluated at this stage. If anyone on the team knows (or knows who to
ask), I'd like to close this gap properly.

In the meantime, the trace gives us a cheap way to track this across
toolchain bumps: run TRACE=1 against the test suite, aggregate events,
check whether UnevaluatedConstDiscovered starts appearing. If a future
nightly changes the evaluation behavior, we'll see it immediately and can
write a targeted test. Until then, the handler is tested against the API
contract (it compiles, it type-checks, it does the right thing with the
ConstantKind::Unevaluated variant), but we don't have an integration test
that actually reaches it end-to-end.