v: allow recursive struct with option

[felipensp]

Fix #14185

struct Node {
mut:
  next ?Node
}

fn main() {
	mut a := Node{}
	a.next = Node{}
	println(a)
	println(a.next?)
	println(a.next?.next)
}

Node{
    next: Option(Node{
        next: Option(error: none)
    })
}
Node{
    next: Option(error: none)
}
Option(error: none)

[medvednikov]

just one test failing!

Failed command 1:    '/home/runner/work/v/v/v' -cflags -fsanitize=address   -o '/tmp/v_1001/tsession_7f337d74f740_349323323640/option_nested_struct_test' '/home/runner/work/v/v/vlib/v/tests/option_nested_struct_test.v'

[watzon]

@medvednikov I ran the specs locally and they seem to pass, do you know what runner that failed on? The logs have been cleaned up now. It would be really helpful for a project I'm working on if this got merged.

[JalonSolov]

The problem is that it failed the sanitize-address tests. That generally points to memory leaks, array access problems, etc. Those need to be addressed, first.

[watzon]

Can confirm. I tried a real world test and got a segfault.

[felipensp]

Yes, It points memory issue when doing a.next = Node{}.

[felipensp]

Yes, It points memory issue when doing a.next = Node{}.

Since makes no sense a recursive struct using stack, I've changed this PR plan to allow recursive struct using ?&Node. What do you think @medvednikov? In this way we do not have memory issues.

[medvednikov]

Hm I thought ?Node would imply ?&Node.

@spytheman what do you think?

[spytheman]

Hm I thought ?Node would imply ?&Node.

I think, that it is still too early (opened bugs concerning option values), to change the representation of Option, which will be needed to make struct Node { next ?Node } work.

This PR enables the compilation of:

struct Node { next ?&Node }
a := Node{}

which currently leads to segfault in cgen on master (stack overflow due to Gen_struct_init -> Gen_zero_struct_field -> Gen_expr_with_tmp_var -> Gen_expr_with_cast -> Gen_expr -> Gen_struct_init etc).

That is still valuable and enables more and safer programs, compared to just next &Node which we do support.

[medvednikov]

Ok, makes sense.

But I think in the future, it'd be okay to have just ?Node, instead of always requiring ?&Node.

Feels a lot more readable and simple.