| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit 526090b901cbedcef7e1eec132e217917606a54d)
|
|
|
|
And suggest adding the `#[coroutine]` to the closure
|
|
Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq`
In `parse_seq`, when parsing a sequence of token-separated items, if we don't see a separator, we try to parse another item eagerly in order to give a good diagnostic and recover from a missing separator:
https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L900-L901
If parsing the item itself calls `expect_one_of`, then we will fatal because of #58903:
https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L513-L516
For `precise_capturing` feature I implemented, we do end up calling `expected_one_of`:
https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/ty.rs#L712-L714
This leads the compiler to fatal *before* having emitted the first error, leading to absolutely no useful information for the user about what happened in the parser.
This PR makes it so that we stop doing that.
Fixes #124195
|
|
|
|
|
|
fix normalizing in different `ParamEnv`s with the same `InferCtxt`
This PR changes the key of the projection cache from just `AliasTy` to `(AliasTy, ParamEnv)` to allow normalizing in different `ParamEnv`s without resetting caches. Previously, normalizing the same alias in different param envs would always reuse the cached result from the first normalization, which is incorrect if the projection clauses in the param env have changed.
Fixing this bug allows us to get rid of `InferCtxt::clear_caches`, which was only used by the `AutoTraitFinder`, because it requires normalizing in different param envs.
r? `@fmease`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
information about the defining anchor
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/123145
|
|
collector.rs:934:13 #105488
Fixes https://github.com/rust-lang/rust/issues/105488
|
|
change `NormalizesTo` to fully structurally normalize
notes in https://hackmd.io/wZ016dE4QKGIhrOnHLlThQ
need to also update the dev-guide once this PR lands. in short, the setup is now as follows:
`normalizes-to` internally implements one step normalization, applying that normalization to the `goal.predicate.term` causes the projected term to get recursively normalized. With this `normalizes-to` normalizes until the projected term is rigid, meaning that we normalize as many steps necessary, but at least 1.
To handle rigid aliases, we add another candidate only if the 1 to inf step normalization failed. With this `normalizes-to` is now full structural normalization. We can now change `AliasRelate` to simply emit `normalizes-to` goals for the rhs and lhs.
This avoids the concerns from https://github.com/rust-lang/trait-system-refactor-initiative/issues/103 and generally feels cleaner
|
|
some smaller DefiningOpaqueTypes::No -> Yes switches
r? `@compiler-errors`
These are some easy cases, so let's get them out of the way first.
I added tests exercising the specialization code paths that I believe weren't tested so far.
follow-up to https://github.com/rust-lang/rust/pull/117348
|
|
|
|
They are mostly used in diagnostics anyway
|
|
Add test for getting parent HIR for synthetic HIR node
Fixes #122991, which was actually fixed by #123415
|
|
|
|
|
|
|
|
r=compiler-errors,oli-obk
rework opaque type region inference
User-facing changes are documented in [this comment](https://github.com/rust-lang/rust/pull/116891#issuecomment-1973774412).
The design document is in [this comment](https://github.com/rust-lang/rust/pull/116891#issuecomment-1836900102).
---
\- Fix Ice in check_unique; ICE -> Error; fixes #122782.
\- Ignore uncaptured lifetime args; ICE -> Pass; fixes #111906, fixes #110623, fixes #109059, fixes #122307
\- Except equal parameters from the uniqueness check; Pass -> Error; fixes #113916.
\- Check RPITs for invalid args; Pass -> Error; fixes #111935; ICE -> Error; fixes #110726.
\- Rework opaque types region inference; Pass -> Error; fixes #113971, fixes #112841.
\- Reject external lifetimes as invalid args; Pass -> Error; fixes #105498.
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
|
|
compares `DefId`s which we need to avoid
|
|
|
|
expected ReFree to map to ReEarlyBound #108580
Fixes https://github.com/rust-lang/rust/issues/108580
|
|
add a couple more ice tests
Fixes rust-lang/rust#104779
Fixes rust-lang/rust#106423
Fixes rust-lang/rust#106444
Fixes rust-lang/rust#101852
Fixes rust-lang/rust#106874
Fixes rust-lang/rust#105047
Fixes rust-lang/rust#107228
Fixes rust-lang/rust#99945
|
|
Fixes #101852
|
|
|
|
Fixes #112823
|
|
Split an item bounds and an item's super predicates
This is the moral equivalent of #107614, but instead for predicates this applies to **item bounds**. This PR splits out the item bounds (i.e. *all* predicates that are assumed to hold for the alias) from the item *super predicates*, which are the subset of item bounds which share the same self type as the alias.
## Why?
Much like #107614, there are places in the compiler where we *only* care about super-predicates, and considering predicates that possibly don't have anything to do with the alias is problematic. This includes things like closure signature inference (which is at its core searching for `Self: Fn(..)` style bounds), but also lints like `#[must_use]`, error reporting for aliases, computing type outlives predicates.
Even in cases where considering all of the `item_bounds` doesn't lead to bugs, unnecessarily considering irrelevant bounds does lead to a regression (#121121) due to doing extra work in the solver.
## Example 1 - Trait Aliases
This is best explored via an example:
```
type TAIT<T> = impl TraitAlias<T>;
trait TraitAlias<T> = A + B where T: C;
```
The item bounds list for `Tait<T>` will include:
* `Tait<T>: A`
* `Tait<T>: B`
* `T: C`
While `item_super_predicates` query will include just the first two predicates.
Side-note: You may wonder why `T: C` is included in the item bounds for `TAIT`? This is because when we elaborate `TraitAlias<T>`, we will also elaborate all the predicates on the trait.
## Example 2 - Associated Type Bounds
```
type TAIT<T> = impl Iterator<Item: A>;
```
The `item_bounds` list for `TAIT<T>` will include:
* `Tait<T>: Iterator`
* `<Tait<T> as Iterator>::Item: A`
But the `item_super_predicates` will just include the first bound, since that's the only bound that is relevant to the *alias* itself.
## So what
This leads to some diagnostics duplication just like #107614, but none of it will be user-facing. We only see it in the UI test suite because we explicitly disable diagnostic deduplication.
Regarding naming, I went with `super_predicates` kind of arbitrarily; this can easily be changed, but I'd consider better names as long as we don't block this PR in perpetuity.
|
|
|
|
|
|
|
|
r=compiler-errors
Prevent opaque types being instantiated twice with different regions within the same function
addresses https://github.com/orgs/rust-lang/projects/22/views/1?pane=issue&itemId=41329537
r? `@compiler-errors`
|
|
misc cleanups from debugging something
rename `instantiate_canonical_with_fresh_inference_vars` to `instantiate_canonical` the substs for the canonical are not solely infer vars as that would be wildly wrong and it is rather confusing to see this method called and think that the entire canonicalization setup is completely broken when it is not :thumbsup:
also update region debug printing to be more like the custom impls for Ty/Const, right now regions in debug output are horribly verbose and make it incredibly hard to read but with this atleast boundvars and placeholders when debugging the new solver do not take up excessive amounts of space.
r? `@lcnr`
|
