Illegal storage access compiling call with nested ref/deref'd types

[tersec]

Calling a function with nested layers of object construction, each of which constructs a reference object then dereferences it, results in SIGSEGV at compile time with Nim versions 1.2.12, 1.4.2, and current git head.

Example

type
  Foo = object
    discard

  Bar = object
    x: Foo

proc baz(state: var Bar) = discard
baz((ref Bar)(x: (new Foo)[])[])

Current Output

$ nim c sigsegv.nim
Hint: used config file '/etc/nim/nim.cfg' [Conf]
Hint: used config file '/etc/nim/config.nims' [Conf]
....SIGSEGV: Illegal storage access. (Attempt to read from nil?)
$ nim --version
Nim Compiler Version 1.4.2 [Linux: amd64]
Compiled at 2021-05-13
Copyright (c) 2006-2020 by Andreas Rumpf

active boot switches: -d:release

$ ~/Nim/bin/nim c sigsegv.nim
Hint: used config file 'Nim/config/nim.cfg' [Conf]
Hint: used config file 'Nim/config/config.nims' [Conf]
....SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Segmentation fault
$ ~/Nim/bin/nim --version
Nim Compiler Version 1.5.1 [Linux: amd64]
Compiled at 2021-05-24
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: d217888e5679aff063668930bd00892c4f5cb2b3
active boot switches: -d:release

$ ./env.sh nim c ../sigsegv.nim 
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: sigsegv [Processing]
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
$ ./env.sh nim --version
Nim Compiler Version 1.2.12 [Linux: amd64]
Compiled at 2021-05-23
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: 121628357ec7fae91335bd392f03b0e6dd249319
active boot switches: -d:release

Expected Output

Not a segfault.

[bung87]

what's the expected behavior by language design?

[Araq]

Don't crash at compile-time and compile it properly.

[bung87]

I can make this compile but am not sure about correctness, according to below, but it seems no other way construct var Bar in this kind of form. also it's kind fine as that is semmatch error this is just cgen error.

proc(x: var X | ref X) fails to compile #4448

    The mutability aspect of a type is not lifted to an "or" type. This is not a bug, but it could be a feature that we support. I personally don't like it at all, it's only useful for confused code that uses both var and ref and cannot make up its mind.

Originally posted by @Araq in #4448 (comment)

[bung87]

after ecc8f61, it's still remain same error on gc refc, but compile and runs on orc

[tersec]

That sounds not very fixed/closed.