Skip to content

Do not leak type variables from opaque type relation #99928

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

Merged
merged 1 commit into from
Aug 30, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions compiler/rustc_infer/src/infer/sub.rs
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ use super::SubregionOrigin;
use crate::infer::combine::ConstEquateRelation;
use crate::infer::{TypeVariableOrigin, TypeVariableOriginKind};
use crate::traits::Obligation;
use rustc_middle::ty::error::{ExpectedFound, TypeError};
use rustc_middle::ty::relate::{Cause, Relate, RelateResult, TypeRelation};
use rustc_middle::ty::visit::TypeVisitable;
use rustc_middle::ty::TyVar;
Expand Down Expand Up @@ -141,17 +142,27 @@ impl<'tcx> TypeRelation<'tcx> for Sub<'_, '_, 'tcx> {
Ok(infcx.tcx.mk_ty_var(var))
};
let (a, b) = if self.a_is_expected { (a, b) } else { (b, a) };
let (a, b) = match (a.kind(), b.kind()) {
let (ga, gb) = match (a.kind(), b.kind()) {
(&ty::Opaque(..), _) => (a, generalize(b, true)?),
(_, &ty::Opaque(..)) => (generalize(a, false)?, b),
_ => unreachable!(),
};
self.fields.obligations.extend(
infcx
.handle_opaque_type(a, b, true, &self.fields.trace.cause, self.param_env())?
.handle_opaque_type(ga, gb, true, &self.fields.trace.cause, self.param_env())
// Don't leak any generalized type variables out of this
// subtyping relation in the case of a type error.
.map_err(|err| {
let (ga, gb) = self.fields.infcx.resolve_vars_if_possible((ga, gb));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably overkill, and we maybe should just do something like .map_err(|_| TypeError::Sorts(ExpectedFound { expected: a, found: b })) instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, I was just checking out all error sources in handle_opaque_types, and they all boil down to calling infcx.at(...).eq(x, y)? in some manner. The issue is that sometimes it's not a and b as passed, but another previously registered hidden type. Then you want to report the previous hidden type mismatching the new hidden type.

So I guess I'm saying there is a version of this issue where your change will actually not catch it. Trying to produce an example now

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was unable to reproduce the issue in the defining scope (that doesn't mean it's not possible, just that I gave up for now ^^). I found this absolutely useless diagnostic though: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b80473c86172959763c139535154c3f9

Did some more thinking and I'm wondering now if the did.is_local() check should actually be infcx.opaque_type_origin(did).is_some() so we only generate those generalized inference vars if we're actually able to handle the opaque type. I was kinda hoping to keep that isolated in handle_opaque_type, but that appears to have been a misplaced hope.

One more thing is that we're using eq inside handle_opaque_types when it should probably be using the relation that is calling handle_opaque_types. So maybe we could scrap the entire generalization logic and just always invoke handle_opaque_types by passing the relation as an argument and forwarding to that instead of using eq.

so many possibilities to try out. Let's merge this PR for now and I'm moving this comment to an issue so we can continue there.

if let TypeError::Sorts(sorts) = err && sorts.expected == ga && sorts.found == gb {
TypeError::Sorts(ExpectedFound { expected: a, found: b })
} else {
err
}
})?
.obligations,
);
Ok(a)
Ok(ga)
}

_ => {
Expand Down
13 changes: 13 additions & 0 deletions src/test/ui/impl-trait/issue-99914.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
// edition:2021

fn main() {}

struct Error;
struct Okay;

fn foo(t: Result<Okay, Error>) {
t.and_then(|t| -> _ { bar(t) });
//~^ ERROR mismatched types
}

async fn bar(t: Okay) {}
21 changes: 21 additions & 0 deletions src/test/ui/impl-trait/issue-99914.stderr
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
error[E0308]: mismatched types
--> $DIR/issue-99914.rs:9:27
|
LL | t.and_then(|t| -> _ { bar(t) });
| ^^^^^^ expected enum `Result`, found opaque type
|
note: while checking the return type of the `async fn`
--> $DIR/issue-99914.rs:13:23
|
LL | async fn bar(t: Okay) {}
| ^ checked the `Output` of this `async fn`, found opaque type
= note: expected enum `Result<_, Error>`
found opaque type `impl Future<Output = ()>`
help: try wrapping the expression in `Ok`
|
LL | t.and_then(|t| -> _ { Ok(bar(t)) });
| +++ +

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.