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```
stdio: Document no support for writing to non-blocking stdio/stderr
Printing to stdio/stderr that have been opened with non-blocking
(O_NONBLOCK in linux) can result in an error, which is not handled
by std::io module causing a panic.
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
Add -api-level to pm command
As of ~Aug 30th, `pm build` commands require an `api-level` flag. This flag should match the fuchsia api-level that's being targeted by the code. Since this is dependent on the version of the SDK that's being used, we may want to change this to something a bit more robust in the future.
Printing to stdio/stderr that have been opened with non-blocking
(O_NONBLOCK in linux) can result in an error, which is not handled
by std::io module causing a panic.
Signed-off-by: Usama Arif <usama.arif@bytedance.com>
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`
rustdoc: remove unused CSS `#results > table`
This code was added in 96ef2f8ab9 to improve rendering of the search results table, but results have not used a table since b615c0c854 switched it to rendering with `<div>` tags.
Rollup of 7 pull requests
Successful merges:
- #101357 (Include enum path in variant suggestion)
- #101434 (Update `SessionDiagnostic::into_diagnostic` to take `Handler` instead of `ParseSess`)
- #101445 (Suggest introducing an explicit lifetime if it does not exist)
- #101457 (Recover from using `;` as separator between fields)
- #101462 (Rustdoc-Json: Store Variant Fields as their own item.)
- #101471 (Report number of delayed bugs properly with `-Ztreat-err-as-bug`)
- #101473 (Add more size assertions for MIR types.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This CSS still matches sometimes, as you can see in
<https://doc.rust-lang.org/1.63.0/std/collections/enum.TryReserveErrorKind.html#variant.AllocError.fields>,
but since nothing else is setting `margin-top`, putting it back to `initial`
does nothing.
This selector was added in 2fd378b82b (but it
was called `.stability` instead of `.item-info` at the time), probably as an
override for the selector immediately above it that sets a negative margin.
That negative margin was removed in 593d6d1cb1.
This code was added in 96ef2f8ab9 to improve
rendering of the search results table, but results have not used a table
since b615c0c854 switched it to rendering with
`<div>` tags.
Report number of delayed bugs properly with `-Ztreat-err-as-bug`
Report the number of delayed bugs that went into the `-Ztreat-errr-as-bug=N` being triggered, even if we don't count it in the err_count in regular diagnostic output.
Sometimes we have a session that creates a few diagnostics, perhaps: Error, Delay bug, Error, then Delay bug.
If I ran `-Ztreat-err-as-bug=3`, then I will now see "aborting after 2 errors and 1 delayed bugs" instead of just "after 2 errors" which is confusing since I passed `3`.
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`
Document eager evaluation of `bool::then_some` argument
I encountered this earlier today and thought maybe `bool::then_some` could use a little addition to the documentation.
It's pretty obvious with familiarity and from looking at the implementation, but the argument for `then_some` is eagerly evaluated, which means if you do the following (as I did), you can have a problem:
```rust
// Oops!
let _ = something
.has_another_thing()
.then_some(something.another_thing_or_panic());
```
A note, similar to other methods with eagerly-evaluated arguments and a lazy alternative (`Option::or`, for example), could help point this out to people who forget (like me)!
