summary refs log tree commit diff
path: root/compiler/rustc_trait_selection/src/solve
AgeCommit message (Collapse)AuthorLines
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.
2023-10-23Make things work by using the new solverMichael Goulet-0/+10
2023-10-23Remove FnPtr hack from trait_ref_is_knowableMichael Goulet-8/+19
2023-10-23Handle ReErased in responses in new solverMichael Goulet-2/+10
2023-10-20s/generator/coroutine/Oli Scherer-36/+36
2023-10-20s/Generator/Coroutine/Oli Scherer-33/+33
2023-10-18AliasTy::new instead of tcx methodlcnr-7/+12
2023-10-13explicitly handle auto trait leakage in coherencelcnr-2/+3
2023-10-10reorder files in solvelcnr-4/+5
2023-09-29a small wf and clause cleanuplcnr-5/+4
2023-09-29Auto merge of #115843 - lcnr:bb-provisional-cache, r=compiler-errorsbors-186/+64
new solver: remove provisional cache The provisional cache is a performance optimization if there are large, interleaving cycles. Such cycles generally do not exist. It is incredibly complex and unsound in all trait solvers which have one: the old solver, chalk, and the new solver ([link](https://github.com/rust-lang/rust/blob/master/tests/ui/traits/new-solver/cycles/inductive-not-on-stack.rs)). Given the assumption that it is not perf-critical and also incredibly complex, remove it from the new solver, only checking whether a goal is on the stack. While writing this, I uncovered two additional soundness bugs, see the inline comments for them. r? `@compiler-errors`
2023-09-26Don't store lazyness in DefKindMichael Goulet-1/+1
2023-09-24Remove span from BrAnon.Camille GILLOT-4/+3
2023-09-23Remove GeneratorWitness and rename GeneratorWitnessMIR.Camille GILLOT-20/+8
2023-09-21Move `DepKind` to `rustc_query_system` and define it as `u16`John Kåre Alsaker-2/+2
2023-09-21wlcnr-1/+1
2023-09-21slight refactor, add commentlcnr-11/+20
2023-09-21proof trees: use for `intercrate_ambiguity_causes`lcnr-120/+459
2023-09-20remove `impl<'tcx> ToPredicate<'tcx, Clause<'tcx>> for ↵Ziru Niu-4/+6
PolyProjectionPredicate<'tcx>`
2023-09-18Auto merge of #115748 - RalfJung:post-mono, r=oli-obkbors-2/+4
move required_consts check to general post-mono-check function This factors some code that is common between the interpreter and the codegen backends into shared helper functions. Also as a side-effect the interpreter now uses the same `eval` functions as everyone else to get the evaluated MIR constants. Also this is in preparation for another post-mono check that will be needed for (the current hackfix for) https://github.com/rust-lang/rust/issues/115709: ensuring that all locals are dynamically sized. I didn't expect this to change diagnostics, but it's just cycle errors that change. r? `@oli-obk`
2023-09-18remove provisional cachelcnr-186/+64
2023-09-18Rollup merge of #115838 - lcnr:added-goals, r=compiler-errorsMatthias Krüger-68/+117
inspect: closer to proof trees for coherence a continuation of #115751. Now explicitly store the added goals r? ```@compiler-errors```
2023-09-15Canonicalize effect vars in new solverMichael Goulet-2/+21
2023-09-14move required_consts check to general post-mono-check functionRalf Jung-2/+4
2023-09-14differentiate root and nested goalslcnr-25/+57
2023-09-14inspect: explicitly store added goalslcnr-1/+19
2023-09-14order `added_goals_evaluation` and `nested_probes`lcnr-24/+25
2023-09-14`GoalCandidate` to `Probe`lcnr-29/+27
2023-09-14Auto merge of #115751 - lcnr:inspect-cleanup, r=compiler-errorsbors-205/+200
some inspect improvements split from #114810 because I still want to experiment a bunch with that PR and these changes are self-contained. r? `@compiler-errors`
2023-09-11Rollup merge of #115727 - fee1-dead-contrib:effect-fallback, r=oli-obkMatthias Krüger-0/+3
Implement fallback for effect param r? `@oli-obk` or `@lcnr` tracking issue for this ongoing work: https://github.com/rust-lang/rust/issues/110395
2023-09-11dedup `GoalEvaluationStep` and `GoalCandidate`lcnr-42/+56
also handle 2 panics when dumping proof trees for the whole test suite - need to actually tell the proof tree builder about overflow - need to handle a recursion_limit of 0 :<
2023-09-11inspect: strongly typed CandidateKindlcnr-103/+66
2023-09-11inspect: handle `None` in `nested`lcnr-27/+7
2023-09-11split GoalEvaluation and CanonicalGoalEvaluationlcnr-60/+98
the unnormalized goal is in the callers inference context, while anything inside of the `CanonicalGoalEvaluation` is inside of a new one.
2023-09-10Implement fallback for effect paramDeadbeef-0/+3
2023-09-05Rollup merge of #115519 - compiler-errors:next-solver-assoc-ice, r=lcnrMatthias Krüger-1/+15
Don't ICE on associated type projection without feature gate in new solver Self-explanatory, we should avoid ICEs when the feature gate is not enabled. Continue to ICE when the feature gate *is* enabled, though. Fixes #115500
2023-09-05Auto merge of #115467 - compiler-errors:assoc-ty-object-safety, r=oli-obkbors-0/+6
Do not require associated types with Self: Sized to uphold bounds when confirming object candidate RPITITs and associated types that have `Self: Sized` bounds are opted out of the `dyn Trait` well-formedness check that happens during confirmation. This ensures that we can actually *use* `dyn Trait`s that have associated types that, e.g., have GATs and RPITITs and other naughty things as long as those are opted-out of object safety via a `Self: Sized` bound. Fixes #115464 This seems like a natural part of https://github.com/rust-lang/rust/pull/112319#issuecomment-1592574451, and I don't think needs re-litigation. r? `@oli-obk`
2023-09-03Don't ICE on associated type projection without feature gateMichael Goulet-1/+15
2023-09-02Do not require associated types with Self: Sized to uphold bounds when ↵Michael Goulet-3/+3
confirming object candidate
2023-09-02RPITITs are considered object-safe, they're always on Self:Sized methodsMichael Goulet-0/+6
2023-09-02Signed-off-by: cui fliter <imcusg@gmail.com>cui fliter-1/+1
remove the repetitive word Signed-off-by: cui fliter <imcusg@gmail.com>
2023-08-30clean up `local_overflow_limit` computationRémy Rakic-5/+1
fixes bors snafu where it merged an outdated commit and missed this change
2023-08-29handle edge-case of a recursion limit of 0Rémy Rakic-1/+5
2023-08-18instantiate response: no unnecessary new universelcnr-1/+1
this previously was a off-by-one error.