8e21bd0633
LLVM IR coverage encoding aligns closer to Clang's I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this. r? @tmandry
This directory currently contains some LLVM support code. This will generally be sent upstream to LLVM in time; for now it lives here. NOTE: the LLVM C++ ABI is subject to between-version breakage and must *never* be exposed to Rust. To allow for easy auditing of that, all Rust-exposed types must be typedef-ed as "LLVMXyz", or "LLVMRustXyz" if they were defined here. Functions that return a failure status and leave the error in the LLVM last error should return an LLVMRustResult rather than an int or anything to avoid confusion. When translating enums, add a single `Other` variant as the first one to allow for new variants to be added. It should abort when used as an input. All other types must not be typedef-ed as such.