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 · Fixed by #63093
Closed

Existential type can have inconsistent concrete type #52632

dtolnay opened this issue Jul 22, 2018 · 7 comments · Fixed by #63093
Assignees
Labels
A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

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 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)?

@oli-obk oli-obk added A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. C-bug Category: This is a bug. labels Jul 22, 2018
@dtolnay
Copy link
Member Author

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 has been minimized.

@dtolnay

This comment has been minimized.

@cramertj

This comment has been minimized.

@oli-obk
Copy link
Contributor

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 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 Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label Jan 25, 2019
@oli-obk oli-obk self-assigned this Jan 25, 2019
@Centril Centril added F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. requires-nightly This issue requires a nightly compiler in some way. labels Jul 28, 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. C-bug Category: This is a bug. F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Development

Successfully merging a pull request may close this issue.

4 participants