about summary refs log tree commit diff
path: root/src/test/run-make-fulldeps/coverage/abort.rs
AgeCommit message (Collapse)AuthorLines
2022-07-28Move coverage tests from run-make-fulldeps to run-makeTomasz Miąsko-66/+0
2021-08-04Fix assertions in `coverage-reports` testAlex Crichton-7/+2
Update some `C-unwind` bits and then
2021-08-03rustc: Fill out remaining parts of C-unwind ABIAlex Crichton-5/+9
This commit intends to fill out some of the remaining pieces of the C-unwind ABI. This has a number of other changes with it though to move this design space forward a bit. Notably contained within here is: * On `panic=unwind`, the `extern "C"` ABI is now considered as "may unwind". This fixes a longstanding soundness issue where if you `panic!()` in an `extern "C"` function defined in Rust that's actually UB because the LLVM representation for the function has the `nounwind` attribute, but then you unwind. * Whether or not a function unwinds now mainly considers the ABI of the function instead of first checking the panic strategy. This fixes a miscompile of `extern "C-unwind"` with `panic=abort` because that ABI can still unwind. * The aborting stub for non-unwinding ABIs with `panic=unwind` has been reimplemented. Previously this was done as a small tweak during MIR generation, but this has been moved to a separate and dedicated MIR pass. This new pass will, for appropriate functions and function calls, insert a `cleanup` landing pad for any function call that may unwind within a function that is itself not allowed to unwind. Note that this subtly changes some behavior from before where previously on an unwind which was caught-to-abort it would run active destructors in the function, and now it simply immediately aborts the process. * The `#[unwind]` attribute has been removed and all users in tests and such are now using `C-unwind` and `#![feature(c_unwind)]`. I think this is largely the last piece of the RFC to implement. Unfortunately I believe this is still not stabilizable as-is because activating the feature gate changes the behavior of the existing `extern "C"` ABI in a way that has no replacement. My thinking for how to enable this is that we add support for the `C-unwind` ABI on stable Rust first, and then after it hits stable we change the behavior of the `C` ABI. That way anyone straddling stable/beta/nightly can switch to `C-unwind` safely.
2020-12-03Combination of commitsRich Kadel-1/+34
Fixes multiple issue with counters, with simplification Includes a change to the implicit else span in ast_lowering, so coverage of the implicit else no longer spans the `then` block. Adds coverage for unused closures and async function bodies. Fixes: #78542 Adding unreachable regions for known MIR missing from coverage map Cleaned up PR commits, and removed link-dead-code requirement and tests Coverage no longer depends on Issue #76038 (`-C link-dead-code` is no longer needed or enforced, so MSVC can use the same tests as Linux and MacOS now) Restrict adding unreachable regions to covered files Improved the code that adds coverage for uncalled functions (with MIR but not-codegenned) to avoid generating coverage in files not already included in the files with covered functions. Resolved last known issue requiring --emit llvm-ir workaround Fixed bugs in how unreachable code spans were added.
2020-12-03Coverage tests for remaining TerminatorKinds and async, improve AssertRich Kadel-0/+34
Tested and validate results for panic unwind, panic abort, assert!() macro, TerminatorKind::Assert (for example, numeric overflow), and async/await. Implemented a previous documented idea to change Assert handling to be the same as FalseUnwind and Goto, so it doesn't get its own BasicCoverageBlock anymore. This changed a couple of coverage regions, but I validated those changes are not any worse than the prior results, and probably help assure some consistency (even if some people might disagree with how the code region is consistently computed). Fixed issue with async/await. AggregateKind::Generator needs to be handled like AggregateKind::Closure; coverage span for the outer async function should not "cover" the async body, which is actually executed in a separate "closure" MIR.