diff options
| author | Nicholas Nethercote <n.nethercote@gmail.com> | 2024-02-06 17:40:11 +1100 |
|---|---|---|
| committer | Nicholas Nethercote <n.nethercote@gmail.com> | 2024-02-07 18:57:38 +1100 |
| commit | e55df623ead33023fe6c4488064e5d5e4e141b9e (patch) | |
| tree | 5cee40236a7632490850fa30ef0dec0a49e90eb8 /compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp | |
| parent | 8d1c20a539b72abdbe1ede872f19e0a1a6f34be4 (diff) | |
| download | rust-e55df623ead33023fe6c4488064e5d5e4e141b9e.tar.gz rust-e55df623ead33023fe6c4488064e5d5e4e141b9e.zip | |
Remove an `unchecked_claim_error_was_emitted` call.
When `catch_fatal_errors` catches a `FatalErrorMarker`, it returns an `ErrorGuaranteed` that is conjured out of thin air with `unchecked_claim_error_was_emitted`. But that `ErrorGuaranteed` is never used. This commit changes it to instead conjure a `FatalError` out of thin air. (A non-deprecated action!) This makes more sense because `FatalError` and `FatalErrorMarker` are a natural pairing -- a `FatalErrorMarker` is created by calling `FatalError::raise`, so this is effectively getting back the original `FatalError`. This requires a tiny change in `catch_with_exit_code`. The old result of the `catch_fatal_errors` call there was `Result<Result<(), ErrorGuaranteed>, ErrorGuaranteed>` which could be `flatten`ed into `Result<(), ErrorGuaranteed>`. The new result of the `catch_fatal_errors` calls is `Result<Result<(), ErrorGuaranteed>, FatalError>`, which can't be `flatten`ed but is still easily matched for the success case.
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
