Clean up `ty::Dynamic`
1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely.
2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait`
* `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types
* `lint` contained dyn-Trait-specific diagnostics+lints only
Keep space if arg does not follow punctuation when lint unused parens
Fixesrust-lang/rust#138234
If the arg follows punctuation, still pass `left_pos` with `None` and no space will be added, else then pass `left_pos` with `Some(arg.span.lo())`, so that we can add the space as expected.
And `emit_unused_delims` can make sure no more space will be added if the expr follows space.
---
Edited:
Directly use the `value_span` to check whether the expr removed parens will follow identifier or be followed by identifier.
No changes should be visible by rustc users
This is just some architecture changes to the type checking to
facilitate FFI-safety decisions that depend on how the type is used
(the change here is not complete, there are still bits of "legacy" state
passing for this, but since this is a retconned commit, I can tell you
those bits will disappear before the end of the commit chain)
(there is at least one bit where the decision making code is weird, but
that this is because we do not want to change the lint's behaviour this
early in the chain)
no visible changes to rust users, just making the inner architecture of
the ImproperCTypes lints more sensible, with a clean separation between
the struct (now singular) that interacts with the linting system
and the struct (now singular) that visits the types to check FFI-safety
Mainly, we realise that the non-null assumption on a Box<_> argument
does not depend on what side of the FFI boundary the function is on.
And anyway, this is not the way to deal with this assumption being maybe violated.
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`
Fixes https://github.com/rust-lang/rust/issues/145772
This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today.
This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy.
cc ```@shepmaster```
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
This variant doesn't appear to have ever been used.
There's a matching message in `rustc_resolve`, that used to have a FIXME
for porting it to the new diagnostic infrastructure, but that message is
using `feature_err`, which doesn't use buffered lints. Thus, even when
that does get ported, it won't use `BuiltinLintDiag`.
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
`rustc_lint_defs` uses `rustc_hir` solely for the `Namespace` type,
which it only needs the static description from. Use the static
description directly, to eliminate the dependency on `rustc_hir`.
This reduces a long dependency chain:
- Many things depend on `rustc_errors`
- `rustc_errors` depends on `rustc_lint_defs`
- `rustc_lint_defs` depended on `rustc_hir` prior to this commit
- `rustc_hir` depends on `rustc_target`
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
Couple of codegen_fn_attrs improvements
As noted in https://github.com/rust-lang/rust/pull/144678#discussion_r2245060329 here is no need to keep link_name and export_name separate, which the third commit fixes by merging them. The second commit removes some dead code and the first commit merges two ifs with equivalent conditions. The last commit is an unrelated change which removes an unused `feature(autodiff)`.
Extend `QueryStability` to handle `IntoIterator` implementations
This PR extends the `rustc::potential_query_instability` lint to check values passed as `IntoIterator` implementations.
Full disclosure: I want the lint to warn about this line (please see #138871 for why): aa8f0fd716/src/librustdoc/json/mod.rs (L261)
However, the lint warns about several other lines as well.
Final note: the functions `get_callee_generic_args_and_args` and `get_input_traits_and_projections` were copied directly from [Clippy's source code](4fd8c04da0/src/tools/clippy/clippy_lints/src/methods/unnecessary_to_owned.rs (L445-L496)).
Print regions in `type_name`.
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions.
Fixesrust-lang/rust#145168.
r? `@lcnr`
Fix adjacent code
Fix duplicate warning; merge test into `tests/ui-fulldeps/internal-lints`
Use `rustc_middle::ty::FnSig::inputs`
Address two review comments
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109006991
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109058588
Use `Instance::try_resolve`
Import `rustc_middle::ty::Ty` as `Ty` rather than `MiddleTy`
Simplify predicate handling
Add more `#[allow(rustc::potential_query_instability)]` following rebase
Remove two `#[allow(rustc::potential_query_instability)]` following rebase
Address review comment
Update compiler/rustc_lint/src/internal.rs
Co-authored-by: lcnr <rust@lcnr.de>
Currently they are skipped, which is a bit weird, and it sometimes
causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`.
Most regions are erased by the time `type_name` does its work. So all
regions are now printed as `'_` in non-optional places. Not perfect, but
better than the status quo.
`c_name` is updated to trim lifetimes from MIR pass names, so that the
`PASS_NAMES` sanity check still works. It is also renamed as
`simplify_pass_type_name` and made non-const, because it doesn't need
to be const and the non-const implementation is much shorter.
The commit also renames `should_print_region` as
`should_print_optional_region`, which makes it clearer that it only
applies to some regions.
Fixes#145168.
Handle macros with multiple kinds, and improve errors
(I recommend reviewing this commit-by-commit.)
Switch to a bitflags `MacroKinds` to support macros with more than one kind
Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`.
Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds.
This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`.
Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes.
This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules.
Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors.
This also handles cases of forward-referenced attributes and cyclic attributes.
----
In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds.
rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that.
----
r? ````````@petrochenkov````````
