about summary refs log tree commit diff
path: root/compiler/rustc_trait_selection
AgeCommit message (Collapse)AuthorLines
2023-04-10Support safe transmute in new solverMichael Goulet-0/+64
2023-04-10Stall auto-trait assembly for int/float vars in new solverMichael Goulet-24/+64
2023-04-10review + some small stufflcnr-10/+16
2023-04-10move `structural_traits` into `assembly`lcnr-11/+9
2023-04-10prioritize param-env candidateslcnr-78/+83
2023-04-09Auto merge of #109413 - compiler-errors:pointer-like-abi, r=cjgillotbors-10/+8
Enforce that `PointerLike` requires a pointer-like ABI At least temporarily, let's ban coercing things that are pointer-sized and pointer-aligned but *not* `Abi::Scalar(..)` into `dyn*`. See: https://github.com/rust-lang/rust/pull/104694#discussion_r1142522073 This can be lifted in the future if we decie that we *want* to be able to coerce something `repr(C)` into a `dyn*`, but we'll have to figure out what to do with Miri and codegen... r? compiler
2023-04-09Auto merge of #110031 - compiler-errors:generic-elaboration, r=b-naberbors-21/+17
Make elaboration generic over input Combines all the `elaborate_*` family of functions into just one, which is an iterator over the same type that you pass in (e.g. elaborating `Predicate` gives `Predicate`s, elaborating `Obligation`s gives `Obligation`s, etc.)
2023-04-08Enforce that PointerLike requires a pointer-like ABIMichael Goulet-10/+8
2023-04-08Remove `remap_env_constness` in queriesDeadbeef-7/+1
2023-04-07Switched provisional evaluation cache map to FxIndexMap, and replaced ↵Andrew Xie-15/+9
map.drain_filter with map.retain
2023-04-06Remove u32 on BoundTyKind::AnonJack Huey-8/+6
2023-04-06Remove index from BrAnonJack Huey-3/+3
2023-04-06Remove expect_anon and expect_anon_placeholder in favor of varJack Huey-1/+1
2023-04-06Use BoundTy and BoundRegion instead of kind of PlaceholderTy and ↵Jack Huey-7/+13
PlaceholderRegion
2023-04-06Get rid of elaborate_trait_ref{s} tooMichael Goulet-3/+4
2023-04-06Make elaborator genericMichael Goulet-20/+15
2023-04-06Rollup merge of #109755 - compiler-errors:new-solver-generator-witness-mir, ↵Matthias Krüger-3/+46
r=cjgillot Implement support for `GeneratorWitnessMIR` in new solver r? ```@cjgillot``` I mostly want this to cut down the number of failing UI tests when running the UI test suite with `--compare-mode=next-solver`, but there doesn't seem like much reason to block implementing this since it adds minimal complexity to the existing structural traits impl in the new solver. If others are against adding this for some reason, then maybe we should just make `GeneratorWitnessMIR` return `NoSolution` for these traits. Anything but an ICE please :smile_cat: :ice_cube:
2023-04-05Rollup merge of #109956 - compiler-errors:tweak-debug-outputs, r=oli-obkYuki Okushi-7/+31
Tweak debug outputs to make debugging new solver easier 1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs. For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output). For canonicalized things, I typically care more about what is *being* canonicalized. For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not... 2. Add some more debug and instrument calls to functions to add more structure to tracing lines. r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
2023-04-05Tweak debug outputs to make debugging new solver easierMichael Goulet-7/+31
2023-04-05Implement support for GeneratorWitnessMIR in new solverMichael Goulet-3/+46
2023-04-04Auto merge of #109917 - compiler-errors:remove-relation-methods, r=oli-obkbors-8/+0
Remove `intercrate` and `mark_ambiguous` from `TypeRelation` Fixes #109863 Pulls this logic into `super_combine_tys`, which has access to `InferCtxt` and takes a `ObligationEmittingRelation` -- both of which simplify the logic here. r? `@oli-obk` `@aliemjay`
2023-04-04Remove intercrate and mark_ambiguous from RelationMichael Goulet-8/+0
2023-04-03Never consider int and float vars for `FnPtr` candidatesNilstrieb-8/+14
This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope. FOr integers it shouldn't be a problem in practice so I wasn't able to add a test.
2023-04-02Rollup merge of #109846 - matthiaskrgr:clippy2023_04_III, r=NilstriebNilstrieb-3/+1
more clippy::complexity fixes (iter_kv_map, map_flatten, nonminimal_bool)
2023-04-01use and_then/flat_map for map().flatten()Matthias Krüger-3/+1
2023-04-01a couple clippy::complexity fixesMatthias Krüger-3/+2
map_identity filter_next option_as_ref_deref unnecessary_find_map redundant_slicing unnecessary_unwrap bool_comparison derivable_impls manual_flatten needless_borrowed_reference
2023-03-31Auto merge of #109762 - scottmcm:variantdef-indexvec, r=WaffleLapkinbors-1/+3
Update `ty::VariantDef` to use `IndexVec<FieldIdx, FieldDef>` And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`. There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places. Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
2023-03-30Rollup merge of #109739 - compiler-errors:new-solver-closure-fnonce, r=lcnrMichael Goulet-3/+14
Closures always implement `FnOnce` in new solver We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind. Fixes compiler-errors/next-solver-hir-issues#15 r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
2023-03-30Rollup merge of #109679 - compiler-errors:normalizes-to-hack-2, r=lcnr,BoxyUwUMichael Goulet-43/+70
Freshen normalizes-to hack goal RHS in the evaluate loop Ensure that we repeatedly equate the unconstrained RHS of the normalizes-to hack goal with the *actual* RHS of the goal, even if the normalizes-to goal loops several times and thus we replace the unconstrained RHS var repeatedly. Alternative to #109583.
2023-03-30Update `ty::VariantDef` to use `IndexVec<FieldIdx, FieldDef>`Scott McMurray-1/+3
And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`. There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places. Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
2023-03-30Closures always implement FnOnce in new solverMichael Goulet-3/+14
2023-03-30Rollup merge of #109749 - compiler-errors:new-solver-float-var, r=lcnrYuki Okushi-1/+1
Canonicalize float var as float in new solver Typo in new canonicalizer -- we should be canonicalizing float vars as `CanonicalTyVarKind::Float`, not `CanonicalTyVarKind::Int`. Fixes compiler-errors/next-solver-hir-issues#9
2023-03-30Rollup merge of #109748 - compiler-errors:new-solver-discr-kind-ice, r=lcnrYuki Okushi-5/+43
Don't ICE on `DiscriminantKind` projection in new solver As title says, since we now actually call `Ty::discriminant_kind` on placeholder types 😃 Also drive-by simplify `Pointee::Metadata` projection logic, and fix the UI test because the `<T as Pointee>::Metadata` tests weren't actually exercising the new projection logic, since we still eagerly normalize (which hits `project.rs` in the old solver) in HIR typeck. r? `@lcnr` tho feel free to re-roll, this pr is very low-priority and not super specific to the new trait solver. Fixes compiler-errors/next-solver-hir-issues#14
2023-03-30canonicalize float var as float in new solverMichael Goulet-1/+1
2023-03-30Check pointee metadata correctly in ui testMichael Goulet-3/+1
2023-03-30Don't ICE on DiscriminantKind projection in new solverMichael Goulet-2/+42
2023-03-29Rollup merge of #109675 - compiler-errors:object-heck, r=lcnrMatthias Krüger-3/+16
Do not consider elaborated projection predicates for objects in new solver Object types have projection bounds which are elaborated during astconv. There's no need to do it again for projection goals, since that'll give us duplicate projection candidatesd that are distinct up to regions due to the fact that we canonicalize every region to a separate variable. See quick example below the break for a better explanation. Discussed this with lcnr, and adding a stop-gap until we get something like intersection region constraints (or modify canonicalization to canonicalize identical regions to the same canonical regions) -- after which, this will hopefully not matter and may be removed. r? `@lcnr` --- See `tests/ui/traits/new-solver/more-object-bound.rs`: Consider a goal: `<dyn Iter<'a, ()> as Iterator>::Item = &'a ()`. After canonicalization: `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'2r ()` * First object candidate comes from the item bound in the dyn's bounds itself, giving us `<dyn Iter<'!0r, (), Item = '?!r ()> as Iterator>::Item == &!'1r ()`. This gives us one region constraint: `!'1r == !'2r`. * Second object candidate comes from elaborating the principal trait ref, gives us `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'0r ()`. This gives us one region constraint: `!'0r == !'2r`. * Oops! Ambiguity!
2023-03-29Rollup merge of #109511 - compiler-errors:eval-ctxt-infcx-private, r=lcnrMatthias Krüger-50/+84
Make `EvalCtxt`'s `infcx` private To better protect against people doing bad things with the inner `InferCtxt` r? `@lcnr`
2023-03-29Freshen normalizes-to hack goal RHS in the evaluate loopMichael Goulet-43/+70
2023-03-29Move canonicalization code aroundMichael Goulet-72/+47
2023-03-29Do not consider elaborated projection predicates for objects in new solverMichael Goulet-3/+16
2023-03-29Rollup merge of #109718 - scottmcm:indexvec-last, r=NilstriebDylan DPC-1/+1
Rename `IndexVec::last` → `last_index` As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`". So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index. (Similarly, `Iterator::last` also returns an element, not an index.)
2023-03-29Rollup merge of #109683 - compiler-errors:self-ty-overflow, r=lcnrDylan DPC-18/+53
Check for overflow in `assemble_candidates_after_normalizing_self_ty` Prevents a stack overflow (:warning: :exclamation:) in the new solver when we have param-env candidates that look like: `T: Trait<Assoc = <T as Trait>::Assoc>` The current error message looks bad, but that's because we don't distinguish overflow and other ambiguity errors. I'll break that out into a separate PR since the fix may be controversial. r? `@lcnr`
2023-03-29Rename `IndexVec::last` → `last_index`Scott McMurray-1/+1
As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`". So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index. (Similarly, `Iterator::last` also returns an element, not an index.)
2023-03-29Rollup merge of #109705 - lcnr:coherence-caching, r=compiler-errorsMatthias Krüger-5/+22
new solver: check for intercrate mode when accessing the cache r? ``@compiler-errors``
2023-03-29Inline and remove `SelectionContext::fast_reject_trait_refs`.Nicholas Nethercote-18/+4
Because it has a single call site, and it lets us move a small amount of the work outside the loop.
2023-03-29Introduce `DeepRejectCtxt::substs_refs_may_unify`.Nicholas Nethercote-13/+12
It factors out a repeated code pattern.
2023-03-28check for intercrate mode when accessing the cachelcnr-5/+22
2023-03-28Check for overflow in assemble_candidates_after_normalizing_self_tyMichael Goulet-18/+53
2023-03-28Auto merge of #109692 - Nilstrieb:rollup-hq65rps, r=Nilstriebbors-85/+93
Rollup of 8 pull requests Successful merges: - #91793 (socket ancillary data implementation for FreeBSD (from 13 and above).) - #92284 (Change advance(_back)_by to return the remainder instead of the number of processed elements) - #102472 (stop special-casing `'static` in evaluation) - #108480 (Use Rayon's TLV directly) - #109321 (Erase impl regions when checking for impossible to eagerly monomorphize items) - #109470 (Correctly substitute GAT's type used in `normalize_param_env` in `check_type_bounds`) - #109562 (Update ar_archive_writer to 0.1.3) - #109629 (remove obsolete `givens` from regionck) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-07 20:11:43 +0000