about summary refs log tree commit diff
path: root/compiler/rustc_mir/src/transform
AgeCommit message (Collapse)AuthorLines
2021-07-29Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str, r=oli-obkbors-0/+5
Make const panic!("..") work in Rust 2021. During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now. r? `@RalfJung`
2021-07-29Rollup merge of #87527 - LeSeulArtichaut:no-mir-unsafeck, r=oli-obkYuki Okushi-4/+6
Don't run MIR unsafeck at all when using `-Zthir-unsafeck` I don't know how I missed this :D r? ``@oli-obk``
2021-07-28Improve comments about const panic handlingMara Bos-0/+3
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-07-28Make const panic!("..") work in Rust 2021.Mara Bos-0/+2
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead. panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
2021-07-27Don't run MIR unsafeck at all when using `-Zthir-unsafeck`LeSeulArtichaut-4/+6
2021-07-27Stabilize `const_fn_union`Jacob Pratt-28/+1
2021-07-27Stabilize `const_fn_transmute`Jacob Pratt-32/+0
2021-07-26Auto merge of #87424 - RalfJung:const-check, r=oli-obkbors-8/+8
rename const checking visitor module to check_consts::check This avoids naming ambiguities with "const validation" which is in `interpret/validity.rs` and checks *values*. r? `@oli-obk`
2021-07-25Auto merge of #85646 - Moxinilian:separate-const-switch, r=cjgillotbors-0/+345
MIR opt: separate constant predecessors of a switch For each block S ending with a switch, this pass copies S for each of S's predecessors that seem to assign the value being switched over as a const. This is done using a somewhat simple heuristic to determine what seems to be a const transitively. More precisely, this is what the pass does: - find a block that ends in a switch - track if there is an unique place set before the current basic block that determines the result of the switch (this is the part that resolves switching over discriminants) - if there is, iterate over the parents that have a reasonable terminator and find if the found determining place is likely to be (transitively) set from a const within that parent block - if so, add the corresponding edge to a vector of edges to duplicate - once this is done, iterate over the found edges: copy the target block and replace the reference to the target block in the origin block with the new block This pass is not optimal and could probably duplicate in more cases, but the intention was mostly to address cases like in #85133 or #85365, to avoid creating new enums that get destroyed immediately afterwards (notably making the new try v2 `?` desugar zero-cost). A benefit of this pass working the way it does is that it is easy to ensure its correctness: the worst that can happen is for it to needlessly copy a basic block, which is likely to be destroyed by cleanup passes afterwards. The complex parts where aliasing matters are only heuristics and the hard work is left to further passes like ConstProp. # LLVM blocker Unfortunately, I believe it would be unwise to enable this optimization by default for now. Indeed, currently switch lowering passes like SimplifyCFG in LLVM lose the information on the set of possible variant values, which means it tends to actually generate worse code with this optimization enabled. A fix would have to be done in LLVM itself. This is something I also want to look into. I have opened [a bug report at the LLVM bug tracker](https://bugs.llvm.org/show_bug.cgi?id=50455). When this is done, I hope we can enable this pass by default. It should be fairly fast and I think it is beneficial in many cases. Notably, it should be a sound alternative to simplify-arm-identity. By the way, ConstProp only seems to pick up the optimization in functions that are not generic. This is however most likely an issue in ConstProp that I will look into afterwards. This is my first contribution to rustc, and I would like to thank everyone on the Zulip mir-opt chat for the help and support, and especially `@scottmcm` for the guidance.
2021-07-25clippy::useless_formatMatthias Krüger-5/+5
2021-07-25clippy:: append_instead_of_extendMatthias Krüger-2/+2
2021-07-25use vec![] macro to create Vector with first item inside instead of pushing ↵Matthias Krüger-2/+2
to an empty vec![] slightly reduces code bloat
2021-07-24rename Validator → CheckerRalf Jung-6/+6
2021-07-24rename const checking visitor module to check_consts::checkRalf Jung-3/+3
2021-07-19Iterate through impls only when permittedDeadbeef-8/+11
2021-07-17Auto merge of #87123 - RalfJung:miri-provenance-overhaul, r=oli-obkbors-17/+10
CTFE/Miri engine Pointer type overhaul This fixes the long-standing problem that we are using `Scalar` as a type to represent pointers that might be integer values (since they point to a ZST). The main problem is that with int-to-ptr casts, there are multiple ways to represent the same pointer as a `Scalar` and it is unclear if "normalization" (i.e., the cast) already happened or not. This leads to ugly methods like `force_mplace_ptr` and `force_op_ptr`. Another problem this solves is that in Miri, it would make a lot more sense to have the `Pointer::offset` field represent the full absolute address (instead of being relative to the `AllocId`). This means we can do ptr-to-int casts without access to any machine state, and it means that the overflow checks on pointer arithmetic are (finally!) accurate. To solve this, the `Pointer` type is made entirely parametric over the provenance, so that we can use `Pointer<AllocId>` inside `Scalar` but use `Pointer<Option<AllocId>>` when accessing memory (where `None` represents the case that we could not figure out an `AllocId`; in that case the `offset` is an absolute address). Moreover, the `Provenance` trait determines if a pointer with a given provenance can be cast to an integer by simply dropping the provenance. I hope this can be read commit-by-commit, but the first commit does the bulk of the work. It introduces some FIXMEs that are resolved later. Fixes https://github.com/rust-lang/miri/issues/841 Miri PR: https://github.com/rust-lang/miri/pull/1851 r? `@oli-obk`
2021-07-16get rid of incorrect erase_for_fmtRalf Jung-2/+2
2021-07-15adjustions and cleanup to make Miri build againRalf Jung-1/+1
2021-07-14consistently treat None-tagged pointers as ints; get rid of some deprecated ↵Ralf Jung-5/+4
Scalar methods
2021-07-14CTFE/Miri engine Pointer type overhaul: make Scalar-to-Pointer conversion ↵Ralf Jung-11/+5
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-07-13Auto merge of #87044 - cjgillot:expnhash, r=petrochenkovbors-1/+2
Cache expansion hash globally ... instead of computing it multiple times. Split from #86676 r? `@petrochenkov`
2021-07-13Cache expansion hash.Camille GILLOT-1/+2
2021-07-13Auto merge of #86857 - fee1-dead:add-attr, r=oli-obkbors-2/+28
Add #[default_method_body_is_const] `@rustbot` label F-const_trait_impl
2021-07-10rustc_span: Revert addition of `proc_macro` field to `ExpnKind::Macro`Vadim Petrochenkov-5/+2
The flag has a vague meaning and is used for a single diagnostic change that is low benefit and appears only under `-Z macro_backtrace`.
2021-07-11Rollup merge of #87028 - aDotInTheVoid:patch-1, r=petrochenkovYuki Okushi-1/+1
Fix type: `'satic` -> `'static` Pointed out on discord: https://discord.com/channels/273534239310479360/490356824420122645/863434443170250793 ~~The fact that this compiles is probably a bug.~~ Nope it's `#![feature(in_band_lifetimes)]` (Thanks to [floppy](https://discord.com/channels/273534239310479360/490356824420122645/863437381671059486) ~~[The docs](https://doc.rust-lang.org/stable/nightly-rustc/rustc_mir/transform/inline/struct.Inliner.html#method.check_codegen_attributes) seem to indicate rust thinks this function is generic over the lifetime `'satic`~~ This is because of `in_band_lifetimes`
2021-07-10Fix typo: `satic` -> `static`Nixon Enraght-Moony-1/+1
2021-07-10Permit calls to default const fns of impl constDeadbeef-7/+25
2021-07-10Skip check for calling functions in same traitDeadbeef-3/+11
2021-07-10remove const_raw_ptr_to_usize_cast featureRalf Jung-40/+16
2021-07-08Rework SESSION_GLOBALS API to prevent overwriting itGuillaume Gomez-2/+2
2021-07-06Store macro parent module in ExpnData.Camille GILLOT-1/+1
2021-07-04Combine individual limit queries into single `limits` queryAaron Hill-1/+1
2021-07-04Query-ify global limit attribute handlingAaron Hill-3/+15
2021-07-04Auto merge of #86255 - Smittyvb:mir-alloc-oom, r=RalfJung,oli-obkbors-1/+6
Support allocation failures when interpreting MIR This closes #79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue. Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs. Note that this breaks Miri because it assumes that allocation can never fail.
2021-07-03add note about MAX_ALLOC_LIMITSmittyvb-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-07-02Allocation failure in constprop panics right awaySmitty-0/+1
2021-07-03Remove `ty::Binder::bind()`Yuki Okushi-6/+1
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
2021-06-30Delay ICE on evaluation failSmitty-68/+15
2021-06-30Properly evaluate non-consts in const propSmitty-8/+51
2021-06-30Simplify memory failure checkingSmitty-17/+16
2021-06-30Rename is_spurious -> is_volatileSmitty-2/+2
2021-06-29Properly handle const prop failuresSmitty-0/+13
2021-06-29Simplify const_prop logicSmitty-11/+9
2021-06-29Support allocation failures when interperting MIRSmitty-7/+11
Note that this breaks Miri. Closes #79601
2021-06-25Auto merge of #85603 - ogoffart:fix-uninhabited-enum-branching-pass, ↵bors-7/+5
r=wesleywiser Fix uninhabited enum branching pass when the discriminant is taken with some projection.
2021-06-22implemented separate_const_switch MIR optThéo Degioanni-0/+345
un-update itertools improve predecessor amount short-circuiting cleanup and comments somewhat improved drawing
2021-06-22Rollup merge of #86517 - camsteffen:unused-unsafe-async, r=LeSeulArtichautYuki Okushi-0/+1
Fix `unused_unsafe` around `await` Enables `unused_unsafe` lint for `unsafe { future.await }`. The existing test for this is `unsafe { println!() }`, so I assume that `println!` used to contain compiler-generated unsafe but this is no longer true, and so the existing test is broken. I replaced the test with `unsafe { ...await }`. I believe `await` is currently the only instance of compiler-generated unsafe. Reverts some parts of #85421, but the issue predates that PR.
2021-06-21Fix unused_unsafe with compiler-generated unsafeCameron Steffen-0/+1
2021-06-21Auto merge of #86383 - shamatar:slice_len_lowering, r=bjorn3bors-0/+102
Add MIR pass to lower call to `core::slice::len` into `Len` operand During some larger experiment with range analysis I've found that code like `let l = slice.len()` produces different MIR then one found in bound checks. This optimization pass replaces terminators that are calls to `core::slice::len` with just a MIR operand and Goto terminator. It uses some heuristics to remove the outer borrow that is made to call `core::slice::len`, but I assume it can be eliminated, just didn't find how. Would like to express my gratitude to `@oli-obk` who helped me a lot on Zullip
2021-06-20Squashed implementation of the passAlex Vlasov-0/+102
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 22:15:48 +0000