This property was added to help with positioning the `[+]/[-]` toggle.
It is no longer necessary, because `details.rustdoc-toggle` already has
`position:relative` set on it.
When `.impl-items { flex-basis: 100% }` and `h3.impl, h3.method, h4.method,
h3.type, h4.type, h4.associatedconstant` were added in
34bd2b845b, it seems like it was a mistake even
then. According to MDN, [flex-basis] does nothing unless the box it's applied
to is a flex *item*, a child of a flex container. However, when this was
added, these elements were flex containers themselves.
[flex-basis]: https://developer.mozilla.org/en-US/docs/Web/CSS/flex-basis
Remove `expr_parentheses_needed` from `ParseSess`
Not sure why this method needed to exist on `ParseSess`, but we can achieve the same behavior by just inlining it everywhere.
Improve `File::set_times` error handling
Makes `File::set_times` return an error if the `SystemTime` cannot fit into the required type instead of panicking in `FileTimes::set_{accessed,modified}`. Also makes `File::set_times` return an error on Windows if either of the passed times are `0xFFFF_FFFF_FFFF_FFFF`, as [the documentation for `SetFileTime`](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfiletime) states that this will prevent operations on the file handle from updating the corresponding file time instead of setting the corresponding file time to that value.
Tracking issue: #98245
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
