about summary refs log tree commit diff
path: root/compiler/rustc_trait_selection/src/solve/trait_goals
AgeCommit message (Collapse)AuthorLines
2023-04-10move `structural_traits` into `assembly`lcnr-413/+0
2023-04-06Remove u32 on BoundTyKind::AnonJack Huey-5/+3
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-05Implement support for GeneratorWitnessMIR in new solverMichael Goulet-3/+46
2023-03-30Closures always implement FnOnce in new solverMichael Goulet-3/+14
2023-03-21Rollup merge of #109441 - oli-obk:fn_trait_new_solver, r=compiler-errorsMatthias Krüger-6/+22
Only implement Fn* traits for extern "Rust" safe function pointers and items Since calling the function via an `Fn` trait will assume `extern "Rust"` ABI and not do any safety checks, only safe `extern "Rust"` function can implement the `Fn` traits. This syncs the logic between the old solver and the new solver. r? `@compiler-errors`
2023-03-21Also check function items' signatures for Fn* trait compatibilityOli Scherer-5/+14
2023-03-21Deduplicate fn trait compatibility checksOli Scherer-8/+1
2023-03-21Only implement Fn* traits for extern "Rust" safe function pointers.Oli Scherer-1/+15
2023-03-16replace usage of `evaluate_goal` with a new `add_goal`Boxy-1/+1
2023-02-26Rollup merge of #107941 - compiler-errors:str-has-u8-slice-for-auto, r=lcnrMatthias Krüger-1/+3
Treat `str` as containing `[u8]` for auto trait purposes Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes. ``@dtolnay`` brought this up in https://github.com/rust-lang/rust/issues/13231#issuecomment-1399386472 as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (#107939), but this probably should be considered in the mean time regardless of that PR. r? types for the impl, though this definitely needs an FCP.
2023-02-25Treat `str` as containing `[u8]` for auto trait purposesMichael Goulet-1/+3
2023-02-25Rollup merge of #108333 - compiler-errors:new-solver-object-sound, r=lcnrMichael Goulet-2/+112
Make object bound candidates sound in the new trait solver r? `@lcnr`
2023-02-24Comments, another testMichael Goulet-2/+41
2023-02-24Make higher-ranked projections in object types work in new solverMichael Goulet-16/+27
2023-02-24Check object's supertrait and associated type bounds in new solverMichael Goulet-1/+61
2023-02-24Rename many interner functions.Nicholas Nethercote-4/+2
(This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
2023-02-22Move some InferCtxt methods to EvalCtxt in new solverMichael Goulet-14/+12
2023-02-17Replace `mk_foo` calls with `infer_foo` where possible.Nicholas Nethercote-2/+2
There are several `mk_foo`/`intern_foo` pairs, where the former takes an iterator and the latter takes a slice. (This naming convention is bad, but that's a fix for another PR.) This commit changes several `mk_foo` occurrences into `intern_foo`, avoiding the need for some `.iter()`/`.into_iter()` calls. Affected cases: - mk_type_list - mk_tup - mk_substs - mk_const_list
2023-02-16remove bound_type_of query; make type_of return EarlyBinder; change type_of ↵Kyle Matsuda-1/+1
in metadata
2023-02-07Replacing bound vars is actually instantiating a binderMichael Goulet-2/+2
2023-01-27Introduce GeneratorWitnessMIR.Camille GILLOT-0/+6
2023-01-26fixup new usages of fn_sig, bound_fn_sig after rebasingKyle Matsuda-1/+1
2023-01-26Rollup merge of #107286 - compiler-errors:new-solver-deny-infers, r=lcnrMatthias Krüger-16/+23
ICE in new solver if we see an inference variable By construction, we do not expect to see any `ty::Infer(ty::TyVar(_))` inference types in the solver (we treat this as ambiguous, since we need to be able to structurally resolve the self type at least one layer to assemble candidates for it). Additionally, since we're doing no freshening, we also don't expect to see any fresh vars of any kind in the solver. Let's make that an ICE so we can catch any mistakes. When #107282 lands, we should also ICE there too if we see a non-int/float infer. r? `@lcnr`
2023-01-26ICE in new solver if we see an inference variableMichael Goulet-16/+23
2023-01-26Implement Generator and FutureMichael Goulet-0/+1
2023-01-19trait solver: Implement Fn traits and tuple traitMichael Goulet-1/+50
2023-01-19Fix IndexVec::drain_enumeratedMichael Goulet-10/+5
2023-01-18Handle structural traits more gracefullyMichael Goulet-0/+179