about summary refs log tree commit diff
path: root/src/test/ui/resolve
AgeCommit message (Collapse)AuthorLines
2021-03-20Move some tests to more reasonable directories - 5Caio-0/+83
2021-03-07diagnostics: Differentiate between edition meanings of ::foo in resolve ↵Manish Goregaokar-3/+3
diagnostics for ::foo::Bar
2021-03-06Move some tests to more suitable subdirsYuki Okushi-0/+22
2021-02-24clarifies error when finding mismatched returned types for async functionsNell Shamrell-1/+2
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
2021-02-18Fix popping singleton paths in when generating E0433Ömer Sinan Ağacan-0/+12
Fixes #82156
2021-01-31Move some tests to more reasonable directoriesCaio-0/+21
2021-01-18Add tests for resolution changesRyan Levick-0/+30
2021-01-13Auto merge of #77524 - Patryk27:fixes/66228, r=estebankbors-0/+6
Rework diagnostics for wrong number of generic args (fixes #66228 and #71924) This PR reworks the `wrong number of {} arguments` message, so that it provides more details and contextual hints.
2021-01-11Move some tests to more reasonable directoriesCaio-0/+21
2021-01-10Rework diagnostics for wrong number of generic argsPatryk Wychowaniec-0/+6
2020-12-26update testsBastian Kauschke-1/+0
2020-12-07Move some tests to subdirectoriesVadim Petrochenkov-0/+104
2020-11-24Auto merge of #79294 - petrochenkov:determ, r=varkorbors-0/+7
resolve: Do not put macros into `module.unexpanded_invocations` unless necessary Macro invocations in modules <sup>(*)</sup> need to be tracked because they can produce named items when expanded. We cannot give definite answer to queries like "does this module declare name `n`?" until all macro calls in that module are expanded. Previously we marked too many macros as potentially producing named items. E.g. in this example ```rust mod m { const C: u32 = line!(); } ``` `line!()` cannot emit any items into module `m`, but it was still marked. This PR fixes that and marks macro calls as "unexpanded in module" only if they can actually emit named items into that module. Diagnostics in UI test outputs have different order now because this change affects macro expansion order. <sup>*</sup> Any containers for named items are called modules in resolve (that includes blocks, traits and enums in addition to `mod` items).
2020-11-22Drop support for cloudabi targetsLzu Tao-10/+6
2020-11-22resolve: Do not put macros into `module.unexpanded_invocations` unless necessaryVadim Petrochenkov-11/+3
2020-11-22Add test for an unmotivated "cannot determine resolution" errorVadim Petrochenkov-0/+15
2020-11-01Auto merge of #78420 - estebank:suggest-assoc-fn, r=petrochenkovbors-21/+68
Suggest calling associated `fn` inside `trait`s When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
2020-10-27Add unsized_fn_params featureSantiago Pastorino-3/+3
2020-10-26Suggest calling associated `fn` inside `trait`sEsteban Küber-21/+68
When calling a function that doesn't exist inside of a trait's associated `fn`, and another associated `fn` in that trait has that name, suggest calling it with the appropriate fully-qualified path. Expand the label to be more descriptive. Prompted by the following user experience: https://users.rust-lang.org/t/cannot-find-function/50663
2020-10-20review commentsEsteban Küber-1/+1
2020-10-20Tweak "object unsafe" errorsEsteban Küber-3/+4
Fix #77598.
2020-10-17Rollup merge of #77925 - JohnTitor:sugg-min-features, r=davidtwco,oli-obkYuki Okushi-0/+1
Suggest minimal subset features in `incomplete_features` lint This tells users that we have a minimal subset feature of it and they can fix the lint warning without allowing it. The wording improvement is helpful :) Fixes #77913
2020-10-17Suggest minimal subset features in `incomplete_features` lintYuki Okushi-0/+1
2020-10-15resolve: suggest variants with placeholdersDavid Wood-10/+102
This commit improves the diagnostic modified in rust-lang/rust#77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). Signed-off-by: David Wood <david@davidtw.co>
2020-10-07Auto merge of #77341 - davidtwco:issue-73427-you-might-have-meant-variant, ↵bors-35/+8
r=estebank resolve: improve "try using the enum's variant" Fixes #73427. This PR improves the "try using the enum's variant" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. All of the diagnostic logic introduced by this PR is separated from the normal code path for a successful compilation. r? `@estebank`
2020-10-02Fix span for incorrect pattern field and add labelEsteban Küber-2/+4
2020-09-29resolve: improve "try using the enum's variant"David Wood-35/+8
This commit improves the "try using the enum's variant" suggestion: - Variants in suggestions would not result in more errors (e.g. use of a struct variant is only suggested if the suggestion can trivially construct that variant). Therefore, suggestions are only emitted for variants that have no fields (since the suggestion can't know what value fields would have). - Suggestions include the syntax for constructing the variant. If a struct or tuple variant is suggested, then it is constructed in the suggestion - unless in pattern-matching or when arguments are already provided. - A help message is added which mentions the variants which are no longer suggested. Signed-off-by: David Wood <david@davidtw.co>
2020-09-09Rollup merge of #75984 - kornelski:typeormodule, r=matthewjasperTyler Mandry-3/+3
Improve unresolved use error message "use of undeclared type or module `foo`" doesn't mention that it could be a crate. This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate. I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
2020-09-02pretty: trim paths of unique symbolsDan Aloni-16/+16
If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-01Clarify message about unresolved useKornel-3/+3
2020-08-13Suggest adding `&self` when accessing `self` in static assoc `fn`Esteban Küber-14/+13
2020-08-10Add missing primary labelEsteban Küber-1/+1
2020-08-10Point at item definition in foreign cratesEsteban Küber-0/+5
2020-08-10Do not suggest similarly named enclosing itemEsteban Küber-7/+0
2020-08-10Tweak ordering of suggestionsEsteban Küber-20/+20
Modify logic to make it easier to follow and recover labels that would otherwise be lost.
2020-07-27mv std libs to library/mark-1/+1
2020-07-14Rollup merge of #74228 - estebank:unsized-param, r=davidtwcoManish Goregaokar-2/+4
Provide structured suggestion on unsized fields and fn params * Suggest borrowing or boxing unsized fields * Suggest borrowing fn parameters * Remove some verbosity of unsized errors * Remove `on_unimplemented` note from `trait Sized` Fix #23286, fix #28653. r? @davidtwco
2020-07-14Suggest borrowing in more unsized fn param casesEsteban Küber-1/+4
2020-07-14Remove `Sized` `on_unimplemented` noteEsteban Küber-1/+0
2020-07-14Suggest struct pat on incorrect unit or tuple patEsteban Küber-12/+18
When encountering a unit or tuple pattern for a struct-like item, suggest using the correct pattern. Use `insert_field_names_local` when evaluating variants and store field names even when the list is empty in order to produce accurate structured suggestions.
2020-07-06Rollup merge of #73953 - JohnTitor:audit-hidden-sugg, r=estebankManish Goregaokar-1/+49
Audit hidden/short code suggestions Should fix #73641. Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes. r? @estebank
2020-07-02resolve: disallow label use through closure/asyncDavid Wood-4/+9
This commit modifies resolve to disallow `break`/`continue` to labels through closures or async blocks. This doesn't make sense and should have been prohibited anyway. Signed-off-by: David Wood <david@davidtw.co>
2020-07-02Audit uses of `tool_only_span_suggestion`Yuki Okushi-1/+13
2020-07-02Audit uses of `span_suggestion_short`Yuki Okushi-0/+36
2020-06-23Add re-exports to use suggestionsDan Aloni-5/+7
In the following example, an inaccessible path is suggested via `use foo::bar::X;` whereas an accessible public exported path can be suggested instead. ``` mod foo { mod bar { pub struct X; } pub use self::bar::X; } fn main() { X; } ``` This fixes the issue.
2020-06-21Prefer accessible paths in 'use' suggestionsDan Aloni-4/+1
This fixes an issue with the following sample: mod foo { mod inaccessible { pub struct X; } pub mod avail { pub struct X; } } fn main() { X; } Instead of suggesting both `use crate::foo::inaccessible::X;` and `use crate::foo::avail::X;`, it should only suggest the latter. It is done by trimming the list of suggestions from inaccessible paths if accessible paths are present. Visibility is checked with `is_accessible_from` now instead of being hard-coded. - Some tests fixes are trivial, and others require a bit more explaining, here are my comments: src/test/ui/issues/issue-35675.stderr: Only needs to make the enum public to have the suggestion make sense. src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't help because its constructor is not visible, so the attempted constructor does not work. In that case, it's better not to suggest it. The case where the constructor is public is covered in `issue-26545.rs`.
2020-06-09Remove noisy suggestion of hash_map #72642Ayush Kumar Mishra-9/+3
Fixed failing test-cases Remove noisy suggestion of hash_map #72642 Fixed failing test-cases
2020-06-07Free `default()` forwarding to `Default::default()`Ilya Bobyr-1/+10
When creating default values a trait method needs to be called with an explicit trait name. `Default::default()` seems redundant. A free function on the other hand, when imported directly, seems to be a better API, as it is just `default()`. When implementing the trait, a method is still required.
2020-06-02Improve E0433, so that it suggests missing importsPatryk Wychowaniec-0/+49
2020-05-31Add descriptions for all queriesMatthew Jasper-12/+12
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 05:03:44 +0000