Add codeview_annotation intrinsic

[gurry]

This PR adds a new intrinsic called codeview_annotation which lowers to llvm.codeview.annotation and allows users to emit arbitrary S_ANNOTATION records into PDB files.

Motivation

In Microsoft we are working on supporting Windows driver development in Rust. codeview_annotation is needed to implement a feature called WPP tracing which requires strings from trace statements to be written to the PDB at compile time.

Basically the user writes a trace statement like this in the driver:

trace!("Bytes {}, duration {} ms", byte_count, elapsed_ms);

which expands to a call to codeview_annotation:

codeview_annotation!("Bytes {}, duration {} ms", "some other metadata");

and the string arguments get written to the PDB.

Later at runtime trace viewing tools extract those strings from the PDB, combine them with the stream of variables (e.g. byte_count and elapsed_ms) coming out of the driver and produce a human readable log.

This keeps tracing efficient by avoiding costly I/O of strings at runtime and also helps with not leaking implementation details of drivers.

The intrinsic could also be useful in general for other use cases where you need to embed some user-specific information in the PDB.

API

The intrinsic is declared as:

 pub fn codeview_annotation(strings: &[&str]);

and is publicly exposed through a macro with the same name.

The &[&str] parameter is required to be a const as it must be available at compile time in order to be lowered to llvm.codeview.annotation. Non-const arguments are rejected with a compiler error.

Supported Platforms

Only LLVM on msvc is supported. It is a no-op on other platforms.

Implementation

Calls to codeview_annotation are lowered to StatementKind::Intrinsic at MIR building time. The string arguments are extracted from THIR and stored in the newly introduced variant NonDivergingIntrinsic::CodeviewAnnotation(Box<[Symbol]>) which is ultimately lowered to llvm.codeview.annotation in the backend.

We have chosen to collect the string arguments at the time of THIR->MIR translation because it is easier to do so. The other option was to do it during codegen but that would have required walking chains of MIR locals backwards which was more complicated.

Future Work

Ideally we should have implemented this feature using const generics e.g.:

pub fn codeview_annotation<const STRINGS: &[&str]>();

as that guarantees the compile time availability of the inputs. However, we are blocked on adt_const_params and especially unsized_const_params. Whenever these features get stabilized we can update the implementation to make use of them.

[wesleywiser]

In broad strokes, this looks reasonable to me.

My main question is in the second review comment regarding feature scope. The PR description seems a bit out of date in that a lot more than just string literals is supported and I think that is adding a lot of complexity to the implementation. If that isn't actually necessary (and if it is, why?), I think it would be better to simplify the feature to just string literals.

[wesleywiser]

Oh, I forgot to mention, I think you also need to adjust the MIR inliner to mirror the LLVM behavior of the annotation blocking inlining.

[gurry]

Oh, I forgot to mention, I think you also need to adjust the MIR inliner to mirror the LLVM behavior of the annotation blocking inlining.

Sure, I will take a look.