| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix clippy::single_char_pattern perf findings
|
|
Rollup of 7 pull requests
Successful merges:
- #90939 (Tweak errors coming from `for`-loop, `?` and `.await` desugaring)
- #91859 (Iterator::cycle() — document empty iterator special case)
- #91868 (Use `OutputFilenames` to generate output file for `-Zllvm-time-trace`)
- #91870 (Revert setting a default for the MACOSX_DEPLOYMENT_TARGET env var for linking)
- #91881 (Stabilize `iter::zip`)
- #91882 (Remove `in_band_lifetimes` from `rustc_typeck`)
- #91940 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Previously some code paths would fail to evaluate the rvalue, while
incorrectly indicating success with `Ok`. As a result the previous value
of lhs could have been incorrectly const propagated.
|
|
|
|
This optimization pass previously made excessive assumptions as to the nature of
the blocks being optimized. We remove those assumptions and make sure to
rigorously justify all changes that are made to the MIR. Details can be found
in the file.
|
|
|
|
|
|
|
|
Remove `in_band_lifetimes` from `rustc_mir_transform`
Like #91580, this was inspired by the conversation in #44524 about possibly removing the feature from the compiler. This crate is a heavy `'tcx` user, so is a nice case study.
r? ``@petrochenkov``
Three interesting ones:
This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`:
```diff
-impl Visitor<'_> for UsedLocals {
+impl<'tcx> Visitor<'tcx> for UsedLocals {
fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
```
This one use in-band for one, and underscore for the other:
```diff
-pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) {
+pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
```
A spurious name, since there's no single-use-lifetime warning:
```diff
-pub fn run_passes(tcx: TyCtxt<'tcx>, body: &'mir mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
+pub fn run_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
```
|
|
Address some FIXMEs left over from #91475
This shouldn't change behavior, only clarify what we're currently doing. I filed #91576 to see if the treatment of generator drop shims is intentional.
cc #91475
|
|
This one is a heavy `'tcx` user.
Two interesting ones:
This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`:
```diff
-impl Visitor<'_> for UsedLocals {
+impl<'tcx> Visitor<'tcx> for UsedLocals {
fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
```
This one use in-band for one, and underscore for the other:
```diff
-pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) {
+pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
```
|
|
Small mir-opt refactor
Hopefully-non-controversial changes from some not-ready-yet work that I'd figured I'd submit on their own.
|
|
Notably, the passes at the end of `make_shim` aren't applied to them.
|
|
|
|
Add a MIR pass manager (Taylor's Version)
The final draft of #91386 and #77665.
While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today:
- Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase.
- `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch on `body.phase` yourself.
- If your pass is solely to emit errors, you can use the `MirLint` interface instead, which gets a shared reference to `Body` instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?
- MIR is no longer dumped for passes that aren't enabled, or for lints.
I tried to check that `-Zvalidate` still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes in `run_passes`. However, it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors).
cc `@oli-obk` `@wesleywiser`
r? rust-lang/wg-mir-opt
|
|
|
|
|
|
Looks like Generator drop shims already have `post_borrowck_cleanup` run
on them. That's a bit surprising, since it means they're getting const-
and maybe borrow-checked? This merits further investigation, but for now
just preserve the status quo.
|
|
|
|
|
|
|
|
|
|
r=oli-obk
Move `#![feature(const_precise_live_drops)]` checks earlier in the pipeline
Should mitigate the issues found during MCP on #73255.
Once this is done, we should clean up the queries a bit, since I think `mir_drops_elaborated_and_const_checked` can be merged back into `mir_promoted`.
Fixes #90770.
cc ``@rust-lang/wg-const-eval``
r? ``@nikomatsakis`` (since they reviewed #71824)
|
|
Instead we run `RemoveFalseEdges` and `RemoveUninitDrops` at the
appropriate time. The extra `SimplifyCfg` avoids visiting unreachable
blocks during `RemoveUninitDrops`.
|
|
...since its name is very close to `RemoveUninitDrops`.
|
|
|
|
Otherwise dataflow state will propagate along false edges and cause
things to be marked as maybe init unnecessarily. These should be
separate, since `SimplifyBranches` also makes `if true {} else {}` into
a `goto`, which means we wouldn't lint anything in the `else` block.
|
|
Visit type in process_projection_elem.
Instead of reimplementing it for each visitor.
|
|
|
|
|
|
Hopefully-non-controversial changes from some not-ready-yet work that I'd figured I'd submit on their own.
|
|
Previously for enums using the `Variants::Single` layout, the variant
index was being confused with its discriminant. For example, in the case
of `enum E { A = 1 }`.
Use `discriminant_for_variant` to avoid the issue.
|
|
The change is limited to the iteration over indices instead of using
`basic_blocks_mut()` directly, in the case the previous implementation
intentionally avoided invalidating the caches stored in MIR body.
|
|
For some time CTFE has been using a dedicated MIR which is never
optimized, so the check for promoted became redundant.
|
|
|
|
Run reveal_all on MIR when inlining is activated.
Fix logic error in https://github.com/rust-lang/rust/pull/85254 which prevented the pass from running when needed.
Fixes https://github.com/rust-lang/rust/issues/78442
r? ``@lcnr``
|
|
|
|
|
|
|
|
Bump bootstrap compiler to 1.57
Fixes https://github.com/rust-lang/rust/issues/90152
r? `@Mark-Simulacrum`
|
|
Rollup of 6 pull requests
Successful merges:
- #89558 (Add rustc lint, warning when iterating over hashmaps)
- #90100 (Skip documentation for tier 2 targets on dist-x86_64-apple-darwin)
- #90155 (Fix alignment of method headings for scannability)
- #90162 (Mark `{array, slice}::{from_ref, from_mut}` as const fn)
- #90221 (Fix ICE when forgetting to `Box` a parameter to a `Self::func` call)
- #90234 (Temporarily turn overflow checks off for rustc-rayon-core)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add rustc lint, warning when iterating over hashmaps
r? rust-lang/wg-incr-comp
|
|
Normalize MIR with RevealAll before optimizations.
Fixes #78442
|
|
|
|
Remove redundant dump_enabled check
|
|
Remove hir::map::blocks and use FnKind instead
The principal tool is `FnLikeNode`, which is not often used and can be easily implemented using `rustc_hir::intravisit::FnKind`.
|
|
|
|
|
|
Adopt let_else across the compiler
This performs a substitution of code following the pattern:
```
let <id> = if let <pat> = ... { identity } else { ... : ! };
```
To simplify it to:
```
let <pat> = ... { identity } else { ... : ! };
```
By adopting the `let_else` feature (cc #87335).
The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet.
Note: Generally I'm the person who *removes* usages of unstable features from the compiler, not adds more usages of them, but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.
|
