summary refs log tree commit diff
path: root/src/test/ui/methods
AgeCommit message (Collapse)AuthorLines
2020-03-08Rollup merge of #69422 - JohnTitor:remove-unwrap, r=XanewokMazdak Farrokhzad-0/+43
Remove use of `unwrap()` from save-analysis Fix #69409, fix #69416
2020-02-28Do not suggest implementing traits if present in predicatesEsteban Küber-3/+2
2020-02-28Review comments: split requirement text to multiple lines for readabilityEsteban Küber-1/+2
2020-02-28Show information of chain of bound obligationsEsteban Küber-1/+1
When the obligation that couldn't be fulfilled is specific to a nested obligation, maintain both the nested and parent obligations around for more accurate and detailed error reporting.
2020-02-28Track all predicates in errors, not just trait obligationsEsteban Küber-1/+3
Surface associated type projection bounds that could not be fulfilled in E0599 errors. Always present the list of unfulfilled trait bounds, regardless of whether we're pointing at the ADT or trait that didn't satisfy it.
2020-02-28Deduplicate information in E0599Esteban Küber-3/+1
2020-02-28Reduce vebosity of E0599Esteban Küber-1/+0
2020-02-28Add more context to E0599 errorsEsteban Küber-2/+6
Point at the intermediary unfullfilled trait bounds.
2020-02-25Tweak testsYuki Okushi-0/+43
2020-02-11On mismatched argument count point at argumentsEsteban Küber-14/+33
2020-02-06rustc_macros: don't limit the -Zmacro-backtrace suggestion to extern macros.Eduard-Mihai Burtescu-2/+0
2020-02-06rustc: rename -Zexternal-macro-backtrace to -Zmacro-backtrace.Eduard-Mihai Burtescu-1/+1
2020-01-24Normalise notes with the/isvarkor-2/+2
2020-01-19When encountering an undefined named lifetime, point to where it can beEsteban Küber-0/+2
This doesn't mention that using an existing lifetime is possible, but that would hopefully be clear as always being an option. The intention of this is to teach newcomers what the lifetime syntax is.
2020-01-08Unify output of "variant not found" errorsEsteban Küber-2/+2
2019-12-20Rollup merge of #67127 - estebank:disambiguate-suggestion, r=varkorMazdak Farrokhzad-13/+52
Use structured suggestion for disambiguating method calls Fix #65635.
2019-12-11review commentsEsteban Küber-4/+4
2019-12-11Use structured suggestion for disambiguating method callsEsteban Küber-13/+52
Fix #65635.
2019-12-11Add more context for type parametersEsteban Küber-1/+1
2019-11-21Point at type in `let` assignment on type errorsEsteban Küber-6/+18
2019-11-18Surround types with backticks in type errorsEsteban Küber-13/+13
2019-11-18Remove E0308 note when primary label has all infoEsteban Küber-21/+1
2019-11-18review comments: tweak prefix stringsEsteban Küber-10/+10
2019-11-18Specific labels when referring to "expected" and "found" typesEsteban Küber-8/+8
2019-10-28Improve the "try using a variant of the expected type" hint.Patryk Wychowaniec-12/+12
2019-10-27Point at local similarly named element and tweak references to variantsEsteban Küber-15/+15
Point at the span for the definition of ADTs internal to the current crate. Look at the leading char of the ident to determine whether we're expecting a likely fn or any of a fn, a tuple struct or a tuple variant. Turn fn `add_typo_suggestion` into a `Resolver` method.
2019-10-24Increase spacing for suggestions in diagnosticsEsteban Küber-0/+4
Make the spacing between the code snippet and verbose structured suggestions consistent with note and help messages.
2019-09-29Rollup merge of #64735 - GuillaumeGomez:long-err-explanation-E0533, r=CentrilMazdak Farrokhzad-1/+26
Add long error explanation for E0533 Part of https://github.com/rust-lang/rust/issues/61137
2019-09-25Update ui testsGuillaume Gomez-1/+26
2019-09-24Remove blanket silencing of "type annotation needed" errorsEsteban Küber-1/+1
Remove blanket check for existence of other errors before emitting "type annotation needed" errors, and add some eager checks to avoid adding obligations when they refer to types that reference `[type error]` in order to reduce unneded errors.
2019-09-08Give method not found a primary span labelEsteban Küber-1/+1
2019-08-16Remove meaningless comments in src/testsd234678-9/+0
2019-07-27tests: Move run-pass tests without naming conflicts to uiVadim Petrochenkov-0/+733
2019-07-24Adjust tests for method disambiguation helpIlija Tovilo-0/+6
2019-07-24Add method disambiguation help for trait implementationIlija Tovilo-0/+76
Closes #51046 Closes #40471
2019-07-03Migrate compile-pass annotations to build-passYuki Okushi-2/+2
2019-06-01review comment: tweak wordingEsteban Küber-3/+3
2019-05-31Tweak wordingEsteban Küber-1/+1
2019-05-31On type inference errors use the type argument name when possibleEsteban Küber-2/+2
``` error[E0282]: type annotations needed in `std::result::Result<i32, E>` --> file7.rs:3:13 | 3 | let b = Ok(4); | - ^^ cannot infer type for `E` in `std::result::Result<i32, E>` | | | consider giving `b` a type` ```
2019-05-31Alternative wording for inference failureEsteban Küber-3/+3
2019-05-31Add more detail to type inference errorEsteban Küber-3/+3
When encountering code where type inference fails, add more actionable information: ``` fn main() { let foo = Vec::new(); } ``` ``` error[E0282]: type annotations needed for `std::vec::Vec<_>` --> $DIR/vector-no-ann.rs:2:16 | LL | let foo = Vec::new(); | --- ^^^^^^^^ cannot infer type for `T` | | | consider giving `foo` the type `std::vec::Vec<_>` with the type parameter `T` specified ``` We still need to modify type printing to optionally accept a `TypeVariableTable` in order to properly print `std::vec::Vec<T>`. CC #25633.
2019-05-29Update ui test suite to use dynmemoryruins-2/+2
2019-05-03Reword casting messageEsteban Küber-1/+1
2019-04-29Suggest try_into when possibleEsteban Küber-0/+4
2019-04-22update tests for migrate mode by defaultMatthew Jasper-35/+9
2019-04-18hide `--explain` hint if error has no extended infoAndy Russell-6/+5
2019-03-11Update NLL testsVadim Petrochenkov-2/+2
2019-03-11Update testsVadim Petrochenkov-23/+23
2019-01-29add tests to a few edge cases in method lookupAriel Ben-Yehuda-0/+290
These aren't fixed by this PR, but were broken in a few older attempts at it. Make sure they don't regress.
2019-01-06Auto merge of #57291 - euclio:method-call-suggestion, r=estebankbors-6/+2
use structured suggestion for method calls Furthermore, don't suggest calling the method if it is part of a place expression, as this is invalid syntax. I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice. The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas? r? @estebank
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 12:36:12 +0000