repr(transparent): it's fine if the one non-1-ZST field is a ZST
This code currently gets rejected:
```rust
#[repr(transparent)]
struct MyType([u16; 0])
```
That clearly seems like a bug to me: `repr(transparent)` [got defined ](https://github.com/rust-lang/rust/issues/77841#issuecomment-716575747) as having any number of 1-ZST fields plus optionally one more field; `MyType` clearly satisfies that definition.
This PR changes the `repr(transparent)` logic to actually match that definition.
Rollup of 6 pull requests
Successful merges:
- #114965 (Remove Drop impl of mpsc Receiver and (Sync)Sender)
- #115434 (make `Debug` impl for `ascii::Char` match that of `char`)
- #115477 (Stabilize the `Saturating` type)
- #115611 (add diagnostic for raw identifiers in format string)
- #115654 (improve PassMode docs)
- #115862 (Migrate `compiler/rustc_hir_typeck/src/callee.rs` to translatable diagnostics)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `.rmeta` file in `dep-info` have correct name (`lib` prefix)
Since `filename_for_metadata()` and
`OutputFilenames::path(OutputType::Metadata)` had different logic for the name of the metadata file, the `.d` file contained a file name different from the actual name used. Share the logic to fix the out-of-sync name.
Without this fix, the `.d` file contained
dash-separated_something-extra.rmeta: dash-separated.rs
instead of
libdash_separated_something-extra.rmeta: dash-separated.rs
which is the name of the file that is actually written by the compiler.
Worth noting: It took me several iterations to get all tests to pass, so I am relatively confident that this PR does not break anything.
Closes#68839
add diagnostic for raw identifiers in format string
Format strings don't support raw identifiers (e.g. `format!("{r#type}")`), but they do support keywords in the format string directly (e.g. `format!("{type}")`). This PR improves the error output when attempting to use a raw identifier in a format string and adds a machine-applicable suggestion to remove the `r#`.
fixes https://github.com/rust-lang/rust/issues/115466
make `Debug` impl for `ascii::Char` match that of `char`
# Objective
use a more recognisable format for the `Debug` impl on `ascii::Char` than the derived one based off the enum variants. The alogorithm used is the following:
- escape `ascii::Char::{Null, CharacterTabulation, CarraigeReturn, LineFeed, ReverseSolidus, Apostrophe}` to `'\0'`, `'\t'`, `'\r'`, `'\n'`, `'\\'` and `'\''` respectively. these are the same escape codes as `<char as Debug>::fmt` uses.
- if `u8::is_ascii_control` is false, print the character wrapped in single quotes.
- otherwise, print in the format `'\xAB'` where `A` and `B` are the hex nibbles of the byte. (`char` uses unicode escapes and this seems like the corresponding ascii format).
Tracking issue: https://github.com/rust-lang/rust/issues/110998
`#[diagnostic::on_unimplemented]` without filters
This commit adds support for a `#[diagnostic::on_unimplemented]` attribute with the following options:
* `message` to customize the primary error message
* `note` to add a customized note message to an error message
* `label` to customize the label part of the error message
The relevant behavior is specified in [RFC-3366](https://rust-lang.github.io/rfcs/3366-diagnostic-attribute-namespace.html)
impl Step for IP addresses
ACP: rust-lang/libs-team#235
Note: since this is insta-stable, it requires an FCP.
Separating out from the bit operations PR since it feels logically disjoint, and so their FCPs can be separate.
Update doc for `alloc::format!` and `core::concat!`
Closes#115551.
Used comments instead of `assert!`s as [`std::fmt`](https://doc.rust-lang.org/std/fmt/index.html#usage) uses comments.
Should all the str-related macros (`format!`, `format_args!`, `concat!`, `stringify!`, `println!`, `writeln!`, etc.) references each others? For instance, [`concat!`](https://doc.rust-lang.org/core/macro.concat.html) mentions that integers are stringified, but don't link to `stringify!`.
`@rustbot` label +A-docs +A-fmt
Field shorthand overwritten in promote local to const assist
Currently, running `promote_local_to_const` on the following:
```rust
struct Foo {
bar: usize,
}
fn main() {
let $0bar = 0;
let foo = Foo { bar };
}
```
Results in:
```rust
struct Foo {
bar: usize,
}
fn main() {
const BAR: usize = 0;
let foo = Foo { BAR };
}
```
But instead should be something like:
```rust
struct Foo {
bar: usize,
}
fn main() {
const BAR: usize = 0;
let foo = Foo { bar: BAR };
}
```
Specialize count for range iterators
Since `size_hint` is already specialized, it feels apt to specialize `count` as well. Without any specialized version of `ExactSizeIterator::len` or `Step::steps_between`, this feels like a more reliable way of accessing this without having to rely on knowing that `size_hint` is correct.
In my case, this is particularly useful to access the `steps_between` implementation for `char` from the standard library without having to compute it manually.
I didn't think it was worth modifying the `Step` trait to add a version of `steps_between` that used native overflow checks since this is just doing one subtraction in most cases anyway, and so I decided to make the inclusive version use `checked_add` so it didn't have this lopsided overflow-checks-but-only-sometimes logic.
don't globally ignore rustc-ice files
Reverts a change that happened in https://github.com/rust-lang/rust/pull/114586 but is unrelated to that PR and wasn't discussed.
ICE files appearing is somewhat of a nuisance, but I'd rather clean them up than have them accumulate in my source folder. `@oli-obk` if you want to ignore them you can add them to your local `.git/info/exclude`.
