about summary refs log tree commit diff
path: root/compiler/rustc_mir_transform/src
AgeCommit message (Collapse)AuthorLines
2023-06-26Migrate predicates_of and caller_bounds to ClauseMichael Goulet-4/+4
2023-06-25use PlaceRef abstractions more consistentlyEric Mark Martin-5/+3
2023-06-22Migrate item_bounds to ty::ClauseMichael Goulet-1/+1
2023-06-21Auto merge of #112834 - oli-obk:mir_opts_considered_unsound, r=cjgillotbors-2/+6
Disable two mir opts that are known to be unsound closes #112460 (does not fix the underlying issue) r? `@cjgillot`
2023-06-21Disable two mir opts that are known to be unsoundOli Scherer-2/+6
2023-06-21Rollup merge of #112844 - Vanille-N:unique, r=RalfJungNilstrieb-0/+1
Add retag in MIR transform: `Adt` for `Unique` may contain a reference Following #112662 , `may_contain_reference` in `rustc_mir_transform::add_retag` underapproximates too much the types that require retagging. r? ``@RalfJung``
2023-06-21Rollup merge of #112772 - compiler-errors:clauses-1, r=lcnrNilstrieb-2/+2
Add a fully fledged `Clause` type, rename old `Clause` to `ClauseKind` Does two basic things before I put up a more delicate set of PRs (along the lines of #112714, but hopefully much cleaner) that migrate existing usages of `ty::Predicate` to `ty::Clause` (`predicates_of`/`item_bounds`/`ParamEnv::caller_bounds`). 1. Rename `Clause` to `ClauseKind`, so it's parallel with `PredicateKind`. 2. Add a new `Clause` type which is parallel to `Predicate`. * This type exposes `Clause::kind(self) -> Binder<'tcx, ClauseKind<'tcx>>` which is parallel to `Predicate::kind` 😸 The new `Clause` type essentially acts as a newtype wrapper around `Predicate` that asserts that it is specifically a `PredicateKind::Clause`. Turns out from experimentation[^1] that this is not negative performance-wise, which is wonderful, since this a much simpler design than something that requires encoding the discriminant into the alignment bits of a predicate kind, or something else like that... r? ``@lcnr`` or ``@oli-obk`` [^1]: https://github.com/rust-lang/rust/pull/112714#issuecomment-1595653910
2023-06-21Rollup merge of #112759 - cjgillot:closure-names, r=oli-obkNilstrieb-6/+22
Make closure_saved_names_of_captured_variables a query. As we will start removing debuginfo during MIR optimizations, we need to keep them somewhere.
2023-06-20`Adt` for `Unique` may contain a referenceNeven Villani-0/+1
2023-06-20merge `BorrowKind::Unique` into `BorrowKind::Mut`Ziru Niu-3/+3
2023-06-19Rollup merge of #112232 - fee1-dead-contrib:match-eq-const-msg, r=b-naberMichael Goulet-9/+9
Better error for non const `PartialEq` call generated by `match` Resolves #90237
2023-06-19Store generator field names in GeneratorLayout.Camille GILLOT-6/+22
2023-06-19s/Clause/ClauseKindMichael Goulet-2/+2
2023-06-19Promote unchecked_add/sub/mul/shl/shr to mir::BinOpScott McMurray-1/+11
2023-06-19add FIXME's for a later refactoringlcnr-3/+6
2023-06-19mir opt: fix subtype handlinglcnr-0/+20
2023-06-19fix types in shim buildinglcnr-7/+23
2023-06-18Auto merge of #112638 - lqd:rpo, r=cjgillotbors-3/+3
Switch the BB CFG cache from postorder to RPO The `BasicBlocks` CFG cache is interesting: - it stores a postorder, but `traversal::postorder` doesn't use it - `traversal::reverse_postorder` does traverse the postorder cache backwards - we do more RPO traversals than postorder traversals (around 20x on the perf.rlo benchmarks IIRC) but it's not cached - a couple places here and there were manually reversing the non-cached postorder traversal This PR switches the order of the cache, and makes a bit more use of it. This is a tiny win locally, but it's also for consistency and aesthetics. r? `@ghost`
2023-06-18Better error for non const `PartialEq` call generated by `match`Deadbeef-9/+9
2023-06-18Auto merge of #112599 - saethlin:cleaner-panics, r=thomccbors-6/+4
Launch a non-unwinding panic for misaligned pointer deref This panic already never unwinds, but that's only because it always hits the unwind guard that's created by our `UnwindAction::Terminate`. Hitting the unwind guard generates a huge double-panic backtrace. Now we generate a normal-looking panic message when this check is hit. r? `@thomcc`
2023-06-16Auto merge of #112716 - compiler-errors:rollup-h77daia, r=compiler-errorsbors-0/+4
Rollup of 7 pull requests Successful merges: - #111074 (Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`) - #112226 (std: available_parallelism using native netbsd api first) - #112474 (Support 128-bit enum variant in debuginfo codegen) - #112662 (`#[lang_item]` for `core::ptr::Unique`) - #112665 (Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`) - #112684 (Disable alignment checks on i686-pc-windows-msvc) - #112706 (Add `SyntaxContext::is_root`) r? `@ghost` `@rustbot` modify labels: rollup
2023-06-16Ignore the always part of #[inline(always)] in MIR inliningBen Kimock-4/+5
2023-06-16Update compiler/rustc_mir_transform/src/check_alignment.rsWesley Wiser-0/+1
2023-06-16Launch a non-unwinding panic for misaligned pointer derefBen Kimock-6/+4
2023-06-16Disable alignment checks on i686-pc-windows-msvcBen Kimock-0/+3
2023-06-15Rollup merge of #112403 - nbdd0121:eh_frame, r=NilstriebGuillaume Gomez-1/+6
Prevent `.eh_frame` from being emitted for `-C panic=abort` Since `CheckAlignment` pass is after the `AbortUnwindingCalls` pass, the `UnwindAction::Terminate` inserted in it has no chance to be converted to `UnwindAction::Unreachable` anymore, causing us to emit landing pads that are not necessary. Although these landing pads can themselves be eliminated by LLVM, `.eh_frame` sections are still generated. This causes trouble for Rust-for-Linux project recently. This PR changes it to generate `UnwindAction::Terminate` when we opt for `-Cpanic=unwind`, and `UnwindAction::Unreachable` for `-Cpanic=abort`. `@ojeda`
2023-06-14make reorder BB pass use cached RPORémy Rakic-1/+1
2023-06-14make const-prop use cached RPORémy Rakic-2/+2
2023-06-14s/drain_filter/extract_if/ for Vec, Btree{Map,Set} and LinkedListThe 8472-9/+6
2023-06-13Auto merge of #112017 - Nemo157:unsafe-block-rustfix, r=eholkbors-11/+45
Add MVP suggestion for `unsafe_op_in_unsafe_fn` Rebase of https://github.com/rust-lang/rust/pull/99827 cc tracking issue https://github.com/rust-lang/rust/issues/71668 No real changes since the original PR, just migrated the new suggestion to use fluent messages and added a couple more testcases, AFAICT from the discussion there were no outstanding changes requested.
2023-06-13Add note about unsafe functions body not being unsafeWim Looman-3/+14
2023-06-13Hide suggestion to wrap function in unsafe blockWim Looman-1/+1
2023-06-13Add MVP suggestion for `unsafe_op_in_unsafe_fn`Léo Lanteri Thauvin-11/+34
Nemo157 rebase notes: Migrated the changes to the lint into fluent
2023-06-09Auto merge of #111626 - pjhades:output, r=b-naberbors-4/+11
Write to stdout if `-` is given as output file With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together. This implements https://github.com/rust-lang/compiler-team/issues/431 The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
2023-06-08Auto merge of #108293 - Jarcho:mut_analyses, r=eholkbors-32/+47
Take MIR dataflow analyses by mutable reference The main motivation here is any analysis requiring dynamically sized scratch memory to work. One concrete example would be pointer target tracking, where tracking the results of a dereference can result in multiple possible targets. This leads to processing multi-level dereferences requiring the ability to handle a changing number of potential targets per step. A (simplified) function for this would be `fn apply_deref(potential_targets: &mut Vec<Target>)` which would use the scratch space contained in the analysis to send arguments and receive the results. The alternative to this would be to wrap everything in a `RefCell`, which is what `MaybeRequiresStorage` currently does. This comes with a small perf cost and loses the compiler's guarantee that we don't try to take multiple borrows at the same time. For the implementation: * `AnalysisResults` is an unfortunate requirement to avoid an unconstrained type parameter error. * `CloneAnalysis` could just be `Clone` instead, but that would result in more work than is required to have multiple cursors over the same result set. * `ResultsVisitor` now takes the results type on in each function as there's no other way to have access to the analysis without cloning it. This could use an associated type rather than a type parameter, but the current approach makes it easier to not care about the type when it's not necessary. * `MaybeRequiresStorage` now no longer uses a `RefCell`, but the graphviz formatter now does. It could be removed, but that would require even more changes and doesn't really seem necessary.
2023-06-07Remove wrongly emitted `.eh_frame` in `-Cpanic=abort`Gary Guo-1/+6
2023-06-06Write to stdout if `-` is given as output fileJing Peng-4/+11
If `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (`obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
2023-06-05cleanup some skip_binder -> subst_identityKyle Matsuda-1/+1
2023-06-04Auto merge of #112240 - cjgillot:recurse-inline, r=scottmcmbors-3/+6
Only check inlining counter after recursing. This PR aims to reduce the strength of https://github.com/rust-lang/rust/pull/105119 even more. In the current implementation, we check the inline count before recursing. This means that we never actually reach inlining depth 3. This PR checks the counter after recursion, to give a chance to inline at depth >= 3. r? `@scottmcm` cc `@JakobDegen`
2023-06-03Only check inlining counter after recusing.Camille GILLOT-3/+6
2023-06-02Rollup merge of #112168 - scottmcm:lower-div-rem-unchecked-to-mir, r=oli-obkMichael Goulet-23/+28
Lower `unchecked_div`/`_rem` to MIR's `BinOp::Div`/`Rem` As described in <https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.BinOp.html#variant.Div>, the ordinary `BinOp`s for these are already UB for division by zero ([or overflow](https://llvm.org/docs/LangRef.html#sdiv-instruction), [demo](https://rust.godbolt.org/z/71e7P7Exh)), as MIR building is responsible for inserting code to panic for those cases regardless of whether the overflow checks are enabled. So we can lower these in the same arm that lowers `wrapping_add` to MIR `BinOp::Add` and such, as all these cases turn into ordinary `Rvalue::BinaryOp`s.
2023-06-02Separate AnonConst from ConstBlock in HIR.Camille GILLOT-4/+2
2023-06-02Auto merge of #111677 - fee1-dead-contrib:rustc_const_eval-translatable, ↵bors-7/+26
r=oli-obk,RalfJung Use translatable diagnostics in `rustc_const_eval` This PR: * adds a `no_span` parameter to `note` / `help` attributes when using `Subdiagnostic` to allow adding notes/helps without using a span * has minor tweaks and changes to error messages
2023-06-01Auto merge of #112040 - cjgillot:separate-const-switch, r=oli-obkbors-17/+30
Enable ConstGoto and SeparateConstSwitch passes by default These 2 passes implement a limited form of jump-threading. Filing this PR to see if enabling them would be lighter than https://github.com/rust-lang/rust/pull/107009.
2023-06-01fix diagnostic messageDeadbeef-2/+4
2023-06-01improve debug message by eagerly translatingDeadbeef-2/+2
2023-06-01Use translatable diagnostics in `rustc_const_eval`Deadbeef-7/+24
2023-06-01Auto merge of #112002 - saethlin:enable-sroa, r=oli-obk,scottmcmbors-5/+45
Enable ScalarReplacementOfAggregates in optimized builds Like MatchBranchSimplification, this pass is known to produce significant runtime improvements in Cranelift artifacts, and I believe based on the perf runs here that the primary effect of this pass is to empower MatchBranchSimplification. ScalarReplacementOfAggregates on its own has little effect on anything, but when this was rebased up to include https://github.com/rust-lang/rust/pull/112001 we started seeing significant and majority-positive results. Based on the fact that we see most of the regressions in debug builds (https://github.com/rust-lang/rust/pull/112002#issuecomment-1566270144) and some rather significant ones in cycles and wall time, I'm only enabling this in optimized builds at the moment.
2023-06-01Lower unchecked_{div, rem} to BinOp::{Div, Rem}Scott McMurray-23/+28
2023-05-31Enable ScalarReplacementOfAggregatesBen Kimock-5/+45