about summary refs log tree commit diff
path: root/compiler/rustc_trait_selection
AgeCommit message (Collapse)AuthorLines
2023-12-12Move some methods from `tcx.hir()` to `tcx`zetanumbers-32/+30
Renamings: - find -> opt_hir_node - get -> hir_node - find_by_def_id -> opt_hir_node_by_def_id - get_by_def_id -> hir_node_by_def_id Fix rebase changes using removed methods Use `tcx.hir_node_by_def_id()` whenever possible in compiler Fix clippy errors Fix compiler Apply suggestions from code review Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Add FIXME for `tcx.hir()` returned type about its removal Simplify with with `tcx.hir_node_by_def_id`
2023-12-12refactor writeback: emit normalization errors with new solverlcnr-5/+4
2023-12-11Auto merge of #118661 - fee1-dead-contrib:restore-const-partialEq, ↵bors-2/+5
r=compiler-errors Restore `const PartialEq` And thus fixes a number of tests. There is a bug that still needs to be fixed, so WIP for now. r? `@compiler-errors`
2023-12-10fix host param for `PartialEq`Deadbeef-2/+5
2023-12-10remove redundant importssurechen-2/+0
detects redundant imports that can be eliminated. for #117772 : In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.
2023-12-09report_not_const_evaluatable_error to avoid ICEing on ConstKind::ExprLenko Donchev-13/+23
2023-12-09Rollup merge of #118762 - compiler-errors:gen-nits, r=eholkJubilee-3/+2
Some more minor `async gen`-related nits Tiny tweaks found after `async gen` pr landed r? eholk
2023-12-08Rollup merge of #118736 - aliemjay:revert-ice-on-ambig, r=compiler-errorsMatthias Krüger-12/+4
temporarily revert "ice on ambguity in mir typeck" Reverts #116530 as a temporary measure to fix #117577. That issue should be ultimately fixed by checking WF of type annotations prior to normalization, which is implemented in #104098 but this PR is intended to be backported to beta. r? ``@compiler-errors`` (the reviewer of the reverted PR)
2023-12-08Rollup merge of #117586 - compiler-errors:the-canonicalizer, r=lcnrMatthias Krüger-430/+2
Uplift the (new solver) canonicalizer into `rustc_next_trait_solver` Uplifts the new trait solver's canonicalizer into a new crate called `rustc_next_trait_solver`. The crate name is literally a bikeshed-avoidance name, so let's not block this PR on that -- renames are welcome later. There are a host of other changes that were required to make this possible: * Expose a `ConstTy` trait to get the `Interner::Ty` from a `Interner::Const`. * Expose some constructor methods to construct `Bound` variants. These are currently methods defined on the interner themselves, but they could be pulled into traits later. * Expose a `IntoKind` trait to turn a `Ty`/`Const`/`Region` into their corresponding `*Kind`s. * Some minor tweaks to other APIs in `rustc_type_ir`. The canonicalizer code itself is best reviewed **with whitespace ignored.** r? ``@lcnr``
2023-12-08More nitsMichael Goulet-3/+2
2023-12-08Uplift canonicalizer into new trait solver crateMichael Goulet-430/+2
2023-12-08Implement `async gen` blocksMichael Goulet-4/+232
2023-12-08Auto merge of #118689 - compiler-errors:const-drop, r=fee1-deadbors-10/+21
Fix const drop checking Fixes confirmation of `~const Destruct` and const drops. r? fee1-dead
2023-12-08temporarily revert "ice on ambguity in mir typeck"Ali MJ Al-Nasrawy-12/+4
Reverts #116530
2023-12-08Auto merge of #118725 - lcnr:normalizes-to-projection-split-3, r=BoxyUwUbors-76/+102
split `NormalizesTo` out of `Projection` 3 third attempt at #112658. Rebasing #116262 is very annoying, so I am doing it again from scratch. We should now be able to merge it without regressing anything as we handle occurs check failures involving aliases correctly since #117088. see https://hackmd.io/ktEL8knTSYmtdfrMMnA-Hg fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/1 r? `@compiler-errors`
2023-12-08implement and use `NormalizesTo`lcnr-67/+73
2023-12-07Rollup merge of #118686 - compiler-errors:object-safety, r=lcnrMatthias Krüger-10/+7
Only check principal trait ref for object safety It should make things a bit faster, in case we end up registering a bunch of object safety preds. r? ```@ghost```
2023-12-07add unused `NormalizesTo` predicatelcnr-10/+30
2023-12-07Fix const drop checkingMichael Goulet-10/+21
2023-12-07Auto merge of #118685 - compiler-errors:stack-dependent, r=lcnrbors-4/+4
`EvaluatedToUnknown` -> `EvaluatedToAmbigStackDependent`, `EvaluatedToRecur` -> `EvaluatedToErrStackDependent` Less confusing names, since the only difference between them and their parallel `EvalutedTo..` is that they are stack dependent. r? lcnr
2023-12-07Auto merge of #118684 - compiler-errors:yeet-poly-gen-sig, r=spastorinobors-65/+59
Remove `PolyGenSig` since it's always a dummy binder Coroutines are never polymorphic in their signature. This cleans up a FIXME in the code: ``` /// Returns the "coroutine signature", which consists of its yield /// and return types. /// /// N.B., some bits of the code prefers to see this wrapped in a /// binder, but it never contains bound regions. Probably this /// function should be removed. ```
2023-12-06Only check principal trait ref for object safetyMichael Goulet-10/+7
2023-12-06EvaluatedToUnknown -> EvaluatedToAmbigStackDependent, EvaluatedToRecur -> ↵Michael Goulet-4/+4
EvaluatedToErrStackDependent
2023-12-06Yeet PolyGenSigMichael Goulet-65/+59
2023-12-06Rollup merge of #116496 - estebank:question-method-chain-context, ↵Matthias Krüger-3/+232
r=compiler-errors Provide context when `?` can't be called because of `Result<_, E>` When a method chain ending in `?` causes an E0277 because the expression's `Result::Err` variant doesn't have a type that can be converted to the `Result<_, E>` type parameter in the return type, provide additional context of which parts of the chain can and can't support the `?` operator. ``` error[E0277]: `?` couldn't convert the error to `String` --> $DIR/question-mark-result-err-mismatch.rs:27:25 | LL | fn bar() -> Result<(), String> { | ------------------ expected `String` because of this LL | let x = foo(); | ----- this has type `Result<_, String>` ... LL | .map_err(|_| ())?; | ---------------^ the trait `From<()>` is not implemented for `String` | | | this can't be annotated with `?` because it has type `Result<_, ()>` | = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait = help: the following other types implement trait `From<T>`: <String as From<char>> <String as From<Box<str>>> <String as From<Cow<'a, str>>> <String as From<&str>> <String as From<&mut str>> <String as From<&String>> = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>` ``` Fix #72124.
2023-12-05Reduce verbosity of errorEsteban Küber-16/+21
2023-12-05Detect incorrect `;` in `Option::ok_or_else` and `Result::map_err`Esteban Küber-3/+67
Fix #72124.
2023-12-05Point at fewer methods in the chain, only those that change the E typeEsteban Küber-29/+47
2023-12-05Provide context when `?` can't be called because of `Result<_, E>`Esteban Küber-1/+143
When a method chain ending in `?` causes an E0277 because the expression's `Result::Err` variant doesn't have a type that can be converted to the `Result<_, E>` type parameter in the return type, provide additional context of which parts of the chain can and can't support the `?` operator. ``` error[E0277]: `?` couldn't convert the error to `String` --> $DIR/question-mark-result-err-mismatch.rs:28:25 | LL | fn bar() -> Result<(), String> { | ------------------ expected `String` because of this LL | let x = foo(); | ----- this can be annotated with `?` because it has type `Result<String, String>` LL | let one = x LL | .map(|s| ()) | ----------- this can be annotated with `?` because it has type `Result<(), String>` LL | .map_err(|_| ())?; | ---------------^ the trait `From<()>` is not implemented for `String` | | | this can't be annotated with `?` because it has type `Result<(), ()>` | = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait = help: the following other types implement trait `From<T>`: <String as From<char>> <String as From<Box<str>>> <String as From<Cow<'a, str>>> <String as From<&str>> <String as From<&mut str>> <String as From<&String>> = note: required for `Result<(), String>` to implement `FromResidual<Result<Infallible, ()>>` ``` Fix #72124.
2023-12-05Rollup merge of #118346 - compiler-errors:deeply-normalize-for-diagnostic, ↵Michael Goulet-5/+57
r=lcnr Add `deeply_normalize_for_diagnostics`, use it in coherence r? lcnr Normalize trait refs used for coherence error reporting with `-Ztrait-solver=next-coherence`. Two things: 1. I said before that we can't add this to `TyErrCtxt` because we compute `OverlapResult`s even if there are no diagnostics being emitted, e.g. for a reservation impl. 2. I didn't want to add this to an `InferCtxtExt` trait because I felt it was unnecessary. I don't particularly care about the API though.
2023-12-05Add moreMichael Goulet-5/+5
2023-12-05Add print_trait_sugaredMichael Goulet-11/+4
2023-12-05Continue folding if deep normalizer failsMichael Goulet-14/+40
2023-12-05Add deeply_normalize_for_diagnostics, use it in coherenceMichael Goulet-4/+30
2023-12-04Deduplicate some logicEsteban Küber-0/+72
2023-12-04Rollup merge of #118495 - weiznich:more_tests_for_on_unimplemented, ↵Takayuki Maeda-52/+98
r=compiler-errors Restrict what symbols can be used in `#[diagnostic::on_unimplemented]` format strings This commit restricts what symbols can be used in a format string for any option of the `diagnostic::on_unimplemented` attribute. We previously allowed all the ad-hoc options supported by the internal `#[rustc_on_unimplemented]` attribute. For the stable attribute we only want to support generic parameter names and `{Self}` as parameters. For any other parameter an warning is emitted and the parameter is replaced by the literal parameter string, so for example `{integer}` turns into `{integer}`. This follows the general design of attributes in the `#[diagnostic]` attribute namespace, that any syntax "error" is treated as warning and subsequently ignored. r? `@compiler-errors`
2023-12-04Restrict what symbols can be used in `#[diagnostic::on_unimplemented]` ↵Georg Semmler-52/+98
format strings This commit restricts what symbols can be used in a format string for any option of the `diagnostic::on_unimplemented` attribute. We previously allowed all the ad-hoc options supported by the internal `#[rustc_on_unimplemented]` attribute. For the stable attribute we only want to support generic parameter names and `{Self}` as parameters. For any other parameter an warning is emitted and the parameter is replaced by the literal parameter string, so for example `{integer}` turns into `{integer}`. This follows the general design of attributes in the `#[diagnostic]` attribute namespace, that any syntax "error" is treated as warning and subsequently ignored.
2023-12-03Auto merge of #118526 - sjwang05:issue-118510, r=petrochenkovbors-2/+9
Fix ICE: `fn_arg_names: unexpected item DefId(..)` Fixes #118510
2023-12-02Fix ICE when suggesting closures for non-fn-like defssjwang05-2/+9
2023-12-02Auto merge of #117754 - matthewjasper:subtype-overflow, r=lcnrbors-5/+30
Handle recursion limit for subtype and well-formed predicates Adds a recursion limit check for subtype predicates and well-formed predicates. `-Ztrait-solver=next` currently panics with unimplemented for these cases. These cases are arguably bugs in the occurs check but: - I could not find a simple way to fix the occurs check - There should still be a recursion limit check to prevent hangs anyway. closes #117151 r? types
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-34/+38
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-12-01Handle recursion limit for subtype and well-formed predicatesMatthew Jasper-5/+30
2023-11-30Auto merge of #117805 - estebank:arg-fn-mismatch, r=petrochenkovbors-18/+173
On Fn arg mismatch for a fn path, suggest a closure When encountering a fn call that has a path to another fn being passed in, where an `Fn` impl is expected, and the arguments differ, suggest wrapping the argument with a closure with the appropriate arguments. The last `help` is new: ``` error[E0631]: type mismatch in function arguments --> $DIR/E0631.rs:9:9 | LL | fn f(_: u64) {} | ------------ found signature defined here ... LL | foo(f); | --- ^ expected due to this | | | required by a bound introduced by this call | = note: expected function signature `fn(usize) -> _` found function signature `fn(u64) -> _` note: required by a bound in `foo` --> $DIR/E0631.rs:3:11 | LL | fn foo<F: Fn(usize)>(_: F) {} | ^^^^^^^^^ required by this bound in `foo` help: consider wrapping the function in a closure | LL | foo(|arg0: usize| f(/* u64 */)); | +++++++++++++ +++++++++++ ```
2023-11-29review comments and rebase fixesEsteban Küber-65/+64
2023-11-29On Fn arg mismatch for a fn path, suggest a closureEsteban Küber-11/+167
When encountering a fn call that has a path to another fn being passed in, where an `Fn` impl is expected, and the arguments differ, suggest wrapping the argument with a closure with the appropriate arguments.
2023-11-29new solver: improve instrument annotationslcnr-1/+4
2023-11-27Auto merge of #117200 - rmehri01:repeated_help, r=WaffleLapkinbors-1/+1
Don't add redundant help for object safety violations Fixes #117186 r? WaffleLapkin
2023-11-27Auto merge of #118118 - spastorino:do-not-erase-late-bound-regions-on-iat, ↵bors-1/+12
r=compiler-errors Do not erase late bound regions when selecting inherent associated types In the fix for #97156 we would want the following code: ```rust #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Foo<T>(T); impl Foo<fn(&'static ())> { type Assoc = u32; } trait Other {} impl Other for u32 {} // FIXME(inherent_associated_types): Avoid emitting two diagnostics (they only differ in span). // FIXME(inherent_associated_types): Enhancement: Spruce up the diagnostic by saying something like // "implementation is not general enough" as is done for traits via // `try_report_trait_placeholder_mismatch`. fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {} //~^ ERROR mismatched types //~| ERROR mismatched types fn main() {} ``` to fail with ... ``` error[E0220]: associated type `Assoc` not found for `Foo<for<'a> fn(&'a ())>` in the current scope --> tests/ui/associated-inherent-types/issue-109789.rs:18:36 | 4 | struct Foo<T>(T); | ------------- associated item `Assoc` not found for this struct ... 18 | fn bar(_: Foo<for<'a> fn(&'a ())>::Assoc) {} | ^^^^^ associated item not found in `Foo<for<'a> fn(&'a ())>` | = note: the associated type was found for - `Foo<fn(&'static ())>` error: aborting due to previous error For more information about this error, try `rustc --explain E0220`. ``` This PR fixes the ICE we are currently getting "was a subtype of Foo<Binder(fn(&ReStatic ()), [])> during selection but now it is not" Also fixes #112631 r? `@lcnr`
2023-11-26don't add redundant help for object safety violationsRyan Mehri-1/+1
2023-11-26Rollup merge of #118302 - mu001999:dead_code/clean, r=cjgillotGuillaume Gomez-17/+0
Clean dead codes Clean dead codes detected by #118257