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

infer variance for region parameters #2282

Closed
nikomatsakis opened this issue Apr 25, 2012 · 5 comments
Closed

infer variance for region parameters #2282

nikomatsakis opened this issue Apr 25, 2012 · 5 comments
Assignees
Labels
A-lifetimes Area: Lifetimes / regions
Milestone

Comments

@nikomatsakis
Copy link
Contributor

It occurs to me that we are always treating regions covariantly. This is clearly wrong. We should either (1) not allow regions to appear in in- or contravariant positions within nominal types or (2) allow variance to be declared. I am leaning towards (1) at the moment.

@ghost ghost assigned nikomatsakis Apr 25, 2012
@graydon
Copy link
Contributor

graydon commented Apr 25, 2012

Can you clarify this with an example?

@nikomatsakis
Copy link
Contributor Author

A bug might look like this:

type T/& = {
    mut f: &uint
};

enum E/& = T;

fn foo(x: &E, v: &uint) {
    x.f = v;
}

fn bar(x: &E) {
    let v = 3u;
    foo(x, &v);
}

The call to foo() will store the region pointer into the mutable record embedded within the enum. bar() makes this call with a region pointer from its own stack. Region subtyping makes the call to foo() type-check.

This is a result of the typing rules for nominal types. Basically we have to know whether the region is used covariantly within the nominal type definition.

@brson
Copy link
Contributor

brson commented Jul 9, 2012

punting to 0.4

@nikomatsakis
Copy link
Contributor Author

It turns out that we are always treating region parameters as invariant. This is good, because it is sound, but less flexible than we might like. I've decided it's probably best to infer the variance on regions.

@nikomatsakis
Copy link
Contributor Author

Here is a test from @bblum that doesn't work because we are always invariant:

struct mutex { i: (); }
struct condvar { lock: &mutex; }

impl &mutex {
    fn lock_cond<U>(blk: fn(condvar) -> U) -> U {
        blk(condvar { lock: self })
    }
}

impl &condvar {
    fn wait() { }
}

fn main() {
    let m = ~(mutex { i: () });
    do m.lock_cond |cond| {
        (&cond).wait();
    }
}

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Support no-std targets and test it in CI

cc `@jamesmunns`

This is a bit annoying as you need to have `MIRI_NO_STD=1` set at all times, but it works ™️

Once libstd's `restricted_std` feature becomes more usable, we can probably do away with that env var.

I also added a test to CI to make sure it keeps working. This test only builds libcore and runs a single test, so it's pretty fast.
jieyouxu pushed a commit to jieyouxu/rust that referenced this issue Mar 14, 2025
Document `fetch.prunetags = true` gotcha during rustc-pull
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions
Projects
None yet
Development

No branches or pull requests

3 participants