| Age | Commit message (Collapse) | Author | Lines |
|---|
|
bound_explicit_item_bounds usages; remove bound_explicit_item_bounds query
|
|
|
|
|
|
|
|
|
|
collect_return_position_impl_trait_in_trait_tys query; remove bound_X version
|
|
Rollup of 4 pull requests
Successful merges:
- #110397 (Move some utils out of `rustc_const_eval`)
- #110398 (use matches! macro in more places)
- #110400 (more clippy fixes: clippy::{iter_cloned_collect, unwarp_or_else_defau…)
- #110402 (Remove the loop in `Align::from_bytes`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
option_map_or_none}
|
|
This gets rid of a blocking dependency edge from
`rustc_lint->rustc_analysis->rustc_hir_typeck->rustc_interface`
|
|
- require `TypeErrCtxt` to always result in an error
- move `resolve_regions_and_report_errors` to the `ObligationCtxt`
- merge `process_registered_region_obligations` into `resolve_regions`
|
|
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.)
|
|
|
|
|
|
|
|
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
|
|
remove obsolete `givens` from regionck
Revives #107376. The only change is the last commit (https://github.com/rust-lang/rust/pull/109629/commits/2a3177a8bcc4c5a5285dc2908a0f1ce98e9a6377) which should fix the regression.
Fixes https://github.com/rust-lang/rust/issues/106567
r? `@lcnr`
|
|
Correctly substitute GAT's type used in `normalize_param_env` in `check_type_bounds`
Given:
```rust
trait Foo {
type Assoc<T>: PartialEq<Self::Assoc<i32>>;
}
impl Foo for () {
type Assoc<T> = Wrapper<T>;
}
struct Wrapper<T>(T);
impl<T> PartialEq<Wrapper<i32>> for Wrapper<T> { }
```
We add an additional predicate in the `normalize_param_env` in `check_type_bounds` that is used to normalize the GAT's bounds to check them in the impl. Problematically, though, that predicate is constructed to be `for<^0> <() as Foo>::Assoc<^0> => Wrapper<T>`, instead of `for<^0> <() as Foo>::Assoc<^0> => Wrapper<^0>`.
That means `Self::Assoc<i32>` in the bounds that we're checking normalizes to `Wrapper<T>`, instead of `Wrapper<i32>`, and so the bound `Self::Assoc<T>: PartialEq<Self::Assoc<i32>>` normalizes to `Wrapper<T>: PartialEq<Wrapper<T>>`, which does not hold.
Fixes this by properly substituting the RHS of that normalizes predicate that we add to the `normalize_param_env`. That means the bound is properly normalized to `Wrapper<T>: PartialEq<Wrapper<i32>>`, which *does* hold.
---
The second commit in this PR just cleans up some substs stuff and some naming.
r? `@jackh726` cc #87900
|
|
|
|
|
|
Deeply check well-formedness of return-position `impl Trait` in trait
Walk the bounds of RPITITs to see if we find any more RPITITs 😸
|
|
|
|
Do not consider synthesized RPITITs on missing items checks
Without this patch for `tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs` we get ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:4:12
|
4 | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`, ``
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:12:1
|
8 | fn foo(&self) -> impl Sized;
| ----------------------------
| | |
| | `` from trait
| `foo` from trait
...
12 | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo`, `` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
instead of ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/dont-project-to-rpitit-with-no-value.rs:4:12
|
LL | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`
--> $DIR/dont-project-to-rpitit-with-no-value.rs:12:1
|
LL | fn foo(&self) -> impl Sized;
| ---------------------------- `foo` from trait
...
LL | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
r? `@compiler-errors`
|
|
RPITITs are `DefKind::Opaque` with new lowering strategy
r? `@spastorino`
Kinda cherry-picked #109400
|
|
move Option::as_slice to intrinsic
````@scottmcm```` suggested on #109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation.
cc ````@nikic```` as this should hopefully unblock #107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
|
|
|
|
|
|
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
|
|
|
|
|
|
|
|
|
|
|
|
they add more complexity then they are worth. It's confusing
which of these helpers should be used in which context.
|
|
|
|
-Zlower-impl-trait-in-trait-to-assoc-ty
|
|
Install projection from RPITIT to default trait method opaque correctly
1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!
2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.
3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.
r? ````@spastorino,```` based off of #109140
|
|
Revert #107376 to fix potential `bincode` breakage and `rustc-perf` benchmark.
#107376 caused `rustc-perf`'s `webrender` benchmark to break, by regressing on the `bincode-1.3.3` crate.
~~This PR is a draft revert in case we can't land a fix soon enough, and we'd like to land the revert instead~~
(Though I myself think it'd be safer to do the revert, and run crater when relanding #107376.)
cc `@aliemjay`
|
|
type's param-env
|
|
|
|
|
|
This reverts commit e84e5ff04a647ce28540300244a26ba120642eea, reversing
changes made to 1716932743a7b3705cbf0c34db0c4e070ed1930d.
|
|
r=WaffleLapkin,JakobDegen
Ensure `ptr::read` gets all the same LLVM `load` metadata that dereferencing does
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`. Trying to narrow it down, it seems that was because `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.
The root cause is that `ptr::read` is currently implemented via the *untyped* `copy_nonoverlapping`, and thus the `load` doesn't get any type-aware metadata: no `noundef`, no `!range`. This PR solves that by lowering `ptr::read(p)` to `copy *p` in MIR, for which the backends already do the right thing.
Fortuitiously, this also improves the IR we give to LLVM for things like `mem::replace`, and fixes a couple of long-standing bugs where `ptr::read` on `Copy` types was worse than `*`ing them.
Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Move.20array.3A.3AIntoIter.20to.20ManuallyDrop/near/341189936>
cc `@erikdesjardins` `@JakobDegen` `@workingjubilee` `@the8472`
Fixes #106369
Fixes #73258
|
|
remove obsolete `givens` from regionck
Fixes #106567
r? `@lcnr` (feel free to reassign)
|
|
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`.
Turned out to be a more general problem as `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.
This PR lowers `ptr::read(p)` to `copy *p` in MIR, which fortuitiously also improves the IR we give to LLVM for things like `mem::replace`.
|
|
Make RPITITs simple cases work when using lower_impl_trait_in_trait_to_assoc_ty
r? `@compiler-errors`
It's probably best reviewed commit by commit.
|
|
|
|
|
|
Tweak E0740
Also drive-by suppress E0740 if it's an unresolved type.
|
|
Do not implement HashStable for HashSet (MCP 533)
This PR removes all occurrences of `HashSet` in query results, replacing it either with `FxIndexSet` or with `UnordSet`, and then removes the `HashStable` implementation of `HashSet`. This is part of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533), that is, removing the `HashStable` implementations of all collection types with unstable iteration order.
The changes are mostly mechanical. The only place where additional sorting is happening is in Miri's override implementation of the `exported_symbols` query.
|
|
|
