Skip to content
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

treatment of subtyping in trait matching is unsound #5781

Closed
nikomatsakis opened this issue Apr 8, 2013 · 6 comments
Closed

treatment of subtyping in trait matching is unsound #5781

nikomatsakis opened this issue Apr 8, 2013 · 6 comments
Labels
A-typesystem Area: The type system
Milestone

Comments

@nikomatsakis
Copy link
Contributor

We currently assume (at least in vtable.rs. though not in infer) that self types are contravariant. This is not sound since the Self type can appear anywhere, including return types.

For example, this program compiles:

trait Make {
    fn make() -> Self;
}

impl Make for *const uint {
    fn make() -> *const uint {
        ptr::null()
    }
}

fn maker<M:Make>() -> M {
    Make::make()
}

fn main() {
    let a: *uint = maker::<*uint>();
}

Note that we have "produced" a *uint even though there is no function in this program that returns one. In this case, it's harmless, but of course one can construct other more harmful examples (particularly if we add other forms of subtyping such as struct inheritance or datasort refinements).

The fix is a straight-forward modification (search for FIXMEs) but it invalidates a number of existing impls based around *const T and I didn't feel like dealing with the fallout as part of the patch I'm working on.

See also #3598---effectively we need a way to infer/declare variance for the Self parameter as well.

@pnkfelix
Copy link
Member

nominating for maturity milestone 1: Well defined.

@nikomatsakis
Copy link
Contributor Author

I have a local fix for this that simply makes trait matching invariant. It causes a number of compilation errors. The proper fix is to infer variance (#3598). I agree with the nomination that without settling this, the language is not well-defined.

@graydon
Copy link
Contributor

graydon commented Aug 15, 2013

accepted for well-defined milestone

@nikomatsakis
Copy link
Contributor Author

Note: work on variance inference is underway, so this should be addressable soon-ish.

@nikomatsakis
Copy link
Contributor Author

PR #10153 includes a general variance inference pass that should allow us to address this

@pcwalton
Copy link
Contributor

I believe this was accidentally fixed by DST, as @edwardw's code changes to variance were effectively introduced. I have rebased all test cases here and they are correctly rejected. Will close after a PR to add tests.

bors added a commit that referenced this issue Jun 28, 2014
I believe that #5781 got fixed by the DST work. It duplicated the
variance inference work in #12828. Therefore, all that is left in #5781
is adding a test.

Closes #5781.

r? @huonw
pcwalton added a commit to pcwalton/rust that referenced this issue Jul 1, 2014
… borrows

still in scope".

This issue was fixed by PR rust-lang#12828 and rust-lang#5781. All that was left was to
add tests.

Closes rust-lang#12223.
bors added a commit that referenced this issue Jul 2, 2014
still in scope".

This issue was fixed by PR #12828 and #5781. All that was left was to
add tests.

Closes #12223.
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2020
Fix a broken link in CONTRIBUTING.md

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
4 participants