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
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.`
Reinstate `hir-stats.rs` test for stage 1.
It was disabled in #94075 for stage 1 because that PR changed type layouts such that the results for this test were different for stage 1 and stage 2. But now that #94075 is in beta, the results for this test are now the same for stage 1 and stage 2.
r? ```@lqd```
remove the unused :: between trait and type to give user correct diag…
…nostic information
modified: compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
new file: src/test/ui/type/issue-101866.rs
new file: src/test/ui/type/issue-101866.stderr
rustdoc: remove unneeded CSS `.rust-example-rendered { position }`
The Run button isn't inside the `<pre>` any more. It's instead nested below the example wrapper.
The class name can't be removed from the DOM, because `main.js` uses it.
Improve errors for incomplete functions in struct definitions
Given the following code:
```rust
fn main() {}
struct Foo {
fn
}
```
[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=29139f870511f6918324be5ddc26c345)
The current output is:
```
Compiling playground v0.0.1 (/playground)
error: functions are not allowed in struct definitions
--> src/main.rs:4:5
|
4 | fn
| ^^
|
= help: unlike in C++, Java, and C#, functions are declared in `impl` blocks
= help: see https://doc.rust-lang.org/book/ch05-03-method-syntax.html for more information
error: could not compile `playground` due to previous error
```
In this case, rustc should suggest escaping `fn` to use it as an identifier.
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.`
It was disabled in #94075 for stage 1 because that PR changed type
layouts such that the results for this test were different for stage 1
and stage 2. But now that #94075 is in beta, the results for this test
are now the same for stage 1 and stage 2.
modified: compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
new file: src/test/ui/type/issue-101866.rs
new file: src/test/ui/type/issue-101866.stderr
tidy: make rustc dependency error less confusing
The current wording leads to very confusing messages:
```
tidy error: Dependencies for main workspace not explicitly permitted:
* unicode-ident 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)
```
Miri is part of that workspace, and there never was a problem adding Miri dependencies. The actual error is that due to a crate bump this now showed up as a rustc dependency, and *those* are restricted.
rustdoc: remove bad CSS font-weight on `.impl`, `.method`, etc
This line was added in c494a06064, because at the time, the headers had these classes on them. Now, the headers are children of the `<section>` with the class on it.
This commit also adds a test case, to make sure the srclink font weight does not regress again.
Fix span of byte-escaped left format args brace
Fix#102057 (see issue for example).
Previously, the use of escaped left braces (`\x7B`) in format args resulted in an incorrectly offset span. This patch fixes that by considering any escaped characters within the string instead of using a constant offset.
The Run button isn't inside the `<pre>` any more. It's instead nested below
the example wrapper.
The class name can't be removed from the DOM, because `main.js` uses it.
rustdoc: clean up "normalize.css 8" input override CSS
These rules were copied from normalize.css 3, and are mostly redundant.
* `optgroup` isn't used in rustdoc at all
* `textarea` is only used for the "copy" button, so it's not visible
* The remaining buttons and inputs mostly have styles set anyway.
* We should never be setting `color` without also setting the background to something. Otherwise, you get white-on-gray text. That seems to be [the reason] why `normalize.css` changed this.
[the reason]: https://github.com/necolas/normalize.css/pull/502
Fix associated type bindings with anon const in GAT position
The first commit formats `type_of.rs`, which is really hard to maintain since it uses a bunch of features like `let`-chains and `if let` match arm bindings. Best if you just review the second two diffs.
Fixes#102333
Enable inline stack probes on PowerPC and SystemZ
The LLVM PowerPC and SystemZ targets have both supported `"probe-stack"="inline-asm"` for longer than our current minimum LLVM 13 requirement, so we can turn this on for all `powerpc`, `powerpc64`, `powerpc64le`, and `s390x` targets in Rust. These are all tier-2 or lower, so CI does not run their tests, but I have confirmed that their `linux-gnu` variants do pass on RHEL.
cc #43241
bors
