Rollup of 5 pull requests
Successful merges:
- #102672 (rustdoc: remove unused CSS class `in-band`)
- #102693 (Revert "Use getentropy when possible on all Apple platforms")
- #102694 (Suggest calling method if fn does not exist)
- #102708 (Suggest `==` to wrong assign expr)
- #102710 (Add test for issue 82633)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
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 😢
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.
Migrate rustc_codegen_gcc to SessionDiagnostics
As part of #100717 this pr migrates diagnostics to `SessionDiagnostics` for the `rustc_codegen_gcc` crate.
``@rustbot`` label +A-translation
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
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.
`parse_token_tree` is basically a match with four arms: `Eof`,
`OpenDelim`, `CloseDelim`, and "other". It has two call sites, and at
each call site one of the arms is unreachable. It's also not inlined.
This commit removes `parse_token_tree` by splitting it into four
functions and inlining them. This avoids some repeated conditional
tests and also some non-inlined function calls on the hot path.
FIX - ambiguous Diagnostic link in docs
UPDATE - rename diagnostic_items to IntoDiagnostic and AddToDiagnostic
[Gardening] FIX - formatting via `x fmt`
FIX - rebase conflicts. NOTE: Confirm wheather or not we want to handle TargetDataLayoutErrorsWrapper this way
DELETE - unneeded allow attributes in Handler method
FIX - broken test
FIX - Rebase conflict
UPDATE - rename residual _SessionDiagnostic and fix LintDiag link
On later stages, the feature is already stable.
Result of running:
rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#"
- ... when creating diagnostics in rustc_metadata
- use the error_code! macro
- pass macro output to diag.code()
- use fluent from within manual implementation of SessionDiagnostic
- emit the untested errors in case they occur in the wild
- stop panicking in the probably-not-dead code, add fixme to write test
Make call suggestions more general and more accurate
Cleans up some suggestions that have to do with adding `()` to make typeck happy.
1. Drive-by rename of `expr_t` to `base_ty` since it's the type of the `base_expr`
1. Autoderef until we get to a callable type in `suggest_fn_call`.
1. Don't erroneously suggest calling constructor when a method/field does not exist on it.
1. Suggest calling a method receiver if its function output has a method (e.g. `fn.method()` => `fn().method()`)
1. Extend call suggestions to type parameters, fn pointers, trait objects where possible
1. Suggest calling in operators too (fixes#101054)
1. Use `/* {ty} */` as argument placeholder instead of just `_`, which is confusing and makes suggestions look less like `if let` syntax.
