about summary refs log tree commit diff
path: root/compiler/rustc_trait_selection/src/solve
AgeCommit message (Collapse)AuthorLines
2024-04-15Simplify shallow resolver to just fold ty/constsMichael Goulet-1/+1
2024-04-15Remove ConstVariableOriginKindMichael Goulet-10/+4
2024-04-15Remove TypeVariableOriginKindMichael Goulet-10/+5
2024-04-09Rollup merge of #123662 - compiler-errors:no-upvars-yet, r=oli-obkGuillaume Gomez-2/+11
Don't rely on upvars being assigned just because coroutine-closure kind is assigned Previously, code relied on the implicit assumption that if a coroutine-closure's kind variable was constrained, then its upvars were also constrained. This is because we assign all of them at once at the end up upvar analysis. However, there's another way that a coroutine-closure's kind can be constrained: from a signature hint in closure signature deduction. After #123350, we use these hints, which means the implicit assumption above no longer holds. This PR adds the necessary checks so that we don't ICE. r? oli-obk
2024-04-08Don't rely on upvars being assigned just because coroutine-closure kind is ↵Michael Goulet-2/+11
assigned
2024-04-08Auto merge of #122077 - oli-obk:eager_opaque_checks4, r=lcnrbors-9/+5
Pass list of defineable opaque types into canonical queries This eliminates `DefiningAnchor::Bubble` for good and brings the old solver closer to the new one wrt cycles and nested obligations. At that point the difference between `DefiningAnchor::Bind([])` and `DefiningAnchor::Error` was academic. We only used the difference for some sanity checks, which actually had to be worked around in places, so I just removed `DefiningAnchor` entirely and just stored the list of opaques that may be defined. fixes #108498 fixes https://github.com/rust-lang/rust/issues/116877 * [x] run crater - https://github.com/rust-lang/rust/pull/122077#issuecomment-2013293931
2024-04-08Avoid fetching the opaque type origin when only "is this in the defining ↵Oli Scherer-7/+4
scope" is actually needed
2024-04-08Eliminate `DefiningAnchor` now that is just a single-variant enumOli Scherer-1/+1
2024-04-08Pass list of defineable opaque types into canonical queriesOli Scherer-2/+1
2024-04-08Actually create ranged int types in the type system.Oli Scherer-1/+16
2024-04-04Rollup merge of #123477 - lcnr:forced_ambig-no-ice, r=compiler-errorsJacob Pratt-3/+10
do not ICE in `fn forced_ambiguity` if we get an error see the comment. currently causing an ICE in typenum which we've been unable to minimize. r? `@compiler-errors`
2024-04-04Rollup merge of #123464 - fmease:rn-has-proj-to-has-aliases, r=compiler-errorsJacob Pratt-2/+2
Cleanup: Rename `HAS_PROJECTIONS` to `HAS_ALIASES` etc. The name of the bitflag `HAS_PROJECTIONS` and of its corresponding method `has_projections` is quite historical dating back to a time when projections were the only kind of alias type. I think it's time to update it to clear up any potential confusion for newcomers and to reduce unnecessary friction during contributor onboarding. r? types
2024-04-04Rollup merge of #123363 - lcnr:normalizes-to-zero-to-inf, r=BoxyUwUJacob Pratt-257/+138
change `NormalizesTo` to fully structurally normalize notes in https://hackmd.io/wZ016dE4QKGIhrOnHLlThQ need to also update the dev-guide once this PR lands. in short, the setup is now as follows: `normalizes-to` internally implements one step normalization, applying that normalization to the `goal.predicate.term` causes the projected term to get recursively normalized. With this `normalizes-to` normalizes until the projected term is rigid, meaning that we normalize as many steps necessary, but at least 1. To handle rigid aliases, we add another candidate only if the 1 to inf step normalization failed. With this `normalizes-to` is now full structural normalization. We can now change `AliasRelate` to simply emit `normalizes-to` goals for the rhs and lhs. This avoids the concerns from https://github.com/rust-lang/trait-system-refactor-initiative/issues/103 and generally feels cleaner
2024-04-05do not ICE in forced ambiguity if we get an errorlcnr-3/+10
2024-04-04Rename HAS_PROJECTIONS to HAS_ALIASES etc.León Orell Valerian Liehr-2/+2
2024-04-04normalizes-to change from '1' to '0 to inf' stepslcnr-237/+136
2024-04-04Use `DefineOpaqueTypes::Yes` where the new solver is unconditionally used ↵Oli Scherer-8/+16
already
2024-04-04unconstrained `NormalizesTo` term for opaqueslcnr-27/+9
2024-04-03Uplift and start using check_args_compatible more liberallyMichael Goulet-2/+2
2024-03-22Auto merge of #122900 - matthiaskrgr:rollup-nls90mb, r=matthiaskrgrbors-33/+35
Rollup of 8 pull requests Successful merges: - #114009 (compiler: allow transmute of ZST arrays with generics) - #122195 (Note that the caller chooses a type for type param) - #122651 (Suggest `_` for missing generic arguments in turbofish) - #122784 (Add `tag_for_variant` query) - #122839 (Split out `PredicatePolarity` from `ImplPolarity`) - #122873 (Merge my contributor emails into one using mailmap) - #122885 (Adjust better spastorino membership to triagebot's adhoc_groups) - #122888 (add a couple more tests) r? `@ghost` `@rustbot` modify labels: rollup
2024-03-22Split out ImplPolarity and PredicatePolarityMichael Goulet-33/+35
2024-03-22Programmatically convert some of the pat ctorsMichael Goulet-7/+7
2024-03-22Update (doc) commentsLeón Orell Valerian Liehr-1/+1
Several (doc) comments were super outdated or didn't provide enough context. Some doc comments shoved everything in a single paragraph without respecting the fact that the first paragraph should be a single sentence because rustdoc treats these as item descriptions / synopses on module pages.
2024-03-22Rollup merge of #122829 - ShoyuVanilla:gen-block-impl-fused-iter, ↵Matthias Krüger-0/+38
r=compiler-errors Implement `FusedIterator` for `gen` block cc #117078
2024-03-22Implement `FusedIterator` for `gen` blockShoyu Vanilla-0/+38
2024-03-21Rollup merge of #122358 - compiler-errors:bound-regions-in-generator, r=lcnrMatthias Krüger-31/+5
Don't ICE when encountering bound regions in generator interior type I'm pretty sure this meant to say "`has_free_regions`", probably just a typo in 4a4fc3bb5b1efe6857cf5d6c0b554ff36b966996. We can have bound regions (because we only convert non-bound regions into existential regions in generator interiors), but we can't have (non-ReErased) free regions. r? lcnr
2024-03-19Only split by-ref/by-move futures for async closuresMichael Goulet-1/+1
2024-03-19Do binder folding eagerly in bound_coroutine_hidden_typesMichael Goulet-30/+5
I refuse to fix this in the old solver; its lazy instantiation of binders will be the end of me.
2024-03-19Don't ICE when encountering bound regions in generator interior typeMichael Goulet-1/+0
2024-03-19Auto merge of #122493 - lukas-code:sized-constraint, r=lcnrbors-7/+19
clean up `Sized` checking This PR cleans up `sized_constraint` and related functions to make them simpler and faster. This should not make more or less code compile, but it can change error output in some rare cases. ## enums and unions are `Sized`, even if they are not WF The previous code has some special handling for enums, which made them sized if and only if the last field of each variant is sized. For example given this definition (which is not WF) ```rust enum E<T1: ?Sized, T2: ?Sized, U1: ?Sized, U2: ?Sized> { A(T1, T2), B(U1, U2), } ``` the enum was sized if and only if `T2` and `U2` are sized, while `T1` and `T2` were ignored for `Sized` checking. After this PR this enum will always be sized. Unsized enums are not a thing in Rust and removing this special case allows us to return an `Option<Ty>` from `sized_constraint`, rather than a `List<Ty>`. Similarly, the old code made an union defined like this ```rust union Union<T: ?Sized, U: ?Sized> { head: T, tail: U, } ``` sized if and only if `U` is sized, completely ignoring `T`. This just makes no sense at all and now this union is always sized. ## apply the "perf hack" to all (non-error) types, instead of just type parameters This "perf hack" skips evaluating `sized_constraint(adt): Sized` if `sized_constraint(adt): Sized` exactly matches a predicate defined on `adt`, for example: ```rust // `Foo<T>: Sized` iff `T: Sized`, but we know `T: Sized` from a predicate of `Foo` struct Foo<T /*: Sized */>(T); ``` Previously this was only applied to type parameters and now it is applied to every type. This means that for example this type is now always sized: ```rust // Note that this definition is WF, but the type `S<T>` not WF in the global/empty ParamEnv struct S<T>([T]) where [T]: Sized; ``` I don't anticipate this to affect compile time of any real-world program, but it makes the code a bit nicer and it also makes error messages a bit more consistent if someone does write such a cursed type. ## tuples are sized if the last type is sized The old solver already has this behavior and this PR also implements it for the new solver and `is_trivially_sized`. This makes it so that tuples work more like a struct defined like this: ```rust struct TupleN<T1, T2, /* ... */ Tn: ?Sized>(T1, T2, /* ... */ Tn); ``` This might improve the compile time of programs with large tuples a little, but is mostly also a consistency fix. ## `is_trivially_sized` for more types This function is used post-typeck code (borrowck, const eval, codegen) to skip evaluating `T: Sized` in some cases. It will now return `true` in more cases, most notably `UnsafeCell<T>` and `ManuallyDrop<T>` where `T.is_trivially_sized`. I'm anticipating that this change will improve compile time for some real world programs.
2024-03-18address nitsLukas Markeffsky-4/+5
2024-03-18Rollup merge of #122687 - lcnr:normalizes-to-emit-nested-goals, ↵Matthias Krüger-156/+189
r=compiler-errors `NormalizesTo`: return nested goals to caller Fixes the regression of `paperclip-core`. see https://hackmd.io/IsVAafiOTAaPIFcUxRJufw for more details. r? ```@compiler-errors```
2024-03-18cleanup + reviewlcnr-22/+27
2024-03-18`NormalizesTo` return nested goalslcnr-72/+107
2024-03-18move `normalizes_to_hack` to `AliasRelate`lcnr-67/+60
2024-03-18Avoid various uses of `Option<Span>` in favor of using `DUMMY_SP` in the few ↵Oli Scherer-1/+1
cases that used `None`
2024-03-14remove unnecessary sized checksLukas Markeffsky-3/+4
2024-03-14clean up ADT sized constraint computationLukas Markeffsky-2/+12
2024-03-14Rollup merge of #122238 - fee1-dead-contrib:builtin-impl-next-solver-dox, r=lcnrMatthias Krüger-0/+18
Document some builtin impls in the next solver This does not cover all builtin impls, but ones that I were able to go over within a cycle. r? `@lcnr` Let me know if the place isn't correct for these, or if you'd like me to change how the impls are presented ^^
2024-03-14move impl documentation to their actual locationsDeadbeef-33/+12
2024-03-12Rollup merge of #122319 - ↵Matthias Krüger-1/+3
compiler-errors:next-solver-normalizing-self-constrains-args, r=lcnr Don't ICE when non-self part of trait goal is constrained in new solver Self-explanatory. See test for example when this can happen.
2024-03-11Don't ICE when non-self part of trait goal is constrained in new solverMichael Goulet-1/+3
2024-03-11Eliminate `DefiningAnchor::Error`, it is indistinguishable from ↵Oli Scherer-5/+2
`DefiningAnchor::Bind` with an empty list
2024-03-10fix metadata for dyn-star in new solverLukas Markeffsky-2/+3
2024-03-09Document some builtin impls in the next solverDeadbeef-0/+39
2024-03-07Apply `EarlyBinder` only to `TraitRef` in `ImplTraitHeader`Yoshitomo Nakanishi-6/+6
2024-03-06remove outdated fixme commentDeadbeef-1/+0
The `TraitPredicate` no longer has constness as we have desugared it to work with the type system through const generics instead.
2024-03-05Convert `ProofTreeVisitor` to use `VisitorResult`Jason Newcomb-24/+23
2024-03-05Convert `TypeVisitor` and `DefIdVisitor` to use `VisitorResult`Jason Newcomb-3/+3
2024-03-02avoid collecting into vecs in some placesMatthias Krüger-1/+1