about summary refs log tree commit diff
path: root/compiler/rustc_next_trait_solver/src
AgeCommit message (Collapse)AuthorLines
2025-05-27Make some assertions in solver into debug assertionsMichael Goulet-11/+12
2025-05-27Fix some var namesMichael Goulet-2/+2
2025-05-26Auto merge of #141605 - jieyouxu:rollup-3gjqh5l, r=jieyouxubors-1/+1
Rollup of 10 pull requests Successful merges: - rust-lang/rust#140898 (minor improvements on running miri) - rust-lang/rust#141392 (Avoid obligation construction dance with query region constraints) - rust-lang/rust#141431 (Emit dummy open drop for unsafe binder) - rust-lang/rust#141433 (Properly analyze captures from unsafe binders) - rust-lang/rust#141439 (Deduplicate dyn compatibility violations due to coercion) - rust-lang/rust#141449 (further deduplicate ast visitor code) - rust-lang/rust#141513 (interpret: add allocation parameters to `AllocBytes`) - rust-lang/rust#141516 (speed up charsearcher for ascii chars) - rust-lang/rust#141526 (add a dedicated section for compiler environment variables in the unstable book) - rust-lang/rust#141550 (Fix `unused_braces` lint suggestion when encountering attributes) r? `@ghost` `@rustbot` modify labels: rollup
2025-05-26assert we never incorrectly canonicalize envslcnr-0/+7
2025-05-26add additional `TypeFlags` fast pathslcnr-8/+43
2025-05-27Rollup merge of #141392 - compiler-errors:query-outlives, r=lcnr许杰友 Jieyou Xu (Joe)-1/+1
Avoid obligation construction dance with query region constraints And some renaming...
2025-05-26Auto merge of #141500 - compiler-errors:rerun-cache-2, r=lcnrbors-31/+132
Don't rerun goals if none of their vars have changed r? `@ghost` Alternative to rust-lang/rust#141488. I'm pretty sure that we don't need to re-run the goal at all if the inputs don't change... 🤔
2025-05-26Don't rerun goals if none of its vars have changedMichael Goulet-31/+132
2025-05-26RenameMichael Goulet-1/+1
2025-05-25Do not canonicalize in new solver if it has nothing to canonicalizeMichael Goulet-8/+55
2025-05-23yeet `CanonicalVarInfo`lcnr-40/+41
2025-05-22Auto merge of #141396 - matthiaskrgr:rollup-feg050g, r=matthiaskrgrbors-2/+2
Rollup of 7 pull requests Successful merges: - #135562 (Add ignore value suggestion in closure body) - #139635 (Finalize repeat expr inference behaviour with inferred repeat counts) - #139668 (Handle regions equivalent to 'static in non_local_bounds) - #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths) - #140435 (use uX::from instead of _ as uX in non - const contexts) - #141130 (rustc_on_unimplemented cleanups) - #141286 (Querify `coroutine_hidden_types`) Failed merges: - #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs) r? `@ghost` `@rustbot` modify labels: rollup
2025-05-22Auto merge of #141397 - matthiaskrgr:rollup-l9uu6g6, r=matthiaskrgrbors-1/+1
Rollup of 8 pull requests Successful merges: - #141355 (ci: improve citool job db errors) - #141359 (Fix `FnOnce` impl for `AsyncFn`/`AsyncFnMut` self-borrowing closures in new solver) - #141362 (Normalize aliases to correct kind of error term) - #141377 (Remove unnecessary `is_empty` checks) - #141381 (try_cast_aligned: avoid bare int-to-ptr casts) - #141382 (ci: convert distcheck to free runner) - #141389 (ci: prepare aws access keys for migration) - #141390 (Don't allow `poly_select` in new solver) r? `@ghost` `@rustbot` modify labels: rollup
2025-05-22Rollup merge of #141359 - compiler-errors:async-fn-once, r=lcnrMatthias Krüger-1/+1
Fix `FnOnce` impl for `AsyncFn`/`AsyncFnMut` self-borrowing closures in new solver This only affects closures that are "`AsyncFn`/`AsyncFnMut`" in their calling capability that are being called with the `FnOnce` trait. fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/217 r? lcnr
2025-05-22Rollup merge of #141286 - compiler-errors:querify-coroutine, r=oli-obkMatthias Krüger-2/+2
Querify `coroutine_hidden_types` This is necessary if we ever want to add implied bounds that would be used for higher-ranked coroutine auto trait goals (e.g. future implements `Send`). Modest perf regression in `hyper` full build which (afaict?) is the only async stress test, so definitely worth it IMO. r? oli-obk
2025-05-22Auto merge of #141135 - compiler-errors:fast-path-2, r=lcnrbors-4/+23
Fast path for processing some obligations in the new solver Fast path applies to: - Dyn compatibility predicates - Region and type outlives predicates - Trivially sized predicates
2025-05-21Fix FnOnce impl for AsyncFn/AsyncFnMut closures in new solverMichael Goulet-1/+1
2025-05-21fix better_any breakage by making the solver more unsoundlcnr-2/+42
2025-05-20Querify coroutine_hidden_typesMichael Goulet-2/+2
2025-05-18Fast path for processing some obligations in the new solverMichael Goulet-4/+23
2025-05-15Rollup merge of #140712 - lcnr:normalization-gat-args, r=compiler-errorsMatthias Krüger-27/+61
normalization: avoid incompletely constraining GAT args We need to copy the behavior of #125214 in the new solver. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/202 which seems to be the cause of the regression in `deptypes`. r? ```@compiler-errors```
2025-05-12Fix typosomahs-1/+1
2025-05-08refactor `probe_and_consider_param_env_candidate`lcnr-15/+14
2025-05-08normalization: avoid incompletely constraining GAT argslcnr-19/+54
2025-05-08Rollup merge of #140711 - compiler-errors:combine-maybes, r=lcnrMatthias Krüger-14/+19
Do not discard constraints on overflow if there was candidate ambiguity Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/201. There's a pretty chunky justification in the test. r? lcnr
2025-05-08Rollup merge of #140641 - lcnr:opaque-type-storage-entries, r=compiler-errorsMatthias Krüger-76/+44
detect additional uses of opaques after writeback Based on #140607. It's a lot harder to encounter in practice than I though :sweat_smile: :grin: I've still added it with the expectation that somebody will encounter it at some point. Also modifies the `EvalCtxt` to use the same impl to detect newly added opaque types. r? ``@compiler-errors``
2025-05-07detect additional uses of opaques after writebacklcnr-54/+44
2025-05-07opaque_type_storage to InferCtxtLikelcnr-22/+0
2025-05-07Use MaybeCause::or to allow constraints from overflows if they are combined ↵Michael Goulet-14/+19
with ambiguity
2025-05-07ReviewMichael Goulet-21/+27
2025-05-07Only prefer param-env candidates if they remain non-global after normMichael Goulet-125/+243
2025-05-06support duplicates in the opaque_types_storagelcnr-26/+65
2025-05-01Set groundwork for proper const normalizationBoxy-11/+28
2025-04-29Treat `ManuallyDrop` as `~const Destruct`Oli Scherer-0/+3
2025-04-28Rollup merge of #140402 - lcnr:normalizes-to-certainty-yes, r=compiler-errorsChris Denton-32/+66
only return nested goals for `Certainty::Yes` Ambiguous `NormalizesTo` goals can otherwise repeatedly add the same nested goals to the parent. r? ```@compiler-errors```
2025-04-28Rollup merge of #140276 - compiler-errors:typeof-less-eagerly, r=lcnrChris Denton-0/+6
Do not compute type_of for impl item if impl where clauses are unsatisfied Consider the following code: ```rust trait Foo { fn call(self) -> impl Send; } trait Nested {} impl<T> Foo for T where T: Nested, { fn call(self) -> impl Sized { NotSatisfied.call() } } struct NotSatisfied; impl Foo for NotSatisfied { fn call(self) -> impl Sized { todo!() } } ``` In `impl Foo for NotSatisfied`, we need to prove that the RPITIT is well formed. This requires proving the item bound `<NotSatisfied as Foo>::RPITIT: Send`. Normalizing `<NotSatisfied as Foo>::RPITIT: Send` assembles two impl candidates, via the `NotSatisfied` impl and the blanket `T` impl. We end up computing the `type_of` for the blanket impl even if `NotSatisfied: Nested` where clause does not hold. This type_of query ends up needing to prove that its own `impl Sized` RPIT satisfies `Send`, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type of `NotSatisfied.call()`. That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again! In the old solver, we don't end up computing the `type_of` an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate: https://github.com/rust-lang/rust/blob/d7ea436a02d5de4033fcf7fd4eb8ed965d0f574c/compiler/rustc_trait_selection/src/traits/project.rs#L882 This PR makes the new solver more consistent with the old solver by adding a call to `try_evaluate_added_goals` after regstering the impl predicates, which causes us to bail before computing the `type_of` for impls if the impl definitely doesn't apply. r? lcnr Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/185
2025-04-28Auto merge of #140388 - GuillaumeGomez:rollup-aj9o3ch, r=GuillaumeGomezbors-11/+11
Rollup of 7 pull requests Successful merges: - #140056 (Fix a wrong error message in 2024 edition) - #140220 (Fix detection of main function if there are expressions around it) - #140249 (Remove `weak` alias terminology) - #140316 (Introduce `BoxMarker` to improve pretty-printing correctness) - #140347 (ci: clean more disk space in codebuild) - #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job) - #140379 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-28Do not compute type_of for impl item if impl where clauses are unsatisfiedMichael Goulet-0/+6
2025-04-28reviewlcnr-19/+29
2025-04-28only return nested goals for `Certainty::Yes`lcnr-18/+42
2025-04-28Rollup merge of #140249 - BoxyUwU:remove_weak_alias_terminology, r=oli-obkGuillaume Gomez-11/+11
Remove `weak` alias terminology I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust. It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*. I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-) r? `@oli-obk` maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
2025-04-28AsyncDrop implementation using shim codegen of ↵Andrew Zhogin-88/+0
async_drop_in_place::{closure}, scoped async drop added.
2025-04-26Rollup merge of #140320 - lcnr:wf-use-term, r=compiler-errorsMatthias Krüger-6/+6
replace `GenericArg` with `Term` where applicable r? types
2025-04-26convert some `GenericArg` to `Term`lcnr-6/+6
2025-04-25handle specialization in the new trait solverlcnr-14/+111
uwu :3
2025-04-24norm nested aliases before evaluating the parent goallcnr-139/+89
2025-04-24Remove `weak` alias terminologyBoxy-11/+11
2025-04-24Rollup merge of #140214 - compiler-errors:remove-hack, r=lcnrMatthias Krüger-12/+0
Remove comment about handling non-global where bounds with corresponding projection This comment is no longer relevant since we only assemble rigid projections if no param-env candidates hold. Also remove a stray comment from the old solver. r? lcnr
2025-04-23Remove hackMichael Goulet-12/+0
2025-04-23MoreMichael Goulet-34/+33