about summary refs log tree commit diff
path: root/src/test/mir-opt
AgeCommit message (Collapse)AuthorLines
2021-10-06opt-level >= 4Alexander-1/+1
2021-10-06run remaining testsAlexander-9/+17
2021-10-06tidyAlexander-1/+1
2021-10-06add MIR artifactsAlexander-3/+626
2021-10-06reset and cleanupAlexander-0/+50
2021-10-04Stabilize `const_panic`Jacob Pratt-3/+2
2021-09-30Auto merge of #89110 - Aaron1011:adjustment-span, r=estebankbors-76/+76
Use larger span for adjustment THIR expressions Currently, we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef, autoborrow, unsizing). As a result, if a borrow generated by an adustment ends up causing a borrowcheck error, for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`), rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation, this doesn't always get exposed in migration mode, but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions. These spans are recoded when we first create the adjustment during typecheck. For example, an autoref adjustment triggered by a method call will record the span of the entire method call. The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example, in a method call) that produdes a borrowcheck error. For example, an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`), when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases, this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result, several `.nll.stderr` files end up getting removed entirely.
2021-09-25Use larger span for adjustments on method callsAaron Hill-76/+76
Currently, we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef, autoborrow, unsizing). As a result, if a borrow generated by an adustment ends up causing a borrowcheck error, for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`), rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation, this doesn't always get exposed in migration mode, but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example, in a method call) that produdes a borrowcheck error. For example, an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`), when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases, this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result, several `.nll.stderr` files end up getting removed entirely.
2021-09-25Bless testsGary Guo-210/+339
2021-09-18./x.py test --blessTomasz Miąsko-65/+75
2021-09-12Auto merge of #88839 - nbdd0121:alignof, r=nagisabors-151/+180
Introduce NullOp::AlignOf This PR introduces `Rvalue::NullaryOp(NullOp::AlignOf, ty)`, which will be lowered from `align_of`, similar to `size_of` lowering to `Rvalue::NullaryOp(NullOp::SizeOf, ty)`. The changes are originally part of #88700 but since it's not dependent on other changes and could have performance impact on its own, it's separated into its own PR.
2021-09-13Add mir opt test for min_align_of -> AlignOf loweringGary Guo-151/+180
2021-09-11Auto merge of #88214 - notriddle:notriddle/for-loop-span-drop-temps-mut, ↵bors-1/+1
r=nagisa rustc: use more correct span data in for loop desugaring Fixes #82462 Before: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | for x in DroppingSlice(&*v).iter(); { | + After: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | }; | + This seems like a reasonable fix: since the desugared "expr_drop_temps_mut" contains the entire desugared loop construct, its span should contain the entire loop construct as well.
2021-09-05Change scope of temporaries in match guardsMatthew Jasper-19/+20
Each pattern in a match arm has its own copy of the match guard in MIR, with its own temporary, so it has to be dropped before the the guards are joined to the single copy of the arm.
2021-09-03Update coverage testsMatthew Jasper-1/+1
2021-09-02Bless 32bit MIR opt testsMatthew Jasper-93/+68
2021-09-01Fix drop handling for `if let` expressionsMatthew Jasper-333/+309
MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables.
2021-08-28rustc: use more correct span data in for loop desugaringMichael Howell-1/+1
Before: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | for x in DroppingSlice(&*v).iter(); { | + After: help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped | LL | }; | + This seems like a reasonable fix: since the desugared "expr_drop_temps_mut" contains the entire desugared loop construct, its span should contain the entire loop construct as well.
2021-08-27Auto merge of #88371 - Manishearth:rollup-pkkjsme, r=Manishearthbors-405/+405
Rollup of 11 pull requests Successful merges: - #87832 (Fix debugger stepping behavior with `match` expressions) - #88123 (Make spans for tuple patterns in E0023 more precise) - #88215 (Reland #83738: "rustdoc: Don't load all extern crates unconditionally") - #88216 (Don't stabilize creation of TryReserveError instances) - #88270 (Handle type ascription type ops in NLL HRTB diagnostics) - #88289 (Fixes for LLVM change 0f45c16f2caa7c035e5c3edd40af9e0d51ad6ba7) - #88320 (type_implements_trait consider obligation failure on overflow) - #88332 (Add argument types tait tests) - #88340 (Add `c_size_t` and `c_ssize_t` to `std::os::raw`.) - #88346 (Revert "Add type of a let tait test impl trait straight in let") - #88348 (Add field types tait tests) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-08-26update mir diffslcnr-23/+23
2021-08-25Fix debugger stepping behavior around `match` expressionsWesley Wiser-405/+405
Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-08-22Fix typos “an”→“a” and a few different ones that appeared in the ↵Frank Steffahn-1/+1
same search
2021-08-19Revert "Revert "Auto merge of #83417 - erikdesjardins:enableremovezsts, ↵Erik Desjardins-40/+16
r=oli-obk"" This reverts commit 8e11199a153218c13a419df37a9bb675181cccb7.
2021-08-15Revert "Auto merge of #83417 - erikdesjardins:enableremovezsts, r=oli-obk"Erik Desjardins-16/+40
This reverts commit 8007b506ac5da629f223b755f5a5391edd5f6d01, reversing changes made to e55c13e1099b78b1a485202fabc9c1b10b1f1d15.
2021-08-15Introduce hir::ExprKind::Let - Take 2Caio-111/+131
2021-08-07Run RemoveZsts at mir-opt-level=1Erik Desjardins-40/+16
Effectively reverts commit 6960bc9696b05b15d8d89ece2fef14e6e62a43fc.
2021-08-03Make simplify_cfg test more consistentAlex Crichton-47/+50
Force it to always use panic=abort which means that all targets should produce the same MIR now.
2021-07-27Update testsJacob Pratt-42/+40
2021-07-25Auto merge of #85646 - Moxinilian:separate-const-switch, r=cjgillotbors-0/+710
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-14bless mir-opt, codegen, and remaining ui testsRalf Jung-134/+134
2021-07-06Revert "Revert "Update mir opt tests""bjorn3-24/+24
This reverts commit 8d5fb5bf7d5c63dcfaea381e00ded67c21fab3a3.
2021-06-25Auto merge of #85603 - ogoffart:fix-uninhabited-enum-branching-pass, ↵bors-0/+300
r=wesleywiser Fix uninhabited enum branching pass when the discriminant is taken with some projection.
2021-06-23Updated mir pretty print outputDeadbeef-33/+0
2021-06-22implemented separate_const_switch MIR optThéo Degioanni-0/+710
un-update itertools improve predecessor amount short-circuiting cleanup and comments somewhat improved drawing
2021-06-20Squashed implementation of the passAlex Vlasov-0/+77
2021-06-12Pretty print generator witness only in `-Zverbose` modeTomasz Miąsko-13/+13
In release build of deeply-nested-async benchmark the size of `no-opt.bc` file is reduced from 46MB to 62kB.
2021-06-12Rollup merge of #86153 - tmiasko:dummy-span, r=estebankYuki Okushi-8/+8
Print dummy spans as `no-location` Fixes #58808.
2021-06-09Auto merge of #86107 - Smittyvb:peephole-optim-eq-bool, r=wesleywiserbors-0/+166
Peephole optimize `x == false` and `x != true` This adds peephole optimizations to make `x == false`, `false == x`, `x != true`, and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.
2021-06-09Print dummy spans as `no-location`Tomasz Miąsko-8/+8
2021-06-07Peephole optimize `x == false` and `x != true`Smitty-0/+166
2021-06-07Revert "Update mir opt tests"bjorn3-24/+24
This reverts commit e0e0cfa6492292d0b905b07a4ed727f4e1aefc80.
2021-05-30Update mir opt testsbjorn3-24/+24
2021-05-26Bless test outputJacob Pratt-9/+16
2021-05-23unhinabited_enum_branching: Fix the pass when the enum is taken indirectlyOlivier Goffart-62/+14
If there is a projection on the place of the discriminent, the pass wouldn't trigger
2021-05-23Test for unihnabitded_enum_branching pass using reference to fieldsOlivier Goffart-0/+348
2021-05-18Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnrbors-344/+330
Implement the new desugaring from `try_trait_v2` ~~Currently blocked on https://github.com/rust-lang/rust/issues/84782, which has a PR in https://github.com/rust-lang/rust/pull/84811~~ Rebased atop that fix. `try_trait_v2` tracking issue: https://github.com/rust-lang/rust/issues/84277 Unfortunately this is already touching a ton of things, so if you have suggestions for good ways to split it up, I'd be happy to hear them. (The combination between the use in the library, the compiler changes, the corresponding diagnostic differences, even MIR tests mean that I don't really have a great plan for it other than trying to have decently-readable commits. r? `@ghost` ~~(This probably shouldn't go in during the last week before the fork anyway.)~~ Fork happened.
2021-05-18No matter how trivial the change, tidy always finds a way to complain...Scott McMurray-4/+4
2021-05-18Mention the issue number for the new mir-opt in the FIXMEs scottmcm-2/+2
Thanks for the suggestions, lcnr! Co-authored-by: lcnr <rust@lcnr.de>
2021-05-17mir-opt bless for Size field being removed from AllocationRalf Jung-44/+44
2021-05-09PR feedbackScott McMurray-8/+8