Fix `-Zgcc-ld=lld`
`-Zgcc-ld=lld` is currently broken. CI is currently ignoring its tests.
cc `@Mark-Simulacrum` on the `compiletest` change: I'm not sure which of `bootstrap`'s test step or `compiletest` is currently incorrect wrt windows' `--compile-lib-path`. Since `sysroot/bin` is passed on windows, that means that `compiletest` can't find `rust-lld` on windows and tests are currently ignored: it's looking for something that is in `sysroot/lib` instead.
They are currently ignored on unixes for a different reason: the lld wrapper has a different name than what is checked.
(I've changed `compiletest` in this PR, just because I could make a very targeted change there, whereas completely changing the intentional lib path that is passed seemed it'd have wider reaching implications on all tests.)
And in both unix/win cases, I've changed the detection to look for `rust-lld` rather than the wrappers in `bin/gcc-ld/`. It seems like the more stable of all these executable names.
r? `@petrochenkov`
I've tested the `lld-wrapper` change on linux and osx, but couldn't test on windows gnu targets (I only have MSVC targets, and these can't use `rust-lld` via `-Zgcc-ld=lld`, nor do they use the lld wrapper IIUC).
I'd expect it to work whether or not the wrapper is called with or without an executable suffix. But at least now CI should test it in these targets.
Fixes#101370.
Remove unnecessary `EMIT_MIR_FOR_EACH_BITWIDTH`
This commit removes the annotation only for those tests where the 32 bit and 64 bit files were exactly identical. I didn't touch anything in the `mir-opt/const` directory, since having this annotation there seems more principled, even if it doesn't make a difference.
This also removes four additional files related to the `separate_const_switch.rs` test. The associated annotations were removed in #100827 , but I forgot to remove the files as well. (#97564 is the issue tracking an automated check here)
r? ```@wesleywiser```
now that CI correctly detects rust-lld in run-make tests, we ignore this
test since it relies on `-Zgcc-ld=lld` which is not made to work on the
windows-msvc targets: it requires a gcc flavor.
Track PGO profiles in depinfo
This PR makes sure that PGO profiles (`-Cprofile-use` and `-Cprofile-sample-use`) are tracked in depinfo, so that when they change, the compilation session will be invalidated.
This approach was discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Tracking.20PGO.20profile.20files.20in.20cargo).
I tried it locally and it seems that the code is recompiled just with this change, and https://github.com/rust-lang/rust/pull/100413 is not even needed. But it's possible that not everything required is recompiled, so we will probably want to land both changes.
Another approach to implement this could be to store the PGO profiles in `sess.parse_sess.file_depinfo` when the session is being created, but then the paths would have to be converted to a string and then to a symbol, which seemed unnecessarily complicated.
CC `@michaelwoerister`
r? `@Eh2406`
Recover from using `;` as separator between fields
Partially fixes#101440 (only for record structs).
Doing that for tuple structs is harder as their parsing passes through a bunch of helper functions. I don't know how to do that. But [their error message is better anyway](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cc6ee8bb2593596c0cea89d49e79bcb4) and suggests using a comma, even if it doesn't suggest replacing the semicolon with it.
Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`
Suggested by the team in [this Zulip Topic](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20SessionDiagnostic.20on.20Handler).
`Handler` already has almost all the capabilities of `ParseSess` when it comes to diagnostic emission, in this migration we only needed to add the ability to access `source_map` from the emitter in order to get a `Snippet` and the `start_point`. Not sure if adding these two methods [`span_to_snippet_from_emitter` and `span_start_point_from_emitter`] is the best way to address this gap.
P.S. If this goes in the right direction, then we probably may want to move `SessionDiagnostic` to `rustc_errors` and rename it to `DiagnosticHandler` or something similar.
r? `@davidtwco`
r? `@compiler-errors`
Suggest removing unnecessary prefix let in patterns
Helps with #101291, though I think `@estebank` probably wants this:
> Finally, I think it'd be nice if we could detect that we don't know for sure and "just" swallow the rest of the expression (find the next ; accounting for nested braces) or the end of the item (easier).
... to be implemented before we close that issue out completely.
Point out when a callable is not actually callable because its return is not sized
Fixes#100755
I didn't add a UI test for that one because it's equivalent to the UI test that already exists in the suite.
Add let else drop order tests
Add a systematic matrix based test that checks temporary drop order in various settings, `let-else-drop-order.rs`, as requested [here](https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523).
The drop order of let and let else is supposed to be the and in order to ensure this, the test checks that this holds for a number of cases.
The test also ensures that we drop the temporaries of the condition before executing the else block.
cc #87335 tracking issue for `let else`
The drop order of let and let else is supposed to be the same,
and in order to ensure this, the test checks that this holds for
the given list of cases.
The test also ensures that we drop the temporaries of the
condition before executing the else block.
We made the test matrix based so it can check all the possible
combinations and find out possible edge cases.
Rollup of 6 pull requests
Successful merges:
- #101142 (Improve HIR stats)
- #101367 (Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch)
- #101391 (more clippy::perf fixes)
- #101409 (Don't fire `rust_2021_incompatible_closure_captures` in `edition = 2021` crates)
- #101420 (Fix `hir::Local` doc to match with the variable name used: `init`)
- #101429 (Don't suggest reborrow if usage is inside a closure)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't suggest reborrow if usage is inside a closure
I can't think of why we would ever be able to *successfully* suggest a mutable reborrow `&mut *` due to a move happening due to a closure, so just suppress it.
Fixes#101119
Suggest `{Option,Result}::{copied,clone}()` to satisfy type mismatch
Fixes#100699, but in the opposite direction (instead of suggesting to fix the signature, it fixes the body)
