Add new solver / old solver opaque type tests#118717
Draft
traviscross wants to merge 1 commit intorust-lang:mainfrom
Draft
Add new solver / old solver opaque type tests#118717traviscross wants to merge 1 commit intorust-lang:mainfrom
traviscross wants to merge 1 commit intorust-lang:mainfrom
Conversation
When considering an opaque type within a body that is permitted to
define the hidden type for that opaque, we're expecting the new trait
solver to sometimes produce different results.
Sometimes this is due to the fact that the new trait solver considers
more cases to be defining, such as when defining the hidden type
allows an impl for some wrapper type to be matched.
In other cases, this is due to lazy normalization, which e.g. allows
the new trait solver to more consistently handle as a concrete type
the return value of...
```rust
id2<T>(_: T, x: T ) -> T { x }
```
...when it is called with a value of the opaque type and a value of
the corresponding hidden type.
However, the new trait solver is not yet done, and it does not
consistently produce the results we expect that it will once
complete.
As we work toward stabilizing type alias impl Trait (TAIT), we need to
plan for what the behavior of the new trait solver will be.
Similarly, since return position impl Trait (RPIT) is already stable
but will see inference differences with the new trait solver, we need
to begin to plan for that also.
To help enable this planning, let's add test cases that define what
the correct inference behavior should be when handling opaue types.
The goal of this commit is to prompt discussion and ensure there is a
consensus on this behavior, then to document that behavior in these
tests.
Where the correct behavior does not match the behavior of either the
new or the old trait solver, we've chosen to mark that as a known
bug. For the new solver, we've done this since it is still a work in
progress and is expected to eventually model the correct behavior.
For the old solver, we've done this since the behavior is inconsistent
and often surprising, and since we may need to add future-incompat
lints or take other steps to prepare the ecosystem for the transition
to the new solver.
Collaborator
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
Contributor
Author
traviscross
added
the
T-types
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
Tests need blessing due to #118138 |
| struct I; | ||
| struct IShow; | ||
| impl I { | ||
| #[allow(dead_code)] |
Contributor
There was a problem hiding this comment.
ui tests already allow dead code
Contributor
|
@rustbot author |
rustbot
added
S-waiting-on-author
Member
|
@traviscross any updates on this? |
Contributor
Author
|
No. There probably still is value here. Should still clean it up and get it merged sometime. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When considering an opaque type within a body that is permitted to define the hidden type for that opaque, we're expecting the new trait solver to sometimes produce different results.
Sometimes this is due to the fact that the new trait solver considers more cases to be defining, such as when defining the hidden type allows an impl for some wrapper type to be matched.
In other cases, this is due to lazy normalization, which e.g. allows the new trait solver to more consistently handle as a concrete type the return value of...
...when it is called with a value of the opaque type and a value of the corresponding hidden type.
However, the new trait solver is not yet done, and it does not consistently produce the results we expect that it will once complete.
As we work toward stabilizing type alias impl Trait (TAIT), we need to plan for what the behavior of the new trait solver will be. Similarly, since return position impl Trait (RPIT) is already stable but will see inference differences with the new trait solver, we need to begin to plan for that also.
To help enable this planning, let's add test cases that define what the correct inference behavior should be when handling opaue types. The goal of this commit is to prompt discussion and ensure there is a consensus on this behavior, then to document that behavior in these tests.
Where the correct behavior does not match the behavior of either the new or the old trait solver, we've chosen to mark that as a known bug. For the new solver, we've done this since it is still a work in progress and is expected to eventually model the correct behavior. For the old solver, we've done this since the behavior is inconsistent and often surprising, and since we may need to add future-incompat lints or take other steps to prepare the ecosystem for the transition to the new solver.