| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Trim and tidy includes in `rustc_llvm`
These includes tend to accumulate over time, and are usually only removed when something breaks in a new LLVM version, so it's nice to clean them up manually once in a while.
General strategy used for this PR:
- Remove all includes from `LLVMWrapper.h` that aren't needed by the header itself, transplanting them to individual source files as necessary.
- For each source file, temporarily remove each include if doing so doesn't cause a compile error.
- If a “required” include looks like it shouldn't be needed, try replacing it with its sub-includes, then trim that list.
- After doing all of the above, go back and re-add any removed include if the file does actually use things defined in that header, even if the header happens to also be included by something else.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Manually run `clang-format` on `CoverageMappingWrapper.cpp`
In the current version of #123409, there are several unrelated changes to `CoverageMappingWrapper.cpp` that seem to be the result of running `clang-format` on that file.
Instead of asking for those changes to be undone, I figure it's easier to just make them myself as a separate PR, since I was vaguely intending to do that at some point anyway.
In a few cases I've strategically added comments to make the grouping of parameters a little nicer, but mostly it doesn't matter much.
|
|
|
|
|
|
C++ style guides I am aware of recommend specifically preferring = syntax
for any classes with fairly obvious constructors[^0] that do not perform
any complicated logic in their constructor. I contend that all constructors
that the `rustc_llvm` code uses qualify. This has only become more common
since C++ 17 guaranteed many cases of copy initialization elision.
The other detail is that I tried to ask another contributor with
infinitely more C++ experience than me (i.e. any) what this constructor
syntax was, and they thought it was a macro. I know of no other language
that has adopted this same syntax. As the rustc codebase features many
contributors experienced in many other languages, using a less...
unique... style has many other benefits in making this code more
lucid and maintainable, which is something it direly needs.
[^0]: e.g. https://abseil.io/tips/88
|
|
|
|
Adapt for https://github.com/llvm/llvm-project/commit/8ecbb0404d740d1ab173554e47cef39cd5e3ef8c.
|
|
|
|
|
|
Coverage has two FFI functions for computing the hash of a byte string. One
takes a ptr/len pair, and the other takes a NUL-terminated C string.
But on closer inspection, the C string version is unnecessary. The calling-side
code converts a Rust `&str` into a C string, and the C++ code then immediately
turns it back into a ptr/len string before actually hashing it.
|
|
The Rust-side declaration uses `libc::size_t` for the number of bytes, but the
C++ declaration was using `unsigned` instead of `size_t`.
|
|
The regions don't need to be mutable because we pass a copy of them to LLVM
instead, and this matches the `*const` in the Rust-side signature.
|
|
|
|
LLVM upstream has deprecated llvm::makeArrayRef and will remove it.
|
|
|
|
Version 5 adds Branch Regions which are a prerequisite for branch coverage.
Version 6 can use the zeroth filename as prefix for other relative files.
|
|
|
|
|
|
LLVM change 5fbd1a333aa1a0b70903d036b98ea56c51ae5224 modified this
function to want std::string instead of StringRef, which is easily done.
|
|
The definition of this struct changes in LLVM 12 due to the addition
of branch coverage support. To avoid future mismatches, declare our
own struct and then convert between them.
|
|
|
|
* `rustc` should now compile under LLVM 9 or 10
* Compiler generates an error if `-Z instrument-coverage` is specified
but LLVM version is less than 11
* Coverage tests that require `-Z instrument-coverage` and run codegen
should be skipped if LLVM version is less than 11
|
|
Changes the coverage map injected into binaries compiled with
`-Zinstrument-coverage` to LLVM Coverage Mapping Format, Version 4 (from
Version 3). Note, binaries compiled with this version will require LLVM
tools from at least LLVM Version 11.
|
|
|
