about summary refs log tree commit diff
path: root/src/librustc_mir/transform
AgeCommit message (Collapse)AuthorLines
2020-07-15update promoted_mirBastian Kauschke-8/+4
2020-07-15update const arg queriesBastian Kauschke-34/+30
2020-07-15const generics work!Bastian Kauschke-52/+137
2020-07-15continue mir pipelineBastian Kauschke-9/+16
2020-07-15optimized_mirBastian Kauschke-7/+30
2020-07-15InstanceDef::ItemBastian Kauschke-8/+8
2020-07-15ConstKind::UnevaluatedBastian Kauschke-4/+4
2020-07-11Rollup merge of #72920 - oli-obk:const_transmute, r=RalfJungManish Goregaokar-0/+15
Stabilize `transmute` in constants and statics but not const fn cc #53605 (leaving issue open so we can add `transmute` to `const fn` later) Previous attempt: #64011 r? @RalfJung cc @rust-lang/wg-const-eval
2020-07-11Stabilize `transmute` in constants and statics but not const fnOliver Scherer-0/+15
2020-07-10Rollup merge of #73862 - oli-obk:const_array_to_slice, r=RalfJungManish Goregaokar-2/+11
Stabilize casts and coercions to `&[T]` in const fn Part of #64992 There was never a reason to not stabilize this, we just accidentally prevented them when we implemented the `min_const_fn` feature that gave us `const fn` on stable. This PR stabilizes these casts (which are already stable in `const` outside `const fn`), while keeping all other unsizing casts (so `T` -> `dyn Trait`) unstable within const fn. These casts have no forward compatibility concerns with any future features for const eval and users were able to use them under the `const_fn` feature gate already since at least the miri merger, possibly longer. r? @rust-lang/lang
2020-07-09Rollup merge of #74070 - eddyb:forall-tcx-providers, r=nikomatsakisManish Goregaokar-3/+3
Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>. In order to work around normalization-under-HRTB (for `provide!` in `rustc_metadata`), we ended up with this: ```rust struct Providers<'tcx> { type_of: fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, // ... } ``` But what I initially wanted to do, IIRC, was this: ```rust struct Providers { type_of: for<'tcx> fn(TyCtxt<'tcx>, DefId) -> Ty<'tcx>, // ... } ``` This PR moves to the latter, for the simple reason that only the latter allows keeping a `Providers` value, or a subset of its `fn` pointer fields, around in a `static` or `thread_local!`, which can be really useful for custom drivers that override queries. (@jyn514 and I came across a concrete usecase of that in `rustdoc`) The `provide!` macro in `rustc_metadata` is fixed by making the query key/value types available as type aliases under `ty::query::query_{keys,values}`, not just associated types (this is the first commit). r? @nikomatsakis
2020-07-08Add `reachable` and friends to `mir::traversal` moduleDylan MacKenzie-3/+1
2020-07-06Rollup merge of #74102 - oli-obk:const_prop_icde, r=wesleywiserManish Goregaokar-19/+21
Fix const prop ICE we used to erase the local just before we tried to read it for diagnostics fixes #73993 r? @wesleywiser
2020-07-05Rollup merge of #74027 - lcnr:ConstCx-local-def-id, r=varkorManish Goregaokar-25/+21
Convert more `DefId`s to `LocalDefId`s
2020-07-05Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.Eduard-Mihai Burtescu-3/+3
2020-07-05Auto merge of #73879 - ecstatic-morse:discr-switch-uninit, r=oli-obkbors-0/+1
Handle inactive enum variants in `MaybeUninitializedPlaces` Resolves the first part of #69715. This is the equivalent of #68528 but for `MaybeUninitializedPlaces`. Because we now notify drop elaboration that inactive enum variants might be uninitialized, some drops get marked as ["open" that were previously "static"](https://github.com/rust-lang/rust/blob/e0e5d82e1677c82d209b214bbfc2cc5705c2336a/src/librustc_mir/transform/elaborate_drops.rs#L191). Unlike in #69715, this isn't strictly better: An "open" drop expands to more MIR than a simple call to the drop shim. However, because drop elaboration considers each field of an "open" drop separately, it can sometimes eliminate unnecessary drops of moved-from or unit-like enum variants. This is the case for `Option::unwrap`, which is reflected in the `mir-opt` test. cc @eddyb r? @oli-obk
2020-07-04Fix const prop ICEOliver Scherer-19/+21
we used to erase the local just before we tried to read it for diagnostics
2020-07-04nitBastian Kauschke-1/+1
Co-authored-by: varkor <github@varkor.com>
2020-07-04ConstCx to LocalDefIdBastian Kauschke-25/+21
2020-07-03Rollup merge of #73949 - wesleywiser:simplify_try_fixes, r=oli-obkManish Goregaokar-9/+106
[mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass This does not yet attempt re-enabling the pass, but it does resolve a number of issues with the pass. r? @oli-obk I believe this closes #73223.
2020-07-03Rollup merge of #73693 - wesleywiser:const_prop_exhaustive_match, r=oli-obkManish Goregaokar-1/+13
Use exhaustive match in const_prop.rs Addresses a comment left by @RalfJung on #73613 r? @RalfJung
2020-07-02Fix missing return in `optimization_applies()`Wesley Wiser-0/+1
2020-07-02Fix debuginfo so that it points to the correct localWesley Wiser-10/+59
2020-07-02[mir-opt] Prevent mis-optimization when SimplifyArmIdentity runsWesley Wiser-2/+49
If temporaries are used beyond just the temporary chain, then we can't optimize out the reads and writes.
2020-07-02Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2, r=wesleywiserManish Goregaokar-56/+80
add spans to injected coverage counters, extract with CoverageData query This is the next iteration on the Rust Coverage implementation, and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-01Rollup merge of #73778 - nbdd0121:const_likely, r=oli-obkManish Goregaokar-6/+38
Make `likely` and `unlikely` const, gated by feature `const_unlikely` This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`. cc @RalfJung @nagisa r? @oli-obk
2020-06-30Use exhaustive match in const_prop.rsWesley Wiser-1/+13
2020-06-30Handle inactive enum variants in `MaybeUninitializedPlaces`Dylan MacKenzie-0/+1
2020-06-30Stabilize casts and coercions to `&[T]` in const fnOliver Scherer-2/+11
2020-06-30update `equal_up_to_regions`Bastian Kauschke-5/+5
2020-06-29add spans to injected coverage countersRich Kadel-56/+80
added regions with counter expressions and counters. Added codegen_llvm/coverageinfo mod for upcoming coverage map Move coverage region collection to CodegenCx finalization Moved from `query coverageinfo` (renamed from `query coverage_data`), as discussed in the PR at: https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503 Address merge conflict in MIR instrument_coverage test The MIR test output format changed for int types. moved debug messages out of block.rs This makes the block.rs calls to add coverage mapping data to the CodegenCx much more concise and readable. move coverage intrinsic handling into llvm impl I realized that having half of the coverage intrinsic handling in `rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any non-llvm backend would be bound to the same decisions about how the coverage-related MIR terminators should be handled. To fix this, I moved the non-codegen portion of coverage intrinsic handling into its own trait, and implemented it in `rustc_codegen_llvm` alongside `codegen_intrinsic_call`. I also added the (required?) stubs for the new intrinsics to `IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do not fail if called with these new but known intrinsics. address PR Feedback on 28 June 2020 2:48pm PDT
2020-06-28Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match, r=oli-obkbors-94/+1
Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const`, `static`, `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally, we would resolve :whale: #66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk
2020-06-28Stop checking for `while` and `loop` in a const contextDylan MacKenzie-19/+0
2020-06-28MIR const-checkingDylan MacKenzie-33/+1
2020-06-28Remove `control_flow_destroyed` and properly lower `&&` and `||`Dylan MacKenzie-42/+0
2020-06-28Rollup merge of #73757 - oli-obk:const_prop_hardening, r=wesleywiserManish Goregaokar-11/+57
Const prop: erase all block-only locals at the end of every block I messed up this erasure in https://github.com/rust-lang/rust/pull/73656#discussion_r446040140. I think it is too fragile to have the previous scheme. Let's benchmark the new scheme and see what happens. r? @wesleywiser cc @felix91gr
2020-06-28Erase all block-only locals at the end of every block, even if they have not ↵Oliver Scherer-11/+57
been touched.
2020-06-27Rollup merge of #73708 - Aaron1011:feature/reland-move-fn-self-msg, r=davidtwcoManish Goregaokar-0/+1
Explain move errors that occur due to method calls involving `self` (take two) This is a re-attempt of #72389 (which was reverted in #73594) Instead of using `ExpnKind::Desugaring` to represent operators, this PR checks the lang item directly.
2020-06-27Rollup merge of #72796 - RalfJung:mir-assign-sanity, r=matthewjasperManish Goregaokar-12/+147
MIR sanity check: validate types on assignment This expands the MIR validation added by @jonas-schievink in https://github.com/rust-lang/rust/pull/72093 to also check that on an assignment, the types of both sides match. Cc @eddyb @oli-obk
2020-06-27Fix ICE for lib featuresGary Guo-4/+25
2020-06-26Rollup merge of #73728 - oli-obk:const_prop_cleanup, r=wesleywiserManish Goregaokar-6/+13
Document some invariants correctly/more r? @wesleywiser
2020-06-26Fix allow_internal_unstable with rustc_const_unstableGary Guo-7/+18
2020-06-26Explain move errors that occur due to method calls involving `self`Aaron Hill-0/+1
This is a re-attempt of #72389 (which was reverted in #73594) Instead of using `ExpnKind::Desugaring` to represent operators, this PR checks the lang item directly.
2020-06-26Show the values and computation that would overflow a const evaluation or ↵Oliver Scherer-30/+40
propagation
2020-06-25Document some invariants correctly/moreOliver Scherer-6/+13
2020-06-24Emit line info for generator variantsTyler Mandry-1/+21
2020-06-23Rollup merge of #73613 - oli-obk:const_prop_miscompile, r=wesleywiserManish Goregaokar-16/+38
The const propagator cannot trace references. Thus we avoid propagation of a local the moment we encounter references to it. fixes #73609 cc @RalfJung r? @wesleywiser
2020-06-23Rollup merge of #73488 - richkadel:llvm-coverage-map-gen, r=tmandryManish Goregaokar-56/+158
code coverage foundation for hash and num_counters This PR is the next iteration after PR #73011 (which is still waiting on bors to merge). @wesleywiser - PTAL r? @tmandry (FYI, I'm also working on injecting the coverage maps, in another branch, while waiting for these to merge.) Thanks!
2020-06-23Rollup merge of #73244 - ecstatic-morse:validate-generator-mir, r=tmandryManish Goregaokar-56/+213
Check for assignments between non-conflicting generator saved locals This is to prevent future changes to the generator transform from reintroducing the problem that caused #73137. Namely, a store between two generator saved locals whose storage does not conflict. My ultimate goal is to introduce a modified version of #71956 that handles this case properly. r? @tmandry
2020-06-23The const propagator cannot trace references.Oliver Scherer-16/+38
Thus we avoid propagation of a local the moment we encounter references to it.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 17:03:35 +0000