summary refs log tree commit diff
path: root/compiler/rustc_trait_selection/src/solve
AgeCommit message (Collapse)AuthorLines
2023-12-19add commentlcnr-0/+14
2023-12-18dont discard overflow from normalizes-to goalslcnr-22/+45
2023-12-18track the source of nested goalslcnr-77/+145
2023-12-15Annotate some bugsMichael Goulet-2/+9
2023-12-14Unconditionally register alias-relate in projection goalMichael Goulet-11/+23
2023-12-14consistently use "next solver" instead of "new solver"lcnr-4/+4
2023-12-14update use of feature flagslcnr-5/+4
2023-12-14rename `-Ztrait-solver` to `-Znext-solver`lcnr-4/+5
2023-12-12refactor writeback: emit normalization errors with new solverlcnr-5/+4
2023-12-08Rollup merge of #117586 - compiler-errors:the-canonicalizer, r=lcnrMatthias Krüger-430/+1
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-08Uplift canonicalizer into new trait solver crateMichael Goulet-430/+1
2023-12-08Implement `async gen` blocksMichael Goulet-0/+65
2023-12-08implement and use `NormalizesTo`lcnr-61/+71
2023-12-07add unused `NormalizesTo` predicatelcnr-0/+6
2023-12-05Continue folding if deep normalizer failsMichael Goulet-14/+40
2023-12-05Add deeply_normalize_for_diagnostics, use it in coherenceMichael Goulet-2/+18
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-2/+2
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-11-29new solver: improve instrument annotationslcnr-1/+4
2023-11-26Clean dead codesr0cky-17/+0
2023-11-25Rollup merge of #118259 - spastorino:move-eager-resolver-to-infer, ↵León Orell Valerian Liehr-80/+5
r=compiler-errors Move EagerResolution to rustc_infer::infer::resolve `EagerResolver` fits better in `rustc_infer::infer::resolver`. Started to disentagle #118118 that has a lot of unrelated things. r? `@compiler-errors` `@lcnr`
2023-11-24Move EagerResolution to rustc_infer::infer::resolveSantiago Pastorino-80/+5
2023-11-24Rollup merge of #118243 - lcnr:commit-if-ok, r=compiler-errorsMichael Goulet-9/+9
EvalCtxt::commit_if_ok don't inherit nested goals we use it to check whether an alias is rigid, so we want to avoid considering an alias rigid simply because the inference constraints from normalizing it caused another nested goal fail r? `@compiler-errors`
2023-11-24EvalCtxt::commit_if_ok don't inherit nested goalslcnr-9/+9
2023-11-22Auto merge of #118120 - compiler-errors:closure-kind, r=lcnrbors-3/+0
Remove `PredicateKind::ClosureKind` We don't need the `ClosureKind` predicate kind -- instead, `Fn`-family trait goals are left as ambiguous, and we only need to make progress on `FnOnce` projection goals for inference purposes. This is similar to how we do confirmation of `Fn`-family trait and projection goals in the new trait solver, which also doesn't use the `ClosureKind` predicate. Some hacky logic is added in the second commit so that we can keep the error messages the same.
2023-11-22Replace `no_ord_impl` with `orderable`.Nicholas Nethercote-0/+1
Similar to the previous commit, this replaces `newtype_index`'s opt-out `no_ord_impl` attribute with the opt-in `orderable` attribute.
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-5/+5
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now.
2023-11-21Remove ClosureKind predicate kindMichael Goulet-3/+0
2023-11-20handle reservation impls, track impl sourcelcnr-25/+45
2023-11-20self ty infer ambiguity: add proof tree candlcnr-11/+16
2023-11-17Auto merge of #117278 - lcnr:try-normalize-ty, r=compiler-errorsbors-291/+287
new solver normalization improvements cool beans At the core of this PR is a `try_normalize_ty` which stops for rigid aliases by using `commit_if_ok`. Reworks alias-relate to fully normalize both the lhs and rhs and then equate the resulting rigid (or inference) types. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/68 by avoiding the exponential blowup. Also supersedes #116369 by only defining opaque types if the hidden type is rigid. I removed the stability check in `EvalCtxt::evaluate_goal` due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/75. While I personally have opinions on how to fix it, that still requires further t-types/`@nikomatsakis` buy-in, so I removed that for now. Once we've decided on our approach there, we can revert this commit. r? `@compiler-errors`
2023-11-15Auto merge of #117878 - gavinleroy:proper-depth-check, r=lcnrbors-1/+1
Fix depth check in ProofTreeVisitor. The hack to cutoff overflows and cycles in the new trait solver was incorrect. We want to inspect everything with depth [0..10]. This fix exposed a previously unseen bug, which caused the compiler to ICE when invoking `trait_ref` on a non-assoc type projection. I simply added the guard in the `AmbiguityCausesVisitor`, and updated the expected output for the `auto-trait-coherence` test which now includes the extra note: ```text | = note: upstream crates may add a new impl of trait `std::marker::Send` for type `OpaqueType` in future versions ``` r? `@lcnr`
2023-11-14finish `RegionKind` renamelcnr-1/+1
- `ReFree` -> `ReLateParam` - `ReEarlyBound` -> `ReEarlyParam`
2023-11-13Rollup merge of #117870 - lcnr:rename-args_ref, r=compiler-errorsMatthias Krüger-4/+2
`fn args_ref_X` to `fn args_X`
2023-11-13Fix overflow and cycle bound for ProofTreeVisitor.Gavin Gray-1/+1
2023-11-13update type flagslcnr-1/+1
- `HAS_RE_LATE_BOUND` -> `HAS_RE_BOUND` - `HAS_TY_LATE_BOUND` -> `HAS_TY_BOUND` - `HAS_CT_LATE_BOUND` -> `HAS_CT_BOUND` - `HAS_LATE_BOUND` -> `HAS_BOUND_VARS` - `fn has_late_bound_regions` -> `fn has_bound_regions` - `fnhas_non_region_late_bound` -> `fn has_non_region_bound_vars` - `fn has_late_bound_vars` -> `fn has_bound_vars`
2023-11-13continue renaminglcnr-2/+2
- `RegionVariableOrigin::~~Late~~BoundRegion` - `~~Late~~BoundRegionConversionTime`
2023-11-13rename `ReLateBound` to `ReBound`lcnr-4/+4
other changes: - `Region::new_late_bound` -> `Region::new_bound` - `Region::is_late_bound` -> `Region::is_bound`
2023-11-13args~~_ref~~_may_unifylcnr-4/+2
2023-11-09remove stability assert in `evaluate_goal`lcnr-98/+8
2023-11-09update overflow handling for norm, add testlcnr-2/+2
2023-11-09rework alias-relate to `norm(lhs) == norm(rhs)`lcnr-165/+140
2023-11-09only instantiate opaques with rigid typeslcnr-17/+22
2023-11-09`try_normalize_ty` end with rigid alias on failurelcnr-30/+136
2023-11-08instrument constituent types computationlcnr-0/+3
2023-11-02Rollup merge of #117394 - lcnr:proof-tree-cache4, r=compiler-errorsMatthias Krüger-97/+94
use global cache when computing proof trees we're writing the solver while relying on the existence of the global cache to avoid exponential blowup. By disabling the global cache when building proof trees, it is easy to get hangs, e.g. when computing intercrate ambiguity causes. Removes the unstable `-Zdump_solver_proof_tree_use_cache` option, as we now always return a full proof tree. r? `@compiler-errors`
2023-11-02use global cache when computing proof treeslcnr-97/+94
2023-10-30Some more coroutine renamingsMichael Goulet-1/+1
2023-10-29Auto merge of #116447 - oli-obk:gen_fn, r=compiler-errorsbors-4/+69
Implement `gen` blocks in the 2024 edition Coroutines tracking issue https://github.com/rust-lang/rust/issues/43122 `gen` block tracking issue https://github.com/rust-lang/rust/issues/117078 This PR implements `gen` blocks that implement `Iterator`. Most of the logic with `async` blocks is shared, and thus I renamed various types that were referring to `async` specifically. An example usage of `gen` blocks is ```rust fn foo() -> impl Iterator<Item = i32> { gen { yield 42; for i in 5..18 { if i.is_even() { continue } yield i * 2; } } } ``` The limitations (to be resolved) of the implementation are listed in the tracking issue
2023-10-27Make `gen` blocks implement the `Iterator` traitOli Scherer-4/+69
2023-10-26Auto merge of #112875 - compiler-errors:negative-coherence-rework, r=lcnrbors-8/+29
Rework negative coherence to properly consider impls that only partly overlap This PR implements a modified negative coherence that handles impls that only have partial overlap. It does this by: 1. taking both impl trait refs, instantiating them with infer vars 2. equating both trait refs 3. taking the equated trait ref (which represents the two impls' intersection), and resolving any vars 4. plugging all remaining infer vars with placeholder types these placeholder-plugged trait refs can then be used normally with the new trait solver, since we no longer have to worry about the issue with infer vars in param-envs. We use the **new trait solver** to reason correctly about unnormalized trait refs (due to deferred projection equality), since this avoid having to normalize anything under param-envs with infer vars in them. This PR then additionally: * removes the `FnPtr` knowable hack by implementing proper negative `FnPtr` trait bounds for rigid types. --- An example: Consider these two partially overlapping impls: ``` impl<T, U> PartialEq<&U> for &T where T: PartialEq<U> {} impl<F> PartialEq<F> for F where F: FnPtr {} ``` Under the old algorithm, we would take one of these impls and replace it with infer vars, then try unifying it with the other impl under identity substitutions. This is not possible in either direction, since it either sets `T = U`, or tries to equate `F = &?0`. Under the new algorithm, we try to unify `?0: PartialEq<?0>` with `&?1: PartialEq<&?2>`. This gives us `?0 = &?1 = &?2` and thus `?1 = ?2`. The intersection of these two trait refs therefore looks like: `&?1: PartialEq<&?1>`. After plugging this with placeholders, we get a trait ref that looks like `&!0: PartialEq<&!0>`, with the first impl having substs `?T = ?U = !0` and the second having substs `?F = &!0`[^1]. Then we can take the param-env from the first impl, and try to prove the negated where clause of the second. We know that `&!0: !FnPtr` never holds, since it's a rigid type that is also not a fn ptr, we successfully detect that these impls may never overlap. [^1]: For the purposes of this example, I just ignored lifetimes, since it doesn't really matter.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 16:32:35 +0000