-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wf-check generators #97183
wf-check generators #97183
Conversation
This comment has been minimized.
This comment has been minimized.
@oli-obk what's broken and how? |
This PR checks predicates on generators at all use sites, so also if the generator is used in a different function than where it was defined (via impl trait). This breaks two async tests (see PR diff), even though they should be fine afaict. It looks like the async fn generated TAIT does not know about the predicates of the function, but it may be even subtler, not sure. If nothing is obvious to you, i'll dig in, just wanted to check whether this rang a bell for you |
I have no idea what happens. From the test outputs, this looks more like an issue of missing predicates in the param_env, doesn't it? Lowering for async closures is just an expression, with nothing smart on the generic parameters. |
|
Blocked on #97607 |
☔ The latest upstream changes (presumably #97447) made this pull request unmergeable. Please resolve the merge conflicts. |
#97607 has been resolved by stabilizing nll r? rust-lang/compiler |
☔ The latest upstream changes (presumably #97674) made this pull request unmergeable. Please resolve the merge conflicts. |
@rustbot review |
r? rust-lang/types |
crater run, maybe? |
@bors try |
⌛ Trying commit b394703ec62dd42d725e83381460e9281fdeb539 with merge 0f68263c719c986445acfdd2b05d69e200c95710... |
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
The only real regression is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The monoio
"regression" should be added as a test.
error[E0277]: the trait bound `B: Bar` is not satisfied | ||
--> $DIR/future.rs:15:5 | ||
| | ||
LL | async move { bar.bar() } | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Bar` is not implemented for `B` | ||
| | ||
note: required by a bound in `foo` | ||
--> $DIR/future.rs:14:11 | ||
| | ||
LL | fn foo<B: Bar>(bar: B) -> FooFuture<B> { | ||
| ^^^ required by this bound in `foo` | ||
help: consider restricting type parameter `B` | ||
| | ||
LL | type FooFuture<B: Bar> = impl Future<Output = ()>; | ||
| +++++ | ||
|
||
error: aborting due to previous error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error seems incorrect, given that there is a B: Bar
bound on foo
and we throw away bounds on type aliases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not throw away bounds on type alias impl trait though. Performing the suggested change will actually work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's interesting!
error[E0277]: the size for values of type `A` cannot be known at compilation time | ||
--> $DIR/issue-88287.rs:35:9 | ||
| | ||
LL | type SearchFutureTy<'f, A, B: 'f> | ||
| - this type parameter needs to be `std::marker::Sized` | ||
... | ||
LL | async move { todo!() } | ||
| ^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | ||
| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know if it's just me, but I'm having a difficult time actually figuring out what the problem here is...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, but that's not a generator issue, closures would have the same issue.
it adds nothing new that isn't already covered by the existing tests |
@rustbot review |
☔ The latest upstream changes (presumably #99137) made this pull request unmergeable. Please resolve the merge conflicts. |
I'm torn on if this needs types team FCP or not. I lean towards no, since this is imo a bug fix. But also can see a case for it. I can't imagine any reason why we wouldn't want to do this, so r=me after rebase |
since it only affects unstable code, I think not @bors r=jackh726 |
wf-check generators fixes rust-lang#90409 We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.
Rollup of 8 pull requests Successful merges: - rust-lang#97183 (wf-check generators) - rust-lang#98320 (Mention first and last macro in backtrace) - rust-lang#99335 (Use split_once in FromStr docs) - rust-lang#99347 (Use `LocalDefId` in `OpaqueTypeKey`) - rust-lang#99392 (Fix debuginfo tests.) - rust-lang#99404 (Use span_bug for unexpected field projection type) - rust-lang#99410 (Update invalid atomic ordering lint) - rust-lang#99434 (Fix `Skip::next` for non-fused inner iterators) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
fixes #90409
We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.