Enable combining `+crt-static` and `relocation-model=pic` on `x86_64-unknown-linux-gnu`
Modern `gcc` versions support `-static-pie`, and `rustc` will already fall-back to `-static` if the local `gcc` is too old (and hence this change is optimistic rather than absolute). This brings the `-musl` and `-gnu` targets to feature compatibility (albeit with different default settings).
Of note a `-static` or `-static-pie` binary based on glibc that uses NSS-backed functions (`gethostbyname` or `getpwuid` etc.) need to have access to the `libnss_X.so.2` libraries and any of their dynamic dependencies.
I wasn't sure about the `# only`/`# ignore` changes (I've not got a `gnux32` toolchain to test with hence not also enabling `-static-pie` there).
Disable drop range analysis
The previous PR, #93165, still performed the drop range analysis despite ignoring the results. Unfortunately, there were ICEs in the analysis as well, so some packages failed to build (see the issue #93197 for an example). This change further disables the analysis and just provides dummy results in that case.
Rollup of 9 pull requests
Successful merges:
- #91343 (Fix suggestion to slice if scrutinee is a `Result` or `Option`)
- #93019 (If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase)
- #93090 (`impl Display for io::ErrorKind`)
- #93456 (Remove an unnecessary transmute from opaque::Encoder)
- #93492 (Hide failed command unless in verbose mode)
- #93504 (kmc-solid: Increase the default stack size)
- #93513 (Allow any pretty printed line to have at least 60 chars)
- #93532 (Update books)
- #93533 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Allow any pretty printed line to have at least 60 chars
Follow-up to #93155. The rustc AST pretty printer has a tendency to get stuck in "vertical smear mode" when formatting highly nested code, where it puts a linebreak at *every possible* linebreak opportunity once the indentation goes beyond the pretty printer's target line width:
```rust
...
((&([("test"
as
&str)]
as
[&str; 1])
as
&[&str; 1]),
(&([]
as
[ArgumentV1; 0])
as
&[ArgumentV1; 0]))
...
```
```rust
...
[(1
as
i32),
(2
as
i32),
(3
as
i32)]
as
[i32; 3]
...
```
This is less common after #93155 because that PR greatly reduced the total amount of indentation, but the "vertical smear mode" failure mode is still just as present when you have deeply nested modules, functions, or trait impls, such as in the case of macro-expanded code from `-Zunpretty=expanded`.
Vertical smear mode is never the best way to format highly indented code though. It does not prevent the target line width from being exceeded, and it produces output that is less readable than just a longer line.
This PR makes the pretty printing algorithm allow a minimum of 60 chars on every line independent of indentation. So as code gets more indented, the right margin eventually recedes to make room for formatting without vertical smear.
```console
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├─────────────────────────────────────┤
├───────────────────────────────────┤
├─────────────────────────────────┤
├───────────────────────────────┤
├─────────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├───────────────────────────┤
├─────────────────────────────┤
├───────────────────────────────┤
├─────────────────────────────────┤
├───────────────────────────────────┤
├─────────────────────────────────────┤
```
If an integer is entered with an upper-case base prefix (0Xbeef, 0O755, 0B1010), suggest to make it lowercase
The current error for this case isn't really great, it just complains about the whole thing past the `0` being an invalid suffix.
rustc_errors: only box the `diagnostic` field in `DiagnosticBuilder`.
I happened to need to do the first change (replacing `allow_suggestions` with equivalent functionality on `Diagnostic` itself) as part of a larger change, and noticed that there's only two fields left in `DiagnosticBuilderInner`.
So with this PR, instead of a single pointer, `DiagnosticBuilder` is two pointers, which should work just as well for passing *it* by value (and may even work better wrt some operations, though probably not by much).
But anything that was already taking advantage of `DiagnosticBuilder` being a single pointer, and wrapping it further (e.g. `Result<T, DiagnosticBuilder>` w/ non-ZST `T`), ~~will probably see a slowdown~~, so I want to do a perf run before even trying to propose this.
Check that `#[rustc_must_implement_one_of]` is applied to a trait
`#[rustc_must_implement_one_of]` only makes sense when applied to a trait, so it's sensible to emit an error otherwise.
Store def_id_to_hir_id as variant in hir_owner.
If hir_owner is Owner(_), the LocalDefId is pointing to an owner, so the ItemLocalId is 0.
If the HIR node does not exist, we store Phantom.
Otherwise, we store the HirId associated to the LocalDefId.
Related to #89278
r? `@oli-obk`
Switch pretty printer to block-based indentation
This PR backports 401d60c042 from the `prettyplease` crate into `rustc_ast_pretty`.
A before and after:
```diff
- let res =
- ((::alloc::fmt::format as
- for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1
- as
- fn(&[&'static str], &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([("test"
- as
- &str)]
- as
- [&str; 1])
- as
- &[&str; 1]),
- (&([]
- as
- [ArgumentV1; 0])
- as
- &[ArgumentV1; 0]))
- as
- Arguments))
- as String);
+ let res =
+ ((::alloc::fmt::format as
+ for<'r> fn(Arguments<'r>) -> String {format})(((::core::fmt::Arguments::new_v1
+ as
+ fn(&[&'static str], &[ArgumentV1]) -> Arguments {Arguments::new_v1})((&([("test"
+ as &str)] as [&str; 1]) as
+ &[&str; 1]),
+ (&([] as [ArgumentV1; 0]) as &[ArgumentV1; 0])) as
+ Arguments)) as String);
```
Previously the pretty printer would compute indentation always relative to whatever column a block begins at, like this:
```rust
fn demo(arg1: usize,
arg2: usize);
```
This is never the thing to do in the dominant contemporary Rust style. Rustfmt's default and the style used by the vast majority of Rust codebases is block indentation:
```rust
fn demo(
arg1: usize,
arg2: usize,
);
```
where every indentation level is a multiple of 4 spaces and each level is indented relative to the indentation of the previous line, not the position that the block starts in.
By itself this PR doesn't get perfect formatting in all cases, but it is the smallest possible step in clearly the right direction. More backports from `prettyplease` to tune the ibox/cbox indent levels around various AST node types are upcoming.
The `print_expr` method already places an `ibox(INDENT_UNIT)` around
every expr that gets printed. Some exprs were then using `self.head`
inside of that, which does its own `cbox(INDENT_UNIT)`, resulting in two
levels of indentation:
while true {
stuff;
}
This commit fixes those cases to produce the expected single level of
indentation within every expression containing a block.
while true {
stuff;
}
Previously the pretty printer would compute indentation always relative
to whatever column a block begins at, like this:
fn demo(arg1: usize,
arg2: usize);
This is never the thing to do in the dominant contemporary Rust style.
Rustfmt's default and the style used by the vast majority of Rust
codebases is block indentation:
fn demo(
arg1: usize,
arg2: usize,
);
where every indentation level is a multiple of 4 spaces and each level
is indented relative to the indentation of the previous line, not the
position that the block starts in.
Create `core::fmt::ArgumentV1` with generics instead of fn pointer
Split from (and prerequisite of) #90488, as this seems to have perf implication.
`@rustbot` label: +T-libs
Render more readable macro matcher tokens in rustdoc
Follow-up to #92334.
This PR lifts some of the token rendering logic from https://github.com/dtolnay/prettyplease into rustdoc so that even the matchers for which a source code snippet is not available (because they are macro-generated, or any other reason) follow some baseline good assumptions about where the tokens in the macro matcher are appropriate to space.
The below screenshots show an example of the difference using one of the gnarliest macros I could find. Some things to notice:
- In the **before**, notice how a couple places break in between `$(....)`↵`*`, which is just about the worst possible place that it could break.
- In the **before**, the lines that wrapped are weirdly indented by 1 space of indentation relative to column 0. In the **after**, we use the typical way of block indenting in Rust syntax which is put the open/close delimiters on their own line and indent their contents by 4 spaces relative to the previous line (so 8 spaces relative to column 0, because the matcher itself is indented by 4 relative to the `macro_rules` header).
- In the **after**, macro_rules metavariables like `$tokens:tt` are kept together, which is how just about everybody writing Rust today writes them.
## Before
## After
r? `@camelid`
Rename _args -> args in format_args expansion
As observed in https://github.com/rust-lang/rust/pull/91359#discussion_r786058960, prior to that PR this variable was sometimes never used, such as in the case of:
```rust
println!("");
// used to expand to:
::std::io::_print(
::core::fmt::Arguments::new_v1(
&["\n"],
&match () {
_args => [],
},
),
);
```
so the leading underscore in `_args` was used to suppress an unused variable lint. However after #91359 the variable is always used when present, as the unused case would instead expand to:
```rust
::std::io::_print(::core::fmt::Arguments::new_v1(&["\n"], &[]));
```
