-
Notifications
You must be signed in to change notification settings - Fork 14k
Closed
Labels
A-type-systemArea: Type systemArea: Type system
Description
There's no ICE or anything. The only problem is that the 'snippet 1' struct definitions are allowed, unlike those from snippet 2.
// Snippet 1
// No compiler error
struct Foo { p: ~[Foo, ..1] }
struct Bar { p: ~[Bar] }
fn main() {
let x: Option<Foo> = None;
let y: Option<Bar> = None;
}Without the vector-ness:
// Snippet 2
// error: this type cannot be instantiated without an
// instance of itself; consider using `Option<Baz>`
struct Baz { p: ~Baz }My understanding of what's going on: Foo and Bar from 'snippet 1' pass typeck::check::check_instantiable, because ty::is_instantiable::subtype_requires always returns false when matching sty variants ty_vec(_, _) and ty_unboxed_vec(_).
Here's the relevant RUST_LOG output for Foo:
subtypes_require(Foo, Foo)?
type_requires(Foo, ~[Foo, .. 1])?
subtypes_require(Foo, ~[Foo, .. 1])?
type_requires(Foo, [Foo, .. 1])?
subtypes_require(Foo, [Foo, .. 1])?
subtypes_require(Foo, [Foo, .. 1])? false
type_requires(Foo, [Foo, .. 1])? false
subtypes_require(Foo, ~[Foo, .. 1])? false
type_requires(Foo, ~[Foo, .. 1])? false
subtypes_require(Foo, Foo)? false
And for Bar:
subtypes_require(Bar, Bar)?
type_requires(Bar, ~[Bar])?
subtypes_require(Bar, ~[Bar])?
subtypes_require(Bar, ~[Bar])? false
type_requires(Bar, ~[Bar])? false
subtypes_require(Bar, Bar)? false
#3779 is the most similar issue I could find. This bug is distinct because the struct isn't infinitely sized. If I understand the terms correctly, issue #3779 describes a failure to verify struct representability, whereas this issue describes a bug in verifying struct instantiability.
Metadata
Metadata
Assignees
Labels
A-type-systemArea: Type systemArea: Type system