about summary refs log tree commit diff
path: root/compiler/rustc_resolve
AgeCommit message (Collapse)AuthorLines
2025-02-24cleanup few unused argsklensy-12/+5
2025-02-23stabilize extract_ifbendn-1/+0
2025-02-22Fix binding mode problemsMichael Goulet-26/+26
2025-02-22Upgrade the compiler to edition 2024Michael Goulet-1/+1
2025-02-21Auto merge of #137397 - matthiaskrgr:rollup-ls2pilo, r=matthiaskrgrbors-2/+2
Rollup of 10 pull requests Successful merges: - #132876 (rustdoc book: acknowledge --document-hidden-items) - #136148 (Optionally add type names to `TypeId`s.) - #136609 (libcore/net: `IpAddr::as_octets()`) - #137336 (Stabilise `os_str_display`) - #137350 (Move methods from Map to TyCtxt, part 3.) - #137353 (Implement `read_buf` for WASI stdin) - #137361 (Refactor `OperandRef::extract_field` to prep for MCP838) - #137367 (Do not exempt nonexistent platforms from platform policy) - #137374 (Stacker now handles miri using a noop impl itself) - #137392 (remove few unused fields) r? `@ghost` `@rustbot` modify labels: rollup
2025-02-21convert all_macro_rules from hashmap to hashsetklensy-2/+2
2025-02-21Rollup merge of #128080 - estebank:out-of-scope-macro, r=petrochenkovMatthias Krüger-5/+21
Specify scope in `out_of_scope_macro_calls` lint ``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = 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 #124535 <https://github.com/rust-lang/rust/issues/124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ``` r? ```@petrochenkov```
2025-02-20Reword messageEsteban Küber-2/+2
2025-02-19Rollup merge of #136344 - zachs18:dot_notation_more_defkinds_3, r=davidtwcoMatthias Krüger-24/+64
Suggest replacing `.` with `::` in more error diagnostics. First commit makes the existing "help: use the path separator to refer to an item" also work when the base is a type alias, not just a trait/module/struct. The existing unconditional `DefKind::Mod | DefKind::Trait` match arm is changed to a conditional `DefKind::Mod | DefKind::Trait | DefKind::TyAlias` arm that only matches if the `path_sep` suggestion-adding closure succeeds, so as not to stop the later `DefKind::TyAlias`-specific suggestions if the path-sep suggestion does not apply. This shouldn't change behavior for `Mod` or `Trait` (due to the default arm's `return false` etc). This commit also updates `tests/ui/resolve/issue-22692.rs` to reflect this, and also renames it to something more meaningful. This commit also makes the `bad_struct_syntax_suggestion` closure take `err` as a parameter instead of capturing it, since otherwise caused borrowing errors due to the change to using `path_sep` in a pattern guard. <details> <summary> Type alias diagnostic example </summary> ```rust type S = String; fn main() { let _ = S.new; } ``` ```diff error[E0423]: expected value, found type alias `S` --> diag7.rs:4:13 | 4 | let _ = S.new; | ^ | - = note: can't use a type alias as a constructor + help: use the path separator to refer to an item + | +4 | let _ = S::new; + | ~~ ``` </details> Second commit adds some cases for `enum`s, where if there is a field/method expression where the field/method has the name of a unit/tuple variant, we assume the user intended to create that variant[^1] and suggest replacing the `.` from the field/method suggestion with a `::` path separator. If no such variant is found (or if the error is not a field/method expression), we give the existing suggestion that suggests adding `::TupleVariant(/* fields */)` after the enum. <details> <summary> Enum diagnostic example </summary> ```rust enum Foo { A(u32), B, C { x: u32 }, } fn main() { let _ = Foo.A(42); // changed let _ = Foo.B; // changed let _ = Foo.D(42); // no change let _ = Foo.D; // no change let _ = Foo(42); // no change } ``` ```diff error[E0423]: expected value, found enum `Foo` --> diag8.rs:8:13 | 8 | let _ = Foo.A(42); // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -8 | let _ = Foo::B.A(42); // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -8 | let _ = (Foo::A(/* fields */)).A(42); // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +8 | let _ = Foo::A(42); // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:9:13 | 9 | let _ = Foo.B; // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -9 | let _ = Foo::B.B; // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -9 | let _ = (Foo::A(/* fields */)).B; // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +9 | let _ = Foo::B; // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:10:13 | 10 | let _ = Foo.D(42); // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 10 | let _ = Foo::B.D(42); // no change | ~~~~~~ help: alternatively, the following enum variant is available | 10 | let _ = (Foo::A(/* fields */)).D(42); // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:11:13 | 11 | let _ = Foo.D; // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 11 | let _ = Foo::B.D; // no change | ~~~~~~ help: alternatively, the following enum variant is available | 11 | let _ = (Foo::A(/* fields */)).D; // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected function, tuple struct or tuple variant, found enum `Foo` --> diag8.rs:12:13 | 12 | let _ = Foo(42); // no change | ^^^ help: try to construct one of the enum's variants: `Foo::A` | = help: you might have meant to construct the enum's non-tuple variant note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ error: aborting due to 5 previous errors ``` </details> [^1]: or if it's a field expression and a tuple variant, that they meant to refer the variant constructor.
2025-02-19Specify scope in `out_of_scope_macro_calls` lintEsteban Küber-5/+21
``` warning: cannot find macro `in_root` in the crate root --> $DIR/key-value-expansion-scope.rs:1:10 | LL | #![doc = in_root!()] | ^^^^^^^ not found in the crate root | = 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 #124535 <https://github.com/rust-lang/rust/issues/124535> = help: import `macro_rules` with `use` to make it callable above its definition = note: `#[warn(out_of_scope_macro_calls)]` on by default ```
2025-02-18When giving a suggestion to use :: instead of . where the rhs is a macro ↵Zachary S-1/+1
giving a type, make it also work when the rhs is a type alias, not just a struct.
2025-02-18Suggest using :: instead of . for enums in some cases.Zachary S-14/+56
Suggest replacing `.` with `::` when encountering "expected value, found enum": - in a method-call expression and the method has the same name as a tuple variant - in a field-access expression and the field has the same name as a unit or tuple variant
2025-02-18Suggest using :: instead of . in more cases.Zachary S-9/+7
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just a struct, trait, or module. Also rename test for this suggestion from issue-22692.rs to something more meaningful.
2025-02-17Enforce T: Hash for Interned<...>Mark Rousskov-0/+39
This adds panicking Hash impls for several resolver types that don't actually satisfy this condition. It's not obvious to me that rustc_resolve actually upholds the Interned guarantees but fixing that seems pretty hard (the structures have at minimum some interior mutability, so it's not really recursively hashable in place...).
2025-02-15rustdoc: improve refdef handling in the unresolved link lintMichael Howell-2/+16
This commit takes advantage of a feature in pulldown-cmark that makes the list of link definitions available to the consuming application. It produces unresolved link warnings for refdefs that aren't used, and can now produce exact spans for the dest even when it has escapes.
2025-02-13Rollup merge of #136869 - chenyukang:yukang-fix-133713-let-binding, r=estebankJubilee-1/+22
Fix diagnostic when using = instead of : in let binding Fixes #133713 r? ``@estebank``
2025-02-12Rollup merge of #136646 - oli-obk:pattern-types-ast, r=BoxyUwUMatthias Krüger-0/+15
Add a TyPat in the AST to reuse the generic arg lowering logic This simplifies ast lowering significantly with little cost to the pattern types parser. Also fixes any problems we've had with generic args (well, pushes any problems onto the `generic_const_exprs` feature gate) follow-up to https://github.com/rust-lang/rust/pull/136284#discussion_r1939292367 r? ``@BoxyUwU``
2025-02-12Fix diagnostic when using = instead of : in let bindingsyukang-1/+22
2025-02-11Rollup merge of #135677 - yotamofek:resolve-cleanups2, r=compiler-errorsMatthias Krüger-7/+8
Small `rustc_resolve` cleanups 1. Don't open-code `Reverse` 2. Use slice patterns where possible
2025-02-11Add a TyPat in the AST to reuse the generic arg lowering logicOli Scherer-0/+15
2025-02-09Auto merge of #136751 - bjorn3:update_rustfmt, r=Mark-Simulacrumbors-91/+132
Update bootstrap compiler and rustfmt The rustfmt version we previously used formats things differently from what the latest nightly rustfmt does. This causes issues for subtrees that get formatted both in-tree and in their own repo. Updating the rustfmt used in-tree solves those issues. Also bumped the bootstrap compiler as the stage0 update command always updates both at the same time.
2025-02-08Rustfmtbjorn3-91/+132
2025-02-08Small resolve refactorAndre Bogus-16/+17
2025-02-06Auto merge of #136471 - safinaskar:parallel, r=SparrowLiibors-22/+23
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of https://github.com/rust-lang/rust/pull/132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
2025-02-03Express contracts as part of function header and lower it to the contract ↵Celina G. Val-2/+9
lang items includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures. includes post-developed commit: removed tabs that creeped in into rustfmt tool source code. includes post-developed commit, placating rustfmt self dogfooding. includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/ includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures). Rebase Conflicts: - compiler/rustc_parse/src/parser/diagnostics.rs - compiler/rustc_parse/src/parser/item.rs - compiler/rustc_span/src/hygiene.rs Remove contracts keywords from diagnostic messages
2025-02-03tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`Askar Safin-22/+23
2025-01-28Refactor FnKind variant to hold &FnCelina G. Val-11/+14
2025-01-27Remove redundant to_ident_string callsMichael Goulet-3/+2
2025-01-27Use identifiers in diagnostics more oftenMichael Goulet-23/+22
2025-01-25Auto merge of #133154 - estebank:issue-133137, r=wesleywiserbors-4/+32
Reword resolve errors caused by likely missing crate in dep tree Reword label and add `help`: ``` error[E0432]: unresolved import `some_novel_crate` --> f704.rs:1:5 | 1 | use some_novel_crate::Type; | ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate` | = help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml` ``` Fix #133137.
2025-01-24Reword "crate not found" resolve messageEsteban Küber-4/+32
``` error[E0432]: unresolved import `some_novel_crate` --> file.rs:1:5 | 1 | use some_novel_crate::Type; | ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate` ``` On resolve errors where there might be a missing crate, mention `cargo add foo`: ``` error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope` --> $DIR/conflicting-impl-with-err.rs:4:11 | LL | impl From<nope::Thing> for Error { | ^^^^ use of unresolved module or unlinked crate `nope` | = help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml` ```
2025-01-21rustc_resolve: don't open-code `Option::filter`Yotam Ofek-4/+1
2025-01-21rustc_resolve: use `Iterator` combinators instead of `for` loops where ↵Yotam Ofek-26/+12
applicable
2025-01-21rustc_resolve: reduce rightwards drift with `let..else` 👉💨Yotam Ofek-381/+387
2025-01-21rustc_resolve: flatten nested `if`sYotam Ofek-229/+198
2025-01-21rustc_resolve: remove unneeded `return`sYotam Ofek-2/+0
2025-01-21use slice patterns for checking for elements of sliceYotam Ofek-5/+6
2025-01-21don't use partial ordering on types that support total orderingYotam Ofek-2/+2
2025-01-20Rollup merge of #135676 - yotamofek:resolve-cleanups, r=BoxyUwU许杰友 Jieyou Xu (Joe)-24/+15
rustc_resolve: use structured fields in traces I think this crate was written before `tracing` was adopted, and was manually writing fields into trace logs instead of using structured fields. I kept function names in the trace messages even though I added `#[instrument]` invocations so that the events will be in named spans, wasn't sure if spans are always printed.
2025-01-20Auto merge of #135754 - jieyouxu:rollup-j4q1hpr, r=jieyouxubors-16/+13
Rollup of 7 pull requests Successful merges: - #135542 (Add the concrete syntax for precise capturing to 1.82 release notes.) - #135700 (Emit single privacy error for struct literal with multiple private fields and add test for `default_field_values` privacy) - #135722 (make it possible to use ci-rustc on tarball sources) - #135729 (Add debug assertions to compiler profile) - #135736 (rustdoc: Fix flaky doctest test) - #135738 (Replace usages of `map_or(bool, ...)` with `is_{some_and|none_or|ok_and}`) - #135747 (Rename FileName::QuoteExpansion to CfgSpec) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-20rustc_resolve: use structured fields in tracesYotam Ofek-24/+15
2025-01-20Rollup merge of #134276 - RalfJung:destabilize-custom-inner-attr, r=SparrowLii许杰友 Jieyou Xu (Joe)-42/+9
fully de-stabilize all custom inner attributes `#![test]` and `#![rustfmt::skip]` were accidentally accepted in more places than they should. These have been marked as soft-unstable since forever (https://github.com/rust-lang/rust/pull/82399) and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274). Cc `@rust-lang/lang` `@petrochenkov`
2025-01-19Run `clippy --fix` for `unnecessary_map_or` lintYotam Ofek-16/+13
2025-01-19fully de-stabilize all custom inner attributesRalf Jung-42/+9
2025-01-18Fix ICE in resolving associated items as non-bindingsFrank King-3/+3
2025-01-16Rollup merge of #134754 - ↵Matthias Krüger-6/+25
frank-king:feature/import_trait_associated_functions, r=oli-obk Implement `use` associated items of traits This PR implements #134691.
2025-01-16Implement `use` associated items of traitsFrank King-6/+25
2025-01-15Auto merge of #134353 - oli-obk:safe-target-feature-unsafe-by-default, ↵bors-3/+4
r=wesleywiser Treat safe target_feature functions as unsafe by default [less invasive variant] This unblocks * #134090 As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions. This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
2025-01-14Enforce syntactical stability of const traits in HIRMichael Goulet-0/+1
2025-01-14Add hir::HeaderSafety to make follow up commits simplerOli Scherer-3/+4