Resolve refactor: extraction of `finalize_module_binding` and `single_import_can_define_name`
This pr the work Vadim asked for in https://github.com/rust-lang/rust/pull/142547#issuecomment-3001339385. This part:
> finalize_module_binding/single_import_can_define_name extraction
Cherry-picked commits of b-naber. Extraction of 2 processes in `resolve_ident_in_module_unadjusted`:
- `finalize_module_binding`
- `single_import_can_define_name`
r? ```@petrochenkov```
Remove false label when `self` resolve failure does not relate to macro
Fixesrust-lang/rust#143134
In the first commit, I did some code-clean, moving `suggest*` to `suggestions/` dir.
In the second, commit, I added ui test.
In the third, I change the code, and present the test result.
r? compiler
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
Fix some comments and related types and locals where it is obvious, e.g.
- bare_fn -> fn_ptr
- LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
The MBE parser checks rules at initial parse time to see if their RHS
has `compile_error!` in it, and returns a list of rule indexes and LHS
spans that don't map to `compile_error!`, for use in unused macro rule
checking.
Instead, have the unused macro rule reporting ask the macro for the rule
to report, and let the macro check at that time. That avoids checking
rules unless they're unused.
In the process, refactor the data structure used to store macro rules,
to group the LHS and RHS (and LHS span) of each rule together, and
refactor the unused rule tracking to only track rule indexes.
This ends up being a net simplification, and reduction in code size.
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#131923 (Derive `Copy` and `Hash` for `IntErrorKind`)
- rust-lang/rust#138340 (Remove some unsized tuple impls now that we don't support unsizing tuples anymore)
- rust-lang/rust#141219 (Change `{Box,Arc,Rc,Weak}::into_raw` to only work with `A = Global`)
- rust-lang/rust#142212 (bootstrap: validate `rust.codegen-backends` & `target.<triple>.codegen-backends`)
- rust-lang/rust#142237 (Detect more cases of unused_parens around types)
- rust-lang/rust#142964 (Attribute rework: a parser for single attributes without arguments)
- rust-lang/rust#143070 (Rewrite `macro_rules!` parser to not use the MBE engine itself)
- rust-lang/rust#143235 (Assemble const bounds via normal item bounds in old solver too)
- rust-lang/rust#143261 (Feed `explicit_predicates_of` instead of `predicates_of`)
- rust-lang/rust#143276 (loop match: handle opaque patterns)
- rust-lang/rust#143306 (Add `track_caller` attributes to trace origin of Clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
suggest declaring modules when file found but module not defined
suggests declaring modules when a module is found but not defined, i.e
```
├── main.rs: `use thing::thang;`
└── thing.rs: `struct thang`
```
or
```
├── main.rs: `use thing::thang;`
└── thing
└── mod.rs: `struct thang`
```
which currently is just
```rust
error[E0432]: unresolved import `yeah`
--> src/main.rs:1:1
|
1 | use thing::thang;
| ^^^^^ use of unresolved module or unlinked crate `thing`
|
```
but now would have this nice help:
```text
= help: you may have forgotten to declare the module `thing`. use `mod thing` in this file to declare this module.
```
Make missing lifetime suggestion verbose
I keep seeing this suggestion when working on rustc, and it's annoying that it's inline. Part of https://github.com/rust-lang/rust/issues/141973. Feel free to close this if there's another PR already doing this.
r? ``@estebank``
Don't give APITs names with macro expansion placeholder fragments in it
The `DefCollector` previously called `pprust::ty_to_string` to construct a name for APITs (arg-position impl traits). The `ast::Ty` that was being formatted however has already had its macro calls replaced with "placeholder fragments", which end up rendering like `!()` (or ICEing, in the case of rust-lang/rust#140333, since it led to a placeholder struct field with no name).
Instead, collect the name of the APIT *before* we visit its macros and replace them with placeholders in the macro expander. This makes the implementation a bit more involved, but AFAICT there's no better way to do this since we can't do a reverse mapping from placeholder fragment -> original macro call AST.
Fixesrust-lang/rust#140333
[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion
Fixes https://github.com/rust-lang/rust/issues/141553.
The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.
r? ```@Manishearth```
Add runtime check to avoid overwrite arg in `Diag`
## Origin PR description
At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it.
For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error
```
arg `instance`already exists.
```
This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure:
1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~
2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~
## Final Decision
After trying and discussing, we made a final decision.
For `#[derive(Subdiagnostic)]`, This PR made two changes:
1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`.
2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
Emit a single error when importing a path with `_`
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
Fixrust-lang/rust#142662.
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
completely deduplicate `Visitor` and `MutVisitor`
r? oli-obk
This closesrust-lang/rust#127615.
### Discussion
> * Give every `MutVisitor::visit_*` method a corresponding `flat_map_*` method.
Not every AST node exists in a location where they can be mapped to multiple instances of themselves. Not every AST node exists in a location where they can be removed from existence (e.g. `filter_map_expr`). I don't think this is doable.
> * Give every `MutVisitor::visit_*` method a corresponding `Visitor` method and vice versa
The only three remaining method-level asymmetries after this PR are `visit_stmt` and `visit_nested_use_tree` (only on `Visitor`) and `visit_span` (only on `MutVisitor`).
`visit_stmt` doesn't seem applicable to `MutVisitor` because `walk_flat_map_stmt_kind` will ask `flat_map_item` / `filter_map_expr` to potentially turn a single `Stmt` to multiple based on what a visitor wants. So only using `flat_map_stmt` seems appropriate.
`visit_nested_use_tree` is used for `rustc_resolve` to track stuff. Not useful for `MutVisitor` for now.
`visit_span` is currently not used for `MutVisitor` already, it was just kept in case we want to revive rust-lang/rust#127241. cc `@cjgillot` maybe we could remove for now and re-insert later if we find a use-case? It does involve some extra effort to maintain.
* Remaining FIXMEs
`visit_lifetime` has an extra param for `Visitor` that's not in `MutVisitor`. This is again something only used by `rustc_resolve`. I think we can keep that symmetry for now.
Adjust `with_generic_param_rib`.
Currently all of its call sites construct a `LifetimeRibKind::Generics` value, which `with_generic_param_rib` then deconstructs (and panics if it's a different `LifetimeRibKind` variant).
This commit makes the code simpler and shorter: the call sites just pass in the three values and `with_generic_param_rib` constructs the `LifetimeRibKind::Generics` value from them.
r? `@petrochenkov`
Currently all of its call sites construct a `LifetimeRibKind::Generics`
value, which `with_generic_param_rib` then deconstructs (and panics if
it's a different `LifetimeRibKind` variant).
This commit makes the code simpler and shorter: the call sites just pass
in the three values and `with_generic_param_rib` constructs the
`LifetimeRibKind::Generics` value from them.
It currently has two, which don't accurately capture what's happening --
the `TupleStruct` spans are allocated in `ResolverArenas`, which is
different to where the `Expr` is allocated -- and require some
"outlives" constraints to be used.
This commit adds another lifetime, renames the existing ones, and
removes the "outlives" constraints.
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](af945cb86e).
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#134536 (Lint on fn pointers comparisons in external macros)
- rust-lang/rust#141069 (Suggest mut when possbile for temporary value dropped while borrowed)
- rust-lang/rust#141934 (resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes)
- rust-lang/rust#142034 (Detect method not being present that is present in other tuple types)
- rust-lang/rust#142402 (chore(doctest): Remove redundant blank lines)
- rust-lang/rust#142406 (Note when enum variants shadow an associated function)
- rust-lang/rust#142407 (Remove bootstrap adhoc group)
- rust-lang/rust#142408 (Add myself (WaffleLapkin) to review rotation)
- rust-lang/rust#142418 (Remove lower_arg_ty as all callers were passing `None`)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error: cannot find attribute `empty_helper` in this scope
--> $DIR/derive-helper-legacy-limits.rs:17:3
|
LL | #[empty_helper]
| ^^^^^^^^^^^^
|
help: `empty_helper` is an attribute that can be used by the derive macro `Empty`, you might be missing a `derive` attribute
|
LL + #[derive(Empty)]
LL | struct S2;
|
```
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> src/main.rs:18:7
|
18 | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Serialize` and `Deserialize` accept the similarly named `serde` attribute
|
18 | #[serde(untagged)]
| ~~~~~
error: cannot find attribute `serde` in this scope
--> src/main.rs:12:7
|
12 | #[serde(untagged)]
| ^^^^^
|
= note: `serde` is in scope, but it is a crate, not an attribute
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
10 | #[derive(Serialize, Deserialize)]
|
```
resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes
Unblocks https://github.com/rust-lang/rust/pull/139493.
Zulip thread requesting help - [#t-compiler/help > Help requested for effects of #139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911).
This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from https://github.com/rust-lang/rust/pull/139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`.
This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected.
(The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
