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

Infinitely recursive struct definitions compile successfully when behind fixed-size vector #11659

Closed
isabelmu opened this issue Jan 19, 2014 · 4 comments
Labels
A-type-system Area: Type system

Comments

@isabelmu
Copy link
Contributor

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.

@huonw
Copy link
Member

huonw commented Jan 19, 2014

Nice catch!

Foo is certainly invalid, since it's fundamentally the same as Baz. However, Bar is ok, since Bar { p: ~[] } is a base case for the recursion.

@isabelmu
Copy link
Contributor Author

Oooh of course.

@huonw
Copy link
Member

huonw commented Jan 19, 2014

(I'm testing a fix for this now.)

@huonw
Copy link
Member

huonw commented Jan 19, 2014

#11661 (your understanding was correct, just needed to detect & handle fixed length vectors specifically).

bors added a commit that referenced this issue Jan 20, 2014
…inger

Previously, they were treated like ~[] and &[] (which can have length
0), but fixed length vectors are fixed length, i.e. we know at compile
time if it's possible to have length zero (which is only for [T, .. 0]).

Fixes #11659.
@huonw huonw closed this as completed in 6f3c202 Jan 20, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 21, 2023
[`manual_is_ascii_check`]: Also check for `is_ascii_hexdigt`

changelog: [`manual_is_ascii_check`]: Also check for `is_ascii_hexdigt`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants