about summary refs log tree commit diff
path: root/compiler/rustc_mir/src/interpret/terminator.rs
AgeCommit message (Collapse)AuthorLines
2021-09-07Rename rustc_mir to rustc_const_eval.Camille GILLOT-517/+0
2021-09-02rustc_target: move `LayoutOf` to `ty::layout`.Eduard-Mihai Burtescu-2/+2
2021-08-30rustc_target: `TyAndLayout::field` should never error.Eduard-Mihai Burtescu-1/+1
2021-08-04Auto merge of #86155 - alexcrichton:abort-on-unwind, r=nikomatsakisbors-7/+2
rustc: Fill out remaining parts of C-unwind ABI 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.
2021-08-03rustc: Fill out remaining parts of C-unwind ABIAlex Crichton-7/+2
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.
2021-08-03don't use .into() to convert types to identical types ↵Matthias Krüger-1/+1
(clippy::useless_conversion) Example: let _x: String = String::from("hello world").into();
2021-07-14CTFE/Miri engine Pointer type overhaul: make Scalar-to-Pointer conversion ↵Ralf Jung-10/+12
infallible This resolves all the problems we had around "normalizing" the representation of a Scalar in case it carries a Pointer value: we can just use Pointer if we want to have a value taht we are sure is already normalized.
2021-06-27Change miri to use tcx allocated allocations.Charles Lew-2/+2
2021-05-26Use `match` instead of `.map_or(StackPopUnwind::Skip, StackPopUnwind::Cleanup)`hyd-dev-5/+8
2021-05-25Add a commenthyd-dev-0/+1
2021-05-25`can_unwind` -> `caller_can_unwind`hyd-dev-2/+2
2021-05-23:facepalm:hyd-dev-1/+1
2021-05-23Pass `StackPopUnwind` to `eval_fn_call()` and some other functions that are ↵hyd-dev-16/+20
called by `eval_fn_call()`
2021-05-23`Cleanup(Option<_>)` -> `Cleanup(BasicBlock), Skip`hyd-dev-4/+4
2021-05-23Don't evaluate `self.fn_can_unwind(...)` if `can_unwind` is already truehyd-dev-3/+4
2021-05-23Move the callee "can unwind" check to the right placehyd-dev-26/+35
2021-05-23const-eval: disallow unwinding across functions that `!fn_can_unwind()`hyd-dev-6/+31
2021-05-21Add `rustc_mir::interpret::Machine::enforce_abi()`hyd-dev-19/+21
2021-05-17Add a comment for `check_abi()`hyd-dev-0/+3
2021-05-09Check the ABI of `body.source`hyd-dev-11/+15
2021-03-09rustc_target: add "unwind" payloads to `Abi`katelyn a. martin-3/+3
### Overview This commit begins the implementation work for RFC 2945. For more information, see the rendered RFC [1] and tracking issue [2]. A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`, and `Thiscall` variants, marking whether unwinding across FFI boundaries is acceptable. The cases where each of these variants' `unwind` member is true correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings introduced in RFC 2945 [3]. ### Feature Gate and Unstable Book This commit adds a `c_unwind` feature gate for the new ABI strings. Tests for this feature gate are included in `src/test/ui/c-unwind/`, which ensure that this feature gate works correctly for each of the new ABIs. A new language features entry in the unstable book is added as well. ### Further Work To Be Done This commit does not proceed to implement the new unwinding ABIs, and is intentionally scoped specifically to *defining* the ABIs and their feature flag. ### One Note on Test Churn This will lead to some test churn, in re-blessing hash tests, as the deleted comment in `src/librustc_target/spec/abi.rs` mentioned, because we can no longer guarantee the ordering of the `Abi` variants. While this is a downside, this decision was made bearing in mind that RFC 2945 states the following, in the "Other `unwind` Strings" section [3]: > More unwind variants of existing ABI strings may be introduced, > with the same semantics, without an additional RFC. Adding a new variant for each of these cases, rather than specifying a payload for a given ABI, would quickly become untenable, and make working with the `Abi` enum prone to mistakes. This approach encodes the unwinding information *into* a given ABI, to account for the future possibility of other `-unwind` ABI strings. ### Ignore Directives `ignore-*` directives are used in two of our `*-unwind` ABI test cases. Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases ignore architectures that do not support `stdcall` and `thiscall`, respectively. These directives are cribbed from `src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and `src/test/ui/extern/extern-thiscall.rs` for `thiscall`. This would otherwise fail on some targets, see: https://github.com/rust-lang-ci/rust/commit/fcf697f90206e9c87b39d494f94ab35d976bfc60 ### Footnotes [1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md [2]: https://github.com/rust-lang/rust/issues/74990 [3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
2021-02-16./x.py fmtTomasz Miąsko-1/+1
2021-02-16Pass MPlaceTy by reference not valueTomasz Miąsko-1/+1
2021-02-16Pass PlaceTy by reference not valueTomasz Miąsko-9/+13
2021-02-16Pass OpTy by reference not valueTomasz Miąsko-8/+8
2021-01-10Add ABI argument to `find_mir_or_eval_fn`Nym Seddon-5/+6
Add ABI argument for called function in `find_mir_or_eval_fn` and `call_extra_fn`. Useful for comparing with expected ABI in interpreters. Related to [miri/1631](https://github.com/rust-lang/miri/issues/1631)
2020-12-06Fix comments related to abort()Albin Hedman-1/+1
2020-12-05abort() now takes a msg parameterAlbin Hedman-1/+1
2020-10-10Refactor how SwitchInt stores jump targetsJonas Schievink-5/+5
2020-09-25Rollup merge of #76973 - lzutao:unstably-const-assume, r=oli-obkJonas Schievink-2/+2
Unstably allow assume intrinsic in const contexts Not sure much about this usage because there are concerns about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic in inline functions. But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221, here we are. [1]: https://github.com/rust-lang/rust/pull/54995#issuecomment-429302709 [2]: https://github.com/rust-lang/rust/issues/49572#issuecomment-589615423
2020-09-21fix InterpCx resolveBastian Kauschke-1/+6
2020-09-20Correct file path after some restructures in compilerLzu Tao-2/+2
2020-09-04Change ty.kind to a methodLeSeulArtichaut-3/+3
2020-08-30mv compiler to compiler/mark-0/+458
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 10:13:40 +0000