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

Existential type can have inconsistent concrete type #52632

Closed
dtolnay opened this issue Jul 22, 2018 · 7 comments
Closed

Existential type can have inconsistent concrete type #52632

dtolnay opened this issue Jul 22, 2018 · 7 comments

Comments

@dtolnay
Copy link
Member

@dtolnay dtolnay commented Jul 22, 2018

#![feature(existential_type)]

use std::fmt::Debug;

// Parser workaround. https://github.com/rust-lang/rust/issues/52631
macro_rules! this_is_an_item {
    ($i:item) => { $i };
}

fn main() {
    this_is_an_item! {
        existential type Existential: Debug;
    }

    fn _unused() -> Existential { String::new() }

    let null = || -> Existential { 0 };
    println!("{:?}", null());
}
Segmentation fault (core dumped)

Mentioning the existential types tracking issue #34511
Mentioning @oli-obk and @cramertj

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jul 22, 2018

O_o I don't think I considered closures at all.

Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?

@dtolnay
Copy link
Member Author

@dtolnay dtolnay commented Jul 22, 2018

As a motivating use case, existential types defined by a closure are required if we want to extend lazy_static! to support referring to local variables.

#![feature(existential_type, untagged_unions)]

#[macro_use]
extern crate lazy_static;

use std::ops::Deref;

#[derive(Debug)]
struct ExpensiveResult;

// TODO: move this inside of `lazy_local!`.
existential type Init: FnOnce() -> ExpensiveResult;

macro_rules! lazy_local {
    (ref $name:ident : $ty:ty = $init:expr;) => {
        #[allow(unions_with_drop_fields)]
        union BrieflyUninit {
            uninit: (),
            // If $name is never deref'd, this initializer is never dropped.
            value: Init,
        }

        static mut INIT: BrieflyUninit = BrieflyUninit { uninit: () };
        let init = move || -> Init { move || $init };
        unsafe {
            std::ptr::write(&mut INIT.value, init());
        }

        lazy_static! {
            static ref $name: $ty = unsafe { std::ptr::read(&INIT.value)() };
        }
    };
}

fn lazy_deref_with_args(arg: i32) -> &'static impl Deref<Target = ExpensiveResult> {
    lazy_local! {
        ref STATE: ExpensiveResult = { println!("arg={}", arg); ExpensiveResult };
    }

    &STATE
}

fn main() {
    let state = lazy_deref_with_args(1);
    println!("{:?}", **state);
}
@cramertj

This comment was marked as off-topic.

@dtolnay

This comment was marked as off-topic.

@cramertj

This comment was marked as off-topic.

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jul 24, 2018

I chose a simpler logic: any in scope use must be a defining use.

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jan 25, 2019

We've moved from segmentation faults to an ICE:

internal compiler error: broken MIR in DefId(0/1:9 ~ playground[d6cf]::main[0]::{{closure}}[0]) (bb0[0]): equate_inputs_and_outputs: `Existential==i32` failed with `NoSolution`
@oli-obk oli-obk added the I-ICE label Jan 25, 2019
@oli-obk oli-obk self-assigned this Jan 25, 2019
Aaron1011 added a commit to Aaron1011/rust that referenced this issue Jul 28, 2019
Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.
Centril added a commit to Centril/rust that referenced this issue Jul 29, 2019
…r=cramertj

Properly check the defining scope of existential types

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.
Centril added a commit to Centril/rust that referenced this issue Jul 29, 2019
…r=cramertj

Properly check the defining scope of existential types

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.
Centril added a commit to Centril/rust that referenced this issue Jul 30, 2019
…r=cramertj

Properly check the defining scope of existential types

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.
Centril added a commit to Centril/rust that referenced this issue Jul 30, 2019
…r=cramertj

Properly check the defining scope of existential types

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.
@bors bors closed this in #63093 Jul 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants