| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=lcnr
Winnow specialized impls during selection in new solver
We need to be able to winnow impls that are specialized by more specific impls in order for codegen to be able to proceed.
r? ``@lcnr``
|
|
Effects/keyword generics MVP
This adds `feature(effects)`, which adds `const host: bool` to the generics of const functions, const traits and const impls. This will be used to replace the current logic around const traits.
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The `FnAbi` is just a pointer, so the error type should not be bigger.
|
|
`LayoutError` is 24 bytes, which is bigger than the `Ok` types, so let's
shrink that.
|
|
|
|
Avoid calling queries during query stack printing
This has the side effect, that when Clippy should ICE (during an EarlyPass?) it will fill up the RAM with 2 GB/s and then freezes my Laptop. This is blocking the Clippy sync and might give some people really bad experiences, so this should be merged ASAP.
r? `@cjgillot`
cc `@Zoxc`
I only commented this on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60try_print_query_stack.60.20has.20.60ImplicitCtx.60.20during.20.60EarlyPass.60/near/363926180). I should've left a comment on the PR as well. My bad.
|
|
|
|
Normalize types when applying uninhabited predicate.
Fixes https://github.com/rust-lang/rust/issues/112997
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
Various impl trait in assoc tys cleanups
r? `@compiler-errors`
All commits except for the last are pure refactorings. 274dab5bd658c97886a8987340bf50ae57900c39 allows struct fields to participate in deciding whether a function has an opaque in its signature.
best reviewed commit by commit
|
|
Migrate `item_bounds` to `ty::Clause`
Should be simpler than the next PR that's coming up. Last three commits are the relevant ones.
r? ``@oli-obk`` or ``@lcnr``
|
|
Don't ICE on unnormalized struct tail in layout computation
1. We try to compute a `SizeSkeleton` even if a layout error occurs, but we really only need to do this if we get `LayoutError::Unknown`, since that means our type is too polymorphic to actually compute the full layout. If we have other errors, like `LayoutError::NormalizationError` or `LayoutError::Cycle`, then we can't really make any progress, since this represents an actual error.
2. Avoid using `normalize_erasing_regions` and `struct_tail_erasing_lifetimes` since those ICE on normalization errors, and since we may call `layout_of` in HIR typeck, we don't know for certain that we're on the happy path.
Fixes #112736
|
|
|
|
|
|
|
|
open coded
|
|
|
|
Add a fully fledged `Clause` type, rename old `Clause` to `ClauseKind`
Does two basic things before I put up a more delicate set of PRs (along the lines of #112714, but hopefully much cleaner) that migrate existing usages of `ty::Predicate` to `ty::Clause` (`predicates_of`/`item_bounds`/`ParamEnv::caller_bounds`).
1. Rename `Clause` to `ClauseKind`, so it's parallel with `PredicateKind`.
2. Add a new `Clause` type which is parallel to `Predicate`.
* This type exposes `Clause::kind(self) -> Binder<'tcx, ClauseKind<'tcx>>` which is parallel to `Predicate::kind` 😸
The new `Clause` type essentially acts as a newtype wrapper around `Predicate` that asserts that it is specifically a `PredicateKind::Clause`. Turns out from experimentation[^1] that this is not negative performance-wise, which is wonderful, since this a much simpler design than something that requires encoding the discriminant into the alignment bits of a predicate kind, or something else like that...
r? ``@lcnr`` or ``@oli-obk``
[^1]: https://github.com/rust-lang/rust/pull/112714#issuecomment-1595653910
|
|
Make closure_saved_names_of_captured_variables a query.
As we will start removing debuginfo during MIR optimizations, we need to keep them somewhere.
|
|
Merge `BorrowKind::Unique` into `BorrowKind::Mut`
Fixes #112072
Might have conflict with #112070
r? `@lcnr`
I'm not sure what's the suitable change in a couple places.
|
|
|
|
change binders from tuple structs to named fields
|
|
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
https://github.com/rust-lang/rust/blob/2f896da247e0ee8f0bef7cd7c54cfbea255b9f68/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L61-L132
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make `Bound::predicates` use `Clause`
Part of #107250
`Bound::predicates` returns an iterator over `Binder<_, Clause>` instead of `Predicate`.
I tried updating `explicit_predicates_of` as well, but it seems that it needs a lot more change than I thought. Will do it in a separate PR instead.
|
|
|
|
|
|
|
