about summary refs log tree commit diff
path: root/compiler/rustc_mir_transform/src
AgeCommit message (Collapse)AuthorLines
2023-10-02subtyping_projectionsouz-a-0/+59
2023-10-01Remove outdated comment.Camille GILLOT-2/+0
2023-10-01Rename lint pass.Camille GILLOT-7/+7
2023-10-01Do not check for impossible predicates in const-prop lint.Camille GILLOT-37/+0
2023-10-01Use DefKind to check for generator.Camille GILLOT-4/+4
2023-09-29Auto merge of #115759 - oli-obk:open_drop_from_non-ADT, r=lcnrbors-10/+25
Reveal opaque types before drop elaboration fixes https://github.com/rust-lang/rust/issues/113594 r? `@cjgillot` cc `@JakobDegen` This pass was introduced in https://github.com/rust-lang/rust/pull/110714 I moved it before drop elaboration (which only cares about the hidden types of things, not the opaque TAIT or RPIT type) and set it to run unconditionally (instead of depending on the optimization level and whether the inliner is active)
2023-09-28Only visit reachable nodes in SsaLocals.Camille GILLOT-8/+4
2023-09-28Skip reinterning if nothing changedOli Scherer-0/+4
2023-09-28Strip `OpaqueCast` during `RevealAll`.Oli Scherer-0/+19
2023-09-28Remove unnecessary generator-check, which also fixes the issue within async ↵Oli Scherer-5/+0
functions
2023-09-28Unconditionally run `RevealAll` pass and run it earlierOli Scherer-5/+1
2023-09-28Some tracing cleanupsOli Scherer-0/+1
2023-09-28Rollup merge of #116211 - matthiaskrgr:clippy3, r=compiler-errorsMatthias Krüger-6/+3
more clippy complextity fixes redundant_guards, useless_format, clone_on_copy
2023-09-27fix clippy::{redundant_guards, useless_format}Matthias Krüger-6/+3
2023-09-27Auto merge of #109597 - cjgillot:gvn, r=oli-obkbors-2/+578
Implement a global value numbering MIR optimization The aim of this pass is to avoid repeated computations by reusing past assignments. It is based on an analysis of SSA locals, in order to perform a restricted form of common subexpression elimination. By opportunity, this pass allows for some simplifications by combining assignments. For instance, this pass could be able to see through projections of aggregates to directly reuse the aggregate field (not in this PR). We handle references by assigning a different "provenance" index to each `Ref`/`AddressOf` rvalue. This ensure that we do not spuriously merge borrows that should not be merged. Meanwhile, we consider all the derefs of an immutable reference to a freeze type to give the same value: ```rust _a = *_b // _b is &Freeze _c = *_b // replaced by _c = _a ```
2023-09-27Auto merge of #116166 - Zalathar:unreachable, r=cjgillotbors-1/+5
Skip MIR pass `UnreachablePropagation` when coverage is enabled When coverage instrumentation and MIR opts are both enabled, coverage relies on two assumptions: - MIR opts that would delete `StatementKind::Coverage` statements instead move them into bb0 and change them to `CoverageKind::Unreachable`. - MIR opts won't delete all `CoverageKind::Counter` statements from an instrumented function. Most MIR opts naturally satisfy the second assumption, because they won't remove coverage statements from bb0, but `UnreachablePropagation` can do so if it finds that bb0 is unreachable. If this happens, LLVM thinks the function isn't instrumented, and it vanishes from coverage reports. A proper solution won't be possible until after per-function coverage info lands in #116046, but for now we can avoid the problem by turning off this particular pass when coverage instrumentation is enabled. --- cc `@cjgillot` since I found this while investigating coverage problems encountered by #113970 `@rustbot` label +A-code-coverage +A-mir-opt
2023-09-26Auto merge of #116144 - lcnr:subst-less, r=oli-obkbors-10/+13
subst -> instantiate continues #110793, there are still quite a few uses of `subst` and `substitute`, but changing them all in the same PR was a bit too much, so I've stopped here for now.
2023-09-26Explicit simplify_place.Camille GILLOT-8/+19
2023-09-26const-eval: make misalignment a hard errorRalf Jung-32/+6
2023-09-26Skip MIR pass `UnreachablePropagation` when coverage is enabledZalathar-1/+5
When coverage instrumentation and MIR opts are both enabled, coverage relies on two assumptions: - MIR opts that would delete `StatementKind::Coverage` statements instead move them into bb0 and change them to `CoverageKind::Unreachable`. - MIR opts won't delete all `CoverageKind::Counter` statements from an instrumented function. Most MIR opts naturally satisfy the second assumption, because they won't remove coverage statements from bb0, but `UnreachablePropagation` can do so if it finds that bb0 is unreachable. If this happens, LLVM thinks the function isn't instrumented, and it vanishes from coverage reports. A proper solution won't be possible until after per-function coverage info lands in #116046, but for now we can avoid the problem by turning off this particular pass when coverage instrumentation is enabled.
2023-09-26subst -> instantiatelcnr-10/+13
2023-09-25Use Vec::retain in remove_dead_blocks.Camille GILLOT-19/+24
2023-09-24Do not clone valtree and slice constants.Camille GILLOT-0/+31
2023-09-24Embed simplification into VnState.Camille GILLOT-77/+112
2023-09-24Workaround issue 112651.Camille GILLOT-1/+5
2023-09-24Add a paragraph about the assume bitwise equal.Camille GILLOT-0/+25
2023-09-24Do not check copiability.Camille GILLOT-12/+7
2023-09-24Add documentation.Camille GILLOT-1/+43
2023-09-24Add global value numbering pass.Camille GILLOT-2/+435
2023-09-23Enable drop_tracking_mir by default.Camille GILLOT-93/+18
2023-09-23Do not construct def_path_str for MustNotSuspend.Camille GILLOT-8/+29
2023-09-21Auto merge of #116010 - RalfJung:more-typed-immediates, r=oli-obkbors-11/+19
interpret: more consistently use ImmTy in operators and casts The diff in src/tools/miri/src/shims/x86/sse2.rs should hopefully suffice to explain why this is nicer. :)
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-90/+84
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
2023-09-21Prevent promotion of const fn calls in inline constsOli Scherer-1/+1
2023-09-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-89/+83
2023-09-21try to avoid some layout_of callsRalf Jung-2/+8
2023-09-20interpret: more consistently use ImmTy in operators and castsRalf Jung-9/+11
2023-09-20coverage: Remove vestigial counter/expression debug labelsZalathar-22/+5
2023-09-20coverage: Remove vestigial `format_counter` methodsZalathar-40/+20
2023-09-20coverage: Remove debug code from the instrumentorZalathar-986/+16
2023-09-20the Const::eval_bits methods don't need to be given the TyRalf Jung-3/+3
2023-09-19move ConstValue into mirRalf Jung-6/+5
this way we have mir::ConstValue and ty::ValTree as reasonably parallel
2023-09-19Rollup merge of #115930 - Zalathar:spans-bug, r=compiler-errorsMatthias Krüger-31/+17
coverage: Fix an unstable-sort inconsistency in coverage spans This code was calling `sort_unstable_by`, but failed to impose a total order on the initial spans. That resulted in unpredictable handling of closure spans, producing inconsistencies in the coverage maps and in user-visible coverage reports. This PR fixes the problem by always sorting closure spans before otherwise-identical non-closure spans, and also switches to a stable sort in case the ordering is still not total. --- In addition to the fix itself, this PR also contains a cleanup to the comparison function that I was working on when I discovered the bug.
2023-09-18coverage: Simplify sorting of coverage spans extracted from MIRZalathar-33/+16
Switching to `Ordering::then_with` makes control-flow less complicated, and there is no need to use `partial_cmp` here.
2023-09-18coverage: Fix an unstable-sort inconsistency in coverage spansZalathar-1/+4
This code was calling `sort_unstable_by`, but failed to impose a total order on the initial spans. That resulted in unpredictable handling of closure spans, producing inconsistencies in the coverage maps and in user-visible coverage reports. This patch fixes the problem by always sorting closure spans before otherwise-identical non-closure spans, and also switches to a stable sort in case the ordering is still not total.
2023-09-18Rollup merge of #115908 - cjgillot:lint-noclone, r=oli-obkMatthias Krüger-21/+4
Do not clone MIR for const-prop lint. Addresses https://github.com/rust-lang/rust/pull/115797#issuecomment-1721250533
2023-09-17Do not clone MIR for const-prop lint.Camille GILLOT-21/+4
2023-09-16coverage: Replace an unnecessary map with a setZalathar-7/+7
This hashmap's values were never used.
2023-09-16coverage: Simplify internal representation of debug typesZalathar-135/+131
2023-09-16coverage: Update log module names in debug docsZalathar-2/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 09:26:44 +0000