Fix `format_args` capture for macro expanded format strings
Since #100996 `format_args` capture for macro expanded strings aren't prevented when the span of the expansion points to a string literal, e.g.
```rust
// not a terribly realistic example, but also happens for proc_macros that set
// the span of the output to an input str literal, such as indoc
macro_rules! x {
($e:expr) => { $e }
}
fn main() {
let a = 1;
println!(x!("{a}"));
}
```
The tests didn't catch it as the span of `concat!()` points to the macro invocation
r? `@m-ou-se`
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
Migrate sidebar links color to CSS variables and unify themes with ayu
Part of https://github.com/rust-lang/rust/pull/98460.
This PR does two things:
1. Migrate more theme CSS rules toward CSS variables.
2. Remove `a.current` specific colors depending on the kind of the item behind the link. The `ayu` theme was already doing it this way and I think it makes much more sense like this.
You can test it [here](https://rustdoc.crud.net/imperio/sidebar-links-color/lib2/struct.Foo.html) by hovering other module's items in the sidebar (or check the selector `a.current`).
cc `@jsha`
r? `@notriddle`
Rollup of 7 pull requests
Successful merges:
- #102361 (Fix ICE in const_trait check code)
- #102373 (Flush delayed bugs before codegen)
- #102483 (create def ids for impl traits during ast lowering)
- #102490 (Generate synthetic region from `impl` even in closure body within an associated fn)
- #102492 (Don't lower assoc bindings just to deny them)
- #102493 (Group together more size assertions.)
- #102521 (rustdoc: add missing margin to no-docblock methods)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
The system GCC 5 in ubuntu:16.04 will be too old to compile LLVM 16, so
we need an upgrade. To avoid raising the minimum glibc requirements for
`i586-unknown-linux-gnu`, this target is converted to a crosstool-ng
toolchain, *relaxing* it to the same Linux 3.2 / glibc 2.17 minimum we
use elsewhere. The musl targets still use Ubuntu's system toolchain, but
this doesn't have the same compatibility concerns.
Group together more size assertions.
Also add a few more assertions for some relevant token-related types.
And fix an erroneous comment in `rustc_errors`.
r? `@lqd`
Flush delayed bugs before codegen
Sometimes it can happen that invalid code like a TyKind::Error makes its way through the compiler without triggering any errors (this is always a bug in rustc but bugs do happen sometimes :)). These ICEs will manifest in the backend like as cg_llvm not being able to get the layout of `[type error]`, which makes it hard to debug. By flushing before codegen, we display all the delayed bugs, making it easier to trace it to the root of the problem.
I tried this on #102366 and it showed tons of of delayed bugs and no error in cg_llvm, so it seems to be working.
This is 682889fb06, but for arrays instead.
For non-generics, this retains links to the array page, but instead of
trying to link it all, it only links the length part, which distinguishes
arrays from slices.
For generics, the entire thing becomes a link, just like slices.
rustdoc: remove no-op CSS `h3.variant, .sub-variant h4 { border-bottom: none }`
This rule, added in 69df43b041 to override the default `h4` style, has been obsoleted when a65c98fefb changed it so that only the top docblock put `border-bottom` on `h4.`
