| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Some cleanups in our normalization logic
Changed a match to be exhaustive and deduplicated some code.
r? ```@compiler-errors```
this pulls out the uncontroversial part of https://github.com/rust-lang/rust/pull/108860
|
|
make `define_opaque_types` fully explicit
based on the idea of #108389. Moved `define_opaque_types` into the actual operations, e.g. `eq`, instead of `infcx.at` because normalization doesn't use `define_opaque_types` and even creates it's own `At` with a different `define_opaque_types` internally.
Somewhat surprisingly, coherence actually relies on `DefineOpaqueTypes::Yes` for soundness which was revealed because I've incorrectly used `DefineOpaqueTypes::No` in `equate_impl_headers`. It feels concerning that even though this is the case, we still sometimes use `DefineOpaqueTypes::No` in coherence. I did not look into this as part of this PR as it is purely changing the structure of the code without changing behavior in any way.
r? ```@oli-obk```
|
|
|
|
|
|
This reverts commit e84e5ff04a647ce28540300244a26ba120642eea, reversing
changes made to 1716932743a7b3705cbf0c34db0c4e070ed1930d.
|
|
|
|
bound vars
|
|
|
|
remove obsolete `givens` from regionck
Fixes #106567
r? `@lcnr` (feel free to reassign)
|
|
|
|
Remove some direct calls to local_def_id_to_hir_id on diagnostics
Was playing with `tests/ui/impl-trait/in-trait/default-body-with-rpit.rs` and was able to remove some ICEs. Still getting ...
```
error[E0277]: `impl Future<Output = Foo::{opaque#0}>` is not a future
--> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
|
10 | async fn baz(&self) -> impl Debug {
| ^^^^^^^^^^ `impl Future<Output = Foo::{opaque#0}>` is not a future
|
= help: the trait `Future` is not implemented for `impl Future<Output = Foo::{opaque#0}>`
= note: impl Future<Output = Foo::{opaque#0}> must be a future or must implement `IntoFuture` to be awaited
note: required by a bound in `Foo::{opaque#1}`
--> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
|
10 | async fn baz(&self) -> impl Debug {
| ^^^^^^^^^^ required by this bound in `Foo::{opaque#1}`
error[E0277]: the size for values of type `impl Future<Output = Foo::{opaque#0}>` cannot be known at compilation time
--> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
|
10 | async fn baz(&self) -> impl Debug {
| ^^^^^^^^^^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `impl Future<Output = Foo::{opaque#0}>`
note: required by a bound in `Foo::{opaque#1}`
--> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:28
|
10 | async fn baz(&self) -> impl Debug {
| ^^^^^^^^^^ required by this bound in `Foo::{opaque#1}`
error: internal compiler error: compiler/rustc_hir_typeck/src/closure.rs:724:18: async fn generator return type not an inference variable: Foo::{opaque#1}<'_>
--> tests/ui/impl-trait/in-trait/default-body-with-rpit.rs:10:39
|
10 | async fn baz(&self) -> impl Debug {
| _______________________________________^
11 | | ""
12 | | }
| |_____^
```
But I guess this is a little bit of progress anyway.
This one goes on top of #108700 and #108945
r? `@compiler-errors`
|
|
Fix object safety checks for new RPITITs
This one goes on top of #108869
r? `@compiler-errors`
|
|
|
|
Remove `identity_future` indirection
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]`annotation.
Fixes https://github.com/rust-lang/rust/issues/104826.
|
|
|
|
|
|
Use `TyCtxt::trait_solver_next` in some places
Also flip order of if statements to avoid `!`
|
|
|
|
|
|
Add suggestion to diagnostic when user has array but trait wants slice. (rebased)
Rebase of #91314, except for change to multipart suggestion
Resolves #90528
r? ``@compiler-errors`` since you requested the multipart suggestion
|
|
tidy: enforce comment blocks to have an even number of backticks
After PR #108694, most unmatched backticks in `compiler/` comments have been eliminated. This PR adds a tidy lint to ensure no new unmatched backticks are added, and either addresses the lint in the remaining instances it found, or allows it.
Very often, backtick containing sections wrap around lines, for example:
```Rust
// This function takes a tuple `(Vec<String>,
// Box<[u8]>)` and transforms it into `Vec<u8>`.
```
The lint is implemented to work on top of blocks, counting each line with a `//` into a block, and counting if there are an odd or even number of backticks in the entire block, instead of looking at just a single line.
|
|
|
|
|
|
Implement goal caching with the new solver
Maybe it's wrong, idk. Opening mostly for first impressions before I go to sleep.
r? ``@lcnr,`` cc ``@cjgillot``
|
|
|
|
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes #108781
|
|
improve readability of winnowing
|
|
Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type
We never supported solving `for<'a> fn(&'a ()): Fn(&'a ())` -- I tried to add that support in #104929, but iirc `@lcnr` wanted to support this more generally by eagerly instantiating trait predicate binders with placeholders. That never happened due to blockers in the old solver, but we probably shouldn't ICE in any case.
On the bright side, this passes on the new solver :^)
|
|
Co-authored-by: Ruby Lazuli <general@patchmixolydic.com>
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous
Fixes #108721
The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:
https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/traits/select/mod.rs#L596-L606
... Compared to the analogous loop in the new solver:
https://github.com/rust-lang/rust/blob/f15f0ea73972786e426732c5b92ba9a904b866c4/compiler/rustc_trait_selection/src/solve/mod.rs#L481-L512
To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.
--
Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/
r? types
|
|
fix: evaluate with wrong obligation stack
fix #108897
r? ``@lcnr``
|
|
Suppress copy impl error when post-normalized type references errors
Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization.
----
The const-generics test regressed recently due to #107965, cc `````@BoxyUwU.`````
* I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails.
* It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
|
|
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
|
|
always resolve to universal regions if possible
`RegionConstraintCollector::opportunistic_resolve_var`, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated `'static == '1 == '2`, it doesn't resolve `'1` or `'2` to `'static`. Now it does!
Addresses review comment https://github.com/rust-lang/rust/pull/107376#discussion_r1093233687.
r? `@lcnr`
|
|
|
|
|
|
For #90528.
|
|
self type
|
|
Fix `ObligationCtxt::sub`
typo it seems
|
|
compiler-errors:rpitit-dont-project-default-w-no-valu, r=cjgillot
Don't project to RPITIT that has no default value
Replicates this behavior, but for RPITIT projection logic (which currently is separate)
https://github.com/rust-lang/rust/blob/b1719530f44e3c8ec903f76020a52bd8764d5d10/compiler/rustc_trait_selection/src/traits/project.rs#L2105-L2115
Fixes #108738
|
|
compiler-errors:non_lifetime_binders-bad-copy-clone, r=jackh726
Don't ICE when encountering bound var in builtin copy/clone bounds
Fixes #108742
|
|
rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
|
|
|
