summary refs log tree commit diff
path: root/tests/ui/methods
AgeCommit message (Collapse)AuthorLines
2024-05-31Rollup merge of #125635 - fmease:mv-type-binding-assoc-item-constraint, ↵Matthias Krüger-3/+3
r=compiler-errors Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology. Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense. --- Old terminology (HIR, rustdoc): ``` `TypeBinding`: (associated) type binding ├── `Constraint`: associated type bound └── `Equality`: (associated) equality constraint (?) ├── `Ty`: (associated) type binding └── `Const`: associated const equality (constraint) ``` Old terminology (AST, abbrev.): ``` `AssocConstraint` ├── `Bound` └── `Equality` ├── `Ty` └── `Const` ``` New terminology (AST, HIR, rustdoc): ``` `AssocItemConstraint`: associated item constraint ├── `Bound`: associated type bound └── `Equality`: associated item equality constraint OR associated item binding (for short) ├── `Ty`: associated type equality constraint OR associated type binding (for short) └── `Const`: associated const equality constraint OR associated const binding (for short) ``` r? compiler-errors
2024-05-30Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanupLeón Orell Valerian Liehr-3/+3
2024-05-23Don't continue probing for method if in suggestion and autoderef hits ambiguityMichael Goulet-0/+25
2024-05-20Note for E0599 if shadowed bindings has the method.surechen-0/+24
implement #123558
2024-05-13Add test to make sure suggestions are still quickMichael Goulet-0/+247
2024-05-09Fix test problems discovered by the revision checkZalathar-0/+1
Most of these changes either add revision names that were apparently missing, or explicitly mark a revision name as currently unused.
2024-05-04compiletest: add enable-by-default check-cfgUrgau-0/+3
2024-04-27tests: remove some trailing wsklensy-1/+1
2024-04-21Use sup instead of eq when unifying self typeMichael Goulet-0/+24
2024-04-21Use fulfillment, not evaluate, during method probeMichael Goulet-0/+58
2024-04-11Auto merge of #123007 - kadiwa4:suggest_convert_ptr_to_mut_ref, r=estebankbors-0/+87
Rework ptr-to-ref conversion suggestion for method calls If we have a value `z` of type `*const u8` and try to call `z.to_string()`, the upstream compiler will show you a note suggesting to call `<*const u8>::as_ref` first. This PR extends that: - The note will only be shown when the method would exist on the corresponding reference type - It can now suggest any of `<*const u8>::as_ref`, `<*mut u8>::as_ref` and `<*mut u8>::as_mut`, depending on what the method needs. I didn't introduce a `help` message because that's not a good idea with `unsafe` functions (and you'd also need to unwrap the `Option<&_>` somehow). People should check the safety requirements. For the simplest case ```rust fn main() { let x = 8u8; let z: *const u8 = &x; // issue #21596 println!("{}", z.to_string()); //~ ERROR E0599 } ``` the output changes like this: ```diff error[E0599]: `*const u8` doesn't implement `std::fmt::Display` --> $DIR/suggest-convert-ptr-to-ref.rs:5:22 | LL | println!("{}", z.to_string()); | ^^^^^^^^^ `*const u8` cannot be formatted with the default formatter | - = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref - = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior +note: the method `to_string` exists on the type `&u8` + --> $SRC_DIR/alloc/src/string.rs:LL:COL + = note: try using the unsafe method `<*const T>::as_ref` to get an optional reference to the value behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref = note: the following trait bounds were not satisfied: `*const u8: std::fmt::Display` which is required by `*const u8: ToString` ``` I removed the separate note about the safety requirements because it was incomplete and the linked doc page already has the information you need. Fixes #83695, but that's more of a side effect. The upstream compiler already suggests the right method name here.
2024-04-11Rollup merge of #123703 - estebank:diag-changes-2, r=NadrierilLeón Orell Valerian Liehr-1/+1
Use `fn` ptr signature instead of `{closure@..}` in infer error When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr. On the error message, use `short_ty_string` and write long types to disk. ``` error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt' = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! { | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` instead of ``` error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! { | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` Address #123630 (test missing).
2024-04-10rework ptr-to-ref conversion suggestion for method callsKalle Wachsmuth-6/+73
2024-04-10move testKalle Wachsmuth-0/+20
2024-04-10Use `fn` ptr signature instead of `{closure@..}` in infer errorEsteban Küber-1/+1
When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr. On the error message, use `short_ty_string` and write long types to disk. ``` error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt' = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! { | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` instead of ``` error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>` --> crates/lang/src/parser.rs:41:13 | 41 | let lit = select! { | ^^^ 42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()), | ---- type must be known at this point | = note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan` help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified | 41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! { | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ``` Fix #123630.
2024-04-09Rollup merge of #122768 - oli-obk:why_is_E0699_so_bad, r=WaffleLapkinMatthias Krüger-13/+35
Use the more informative generic type inference failure error on method calls on raw pointers
2024-04-04Add regression testOli Scherer-0/+66
2024-04-01Make sure to insert Sized bound first into clauses listMichael Goulet-0/+30
2024-03-27Stop sorting `DefId`s in the compilerOli Scherer-2/+2
2024-03-27Sort a diagnostic by `DefPathStr` instead of `DefId`Oli Scherer-2/+2
2024-03-27Sort method suggestions by `DefPath` instead of `DefId`Oli Scherer-26/+26
2024-03-20Use the more informative generic type inference failure error on method ↵Oli Scherer-13/+35
calls on raw pointers
2024-03-05Rollup merge of #121826 - estebank:e0277-root-obligation-2, r=oli-obkMatthias Krüger-10/+18
Use root obligation on E0277 for some cases When encountering trait bound errors that satisfy some heuristics that tell us that the relevant trait for the user comes from the root obligation and not the current obligation, we use the root predicate for the main message. This allows to talk about "X doesn't implement Pattern<'_>" over the most specific case that just happened to fail, like "char doesn't implement Fn(&mut char)" in `tests/ui/traits/suggest-dereferences/root-obligation.rs` The heuristics are: - the type of the leaf predicate is (roughly) the same as the type from the root predicate, as a proxy for "we care about the root" - the leaf trait and the root trait are different, so as to avoid talking about `&mut T: Trait` and instead remain talking about `T: Trait` instead - the root trait is not `Unsize`, as to avoid talking about it in `tests/ui/coercion/coerce-issue-49593-box-never.rs`. ``` error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied --> $DIR/root-obligation.rs:6:38 | LL | .filter(|c| "aeiou".contains(c)) | -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>` | | | required by a bound introduced by this call | = note: required for `&char` to implement `FnOnce<(char,)>` = note: required for `&char` to implement `Pattern<'_>` note: required by a bound in `core::str::<impl str>::contains` --> $SRC_DIR/core/src/str/mod.rs:LL:COL help: consider dereferencing here | LL | .filter(|c| "aeiou".contains(*c)) | + ``` Fix #79359, fix #119983, fix #118779, cc #118415 (the suggestion needs to change), cc #121398 (doesn't fix the underlying issue).
2024-03-03Move testsCaio-0/+32
2024-03-03Be more lax in `.into_iter()` suggestion when encountering `Iterator` ↵Esteban Küber-10/+18
methods on non-`Iterator` ``` error[E0599]: no method named `map` found for struct `Vec<bool>` in the current scope --> $DIR/vec-on-unimplemented.rs:3:23 | LL | vec![true, false].map(|v| !v).collect::<Vec<_>>(); | ^^^ `Vec<bool>` is not an iterator | help: call `.into_iter()` first | LL | vec![true, false].into_iter().map(|v| !v).collect::<Vec<_>>(); | ++++++++++++ ``` We used to provide some help through `rustc_on_unimplemented` on non-`impl Trait` and non-type-params, but this lets us get rid of some otherwise unnecessary conditions in the annotation on `Iterator`.
2024-02-22Deduplicate some logic and reword outputEsteban Küber-2/+2
2024-02-22Make confusable suggestions `verbose`Esteban Küber-2/+12
2024-02-18macro_rules: Preserve all metavariable spans in a global side tableVadim Petrochenkov-2/+2
2024-02-16[AUTO-GENERATED] Migrate ui tests from `//` to `//@` directives许杰友 Jieyou Xu (Joe)-62/+62
2024-02-08Continue to borrowck even if there were previous errorsOli Scherer-1/+1
2024-02-07Update testsr0cky-3/+36
2024-02-06Rollup merge of #120507 - estebank:issue-108428, r=davidtwcoMatthias Krüger-2/+3
Account for non-overlapping unmet trait bounds in suggestion When a method not found on a type parameter could have been provided by any of multiple traits, suggest each trait individually, instead of a single suggestion to restrict the type parameter with *all* of them. Before: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` help: consider restricting the type parameters to satisfy the trait bounds | LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord { | +++++++++++++++++++++++++ ``` After: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix #108428. Follow up to #120396, only last commit is relevant.
2024-02-01review comment: change wordingEsteban Küber-1/+1
2024-02-01On E0277 be clearer about implicit `Sized` bounds on type params and assoc typesEsteban Küber-2/+2
``` error[E0277]: the size for values of type `[i32]` cannot be known at compilation time --> f100.rs:2:33 | 2 | let _ = std::mem::size_of::<[i32]>(); | ^^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[i32]` note: required by an implicit `Sized` bound in `std::mem::size_of` --> /home/gh-estebank/rust/library/core/src/mem/mod.rs:312:22 | 312 | pub const fn size_of<T>() -> usize { | ^ required by the implicit `Sized` requirement on this bound in `size_of` ``` Fix #120178.
2024-01-30Account for non-overlapping unmet trait bounds in suggestionEsteban Küber-2/+3
When a method not found on a type parameter could have been provided by any of multiple traits, suggest each trait individually, instead of a single suggestion to restrict the type parameter with *all* of them. Before: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` help: consider restricting the type parameters to satisfy the trait bounds | LL | fn g<T>(a: T, b: T) -> std::cmp::Ordering where T: Iterator, T: Ord { | +++++++++++++++++++++++++ ``` After: ``` error[E0599]: the method `cmp` exists for reference `&T`, but its trait bounds were not satisfied --> $DIR/method-on-unbounded-type-param.rs:5:10 | LL | (&a).cmp(&b) | ^^^ method cannot be called on `&T` due to unsatisfied trait bounds | = note: the following trait bounds were not satisfied: `T: Ord` which is required by `&T: Ord` `&T: Iterator` which is required by `&mut &T: Iterator` `T: Iterator` which is required by `&mut T: Iterator` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following traits define an item `cmp`, perhaps you need to restrict type parameter `T` with one of them: | LL | fn g<T: Ord>(a: T, b: T) -> std::cmp::Ordering { | +++++ LL | fn g<T: Iterator>(a: T, b: T) -> std::cmp::Ordering { | ++++++++++ ``` Fix #108428.
2024-01-30Rollup merge of #120400 - estebank:bound-error-cleanup, r=oli-obkGuillaume Gomez-4/+1
Bound errors span label cleanup Consolidate span labels for "this type doesn't satisfy a bound" for more compact diagnostic output.
2024-01-26Use single label for method not found due to unmet boundEsteban Küber-4/+1
2024-01-24On E0308 involving `dyn Trait`, mention trait objectsEsteban Küber-0/+1
When encountering a type mismatch error involving `dyn Trait`, mention the existence of boxed trait objects if the other type involved implements `Trait`. Partially addresses #102629.
2024-01-05macro_rules: Add more tests for using `tt` in addition to `ident`Vadim Petrochenkov-6/+24
Generally, `tt` and `ident` should behave identically, modulo the latter accepting only a subset of token trees.
2024-01-02Adjust compiler tests for unused_tuple_struct_fields -> dead_codeJake Goulding-3/+3
2023-12-27fix broken CI and code reviewYoung-Flash-6/+53
2023-12-16test: add test case for `disambiguate the associated function` diagnosticYoung-Flash-0/+69
2023-11-24Show number in error message even for one errorNilstrieb-15/+15
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-12Don't expect a rcvr in print_disambiguation_helpMichael Goulet-0/+46
2023-11-07Rework print_disambiguation_helpMichael Goulet-36/+36
2023-10-17Unify suggestion wordingEsteban Küber-74/+45
2023-10-17review comments + more testsEsteban Küber-12/+412
2023-10-17Properly account for self ty in method disambiguation suggestionEsteban Küber-0/+109
Fix #116703.
2023-10-04Reorder fullfillment errors to keep more interesting ones firstEsteban Küber-1/+1
In `report_fullfillment_errors` push back `T: Sized`, `T: WellFormed` and coercion errors to the end of the list. The pre-existing deduplication logic eliminates redundant errors better that way, keeping the resulting output with fewer errors than before, while also having more detail.
2023-09-21adjust how closure/generator types and rvalues are printedRalf Jung-1/+1