about summary refs log tree commit diff
path: root/tests/ui/resolve
AgeCommit message (Collapse)AuthorLines
2025-03-29rustc_resolve: Test the order that preludes are resolvedjyn-0/+152
2025-03-25compiletest: Support matching on diagnostics without a spanVadim Petrochenkov-0/+2
2025-03-22Note potential but private items in show_candidatesxizheyin-0/+11
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-03-14Do not suggest using `-Zmacro-backtrace` for builtin macrosEsteban Küber-4/+4
For macros that are implemented on the compiler, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros.
2025-02-21Trim suggestion part before generating highlightsMichael Goulet-1/+1
2025-02-21More sophisticated span trimmingMichael Goulet-5/+3
2025-02-18Update `.` -> `::` tests for new diff suggestion format.Zachary S-46/+64
2025-02-18When giving a suggestion to use :: instead of . where the rhs is a macro ↵Zachary S-3/+136
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-0/+283
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/+62
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-14Trim suggestion parts to the subset that is purely additiveMichael Goulet-17/+17
2025-02-14Consider add-prefix replacements tooMichael Goulet-9/+6
2025-02-14Use underline suggestions for purely 'additive' replacementsMichael Goulet-42/+28
2025-02-10Show diff suggestion format on verbose replacementEsteban Küber-172/+260
``` error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields --> $DIR/attempted-access-non-fatal.rs:7:15 | LL | let _ = 2.l; | ^ | help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix | LL - let _ = 2.l; LL + let _ = 2.0f64; | ```
2025-01-26Compiler: Finalize dyn compatibility renamingLeón Orell Valerian Liehr-1/+1
2025-01-25Auto merge of #133154 - estebank:issue-133137, r=wesleywiserbors-52/+67
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-52/+67
``` 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-22Auto merge of #135896 - matthiaskrgr:rollup-g6rv7za, r=matthiaskrgrbors-2/+2
Rollup of 9 pull requests Successful merges: - #132983 (Edit dangling pointers ) - #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block) - #135557 (Point at invalid utf-8 span on user's source code) - #135596 (Properly note when query stack is being cut off) - #135794 (Detect missing fields with default values and suggest `..`) - #135814 (ci: use ghcr buildkit image) - #135826 (Misc. `rustc_resolve` cleanups) - #135837 (Remove test panic from File::open) - #135856 (Library: Finalize dyn compatibility renaming) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-22Rollup merge of #135596 - compiler-errors:stack, r=oli-obkMatthias Krüger-2/+2
Properly note when query stack is being cut off cc #70953 also, i'm not certain whether we should even limit this at all. i don't see the problem with printing the full query stack, apparently it was limited b/c we used to ICE? but we're already printing the full stack to disk since #108714. r? oli-obk
2025-01-22Refactor dyn-compatibility error and suggestionsTaylor Cramer-4/+5
This CL makes a number of small changes to dyn compatibility errors: - "object safety" has been renamed to "dyn-compatibility" throughout - "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait` - Several error messages are reorganized for user readability Additionally, the dyn compatibility error creation code has been split out into functions. cc #132713 cc #133267
2025-01-21add test for issue 135289Rémy Rakic-0/+30
2025-01-18Fix ICE in resolving associated items as non-bindingsFrank King-0/+107
2025-01-16Properly note when query stack is being cut offMichael Goulet-2/+2
2025-01-01Try to write the panic message with a single `write_all` callJohn Kåre Alsaker-2/+4
2024-12-27Remove the `-test` suffix from normalize directivesZalathar-6/+6
2024-12-23Note def descr in NonConstFunctionCallMichael Goulet-2/+2
2024-12-17Adjust `tests/ui/attrs-resolution.rs`许杰友 Jieyou Xu (Joe)-0/+45
- Move `tests/ui/attrs-resolution.rs` to `tests/ui/resolve/`. - Document test intent. - Rename test to `non-macro-attrs-accepted.rs` to better reflect test intent.
2024-12-17Adjust `tests/ui/attrs-resolution-errors.rs`许杰友 Jieyou Xu (Joe)-0/+81
- Move `tests/ui/attrs-resolution-errors.rs` to `tests/ui/resolve/`. - Document test intent. - Rename test to `attr-macros-positional-rejection.rs` to better reflect test intent.
2024-12-10Silence `use foo::Bar;` error if `Bar` isn't found in `foo` and `foo.rs` has ↵Esteban Küber-10/+3
parse errors
2024-12-10Keep track of parse errors in `mod`s and don't emit resolve errors for paths ↵Esteban Küber-9/+3
involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion. Fix #97734.
2024-12-10Add test for resolve errors caused by mod with parse errorsEsteban Küber-0/+60
2024-12-10Rollup merge of #134010 - RalfJung:promoted-type-error-ice, r=oli-obkLeón Orell Valerian Liehr-34/+0
fix ICE on type error in promoted Fixes https://github.com/rust-lang/rust/issues/133968 Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
2024-12-09fix ICE on type error in promotedRalf Jung-34/+0
2024-12-07reword trait bound suggestion message to include the boundsEsteban Küber-1/+1
2024-12-01fix ICE when promoted has layout size overflowRalf Jung-0/+34
2024-11-27Update tests to use new proc-macro headerEric Huss-12/+3
2024-11-26tests: remove `//@ pretty-expanded` usages许杰友 Jieyou Xu (Joe)-2/+0
Done with ```bash sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs ``` and ``` sd '//@pretty-expanded.*\n' '' tests/ui/**/*.rs ```
2024-11-23Update tests for new TRPL chapter orderChris Krycho-1/+1
2024-11-20Detect const in pattern with typoEsteban Küber-0/+123
When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s. ``` error: unreachable pattern --> $DIR/const-with-typo-in-pattern-binding.rs:30:9 | LL | GOOOD => {} | ----- matches any value LL | LL | _ => {} | ^ no value can reach this | help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding | LL | GOOD => {} | ~~~~ ``` Fix #132582.
2024-11-08use verbose for path separator suggestionMichael Goulet-17/+97
2024-11-03Properly suggest `E::assoc` when we encounter `E::Variant::assoc`Esteban Küber-5/+1
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code. Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
2024-10-26Deny calls to non-`#[const_trait]` methods in MIR constckDeadbeef-8/+0
2024-10-11Don't assume traits used as type are trait objsVulnBandit-32/+10
2024-10-06On function and method calls in patterns, link to the bookEsteban Küber-2/+4
``` error: expected a pattern, found an expression --> f889.rs:3:13 | 3 | let (x, y.drop()) = (1, 2); //~ ERROR | ^^^^^^^^ not a pattern | = note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html> error[E0532]: expected a pattern, found a function call --> f889.rs:2:13 | 2 | let (x, drop(y)) = (1, 2); //~ ERROR | ^^^^ not a tuple struct or tuple variant | = note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html> ``` Fix #97200.
2024-09-27Rollup merge of #130826 - fmease:compiler-mv-obj-safe-dyn-compat, ↵Matthias Krüger-1/+1
r=compiler-errors Compiler: Rename "object safe" to "dyn compatible" Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118. Tracking issue: https://github.com/rust-lang/rust/issues/130852 Excludes `compiler/rustc_codegen_cranelift` (to be filed separately). Includes Stable MIR. Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language). r? ghost
2024-09-27On implicit `Sized` bound on fn argument, point at type instead of patternEsteban Küber-4/+4
Instead of ``` error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time --> $DIR/issue-59324.rs:23:20 | LL | fn with_factory<H>(factory: dyn ThriftService<()>) {} | ^^^^^^^ doesn't have a size known at compile-time ``` output ``` error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time --> $DIR/issue-59324.rs:23:29 | LL | fn with_factory<H>(factory: dyn ThriftService<()>) {} | ^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time ```
2024-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-1/+1
2024-09-07Don't call fn_arg_names for non-fn in resolverMichael Goulet-0/+28
2024-08-19Don't consider RibKind::Module's bindings when checking generics shadowingMichael Goulet-0/+8
2024-07-29Structured suggestion for `extern crate foo` when `foo` isn't resolved in importEsteban Küber-7/+28
When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate. When encountering `_` in an import, do not suggest `extern crate _;`. ``` error[E0432]: unresolved import `spam` --> $DIR/import-from-missing-star-3.rs:2:9 | LL | use spam::*; | ^^^^ maybe a missing crate `spam`? | help: consider importing the `spam` crate | LL + extern crate spam; | ```