Fix assignments in array literals

[straight-shoota]

When assigning inside an array literal, the compiler issues a weird error that doesn't make sense from the code presented to the user:

[c = 3]
c # Semantic Error: read before definition of 'c'

The reason for this is that the above code actually expands to this:

::Array(typeof(c = 3)).build(1) do |__temp|
  __temp[0] = c = 3
  1
end
c

So c is declared inside the build block and not visible in the original scope.

This patch changes array literal expansion to unwrap the behaviour of Array.build into the current scope.
Our code example now expands to this:

__temp = ::Array(typeof(c = 3)).unsafe_build(1)
__temp.to_unsafe[0] = c = 3
c

A necessary change to stdlib's Array class is the new undocumented constructor unsafe_build which initializes the buffer and sets size to capacity.

To enable smooth progression between Crystal releases, Array.unsafe_build should be merged alone and the compiler change can follow after the next release.

Also adds codegen specs for assigning in array-like, hash-like and hash literals. They are already working correctly because there's no additional scope introduced.

Resolves #3195

---

EDIT: Original proposal was this, has been changed to the above during the course of the discussion.

__temp = ::Array(typeof(c = 3)).new(1)
__temp.to_unsafe[0] = c = 3
__temp.size = 1
c

We only need a tiny change in stdlib because Array#size= is protected but we need to call it from outside (Array.build calls it internally). The method is undocumented but to avoid accidental calls, I named the public method unsafe_size=.
size= can probably be removed, but that's left for later to ensure backwards compatibility.

[asterite]

I kind of dislike exposing setting the size of an array, even if it's undocumented.

That said, anyone could reopen array and do the same so maybe this is fine.

[straight-shoota]

Alternative to that setter could be an initializer that directly sets size = initial_capacity. That might be better. You can still call that and do unsafe stuff, but you can't change an existing array that easily. It also reduces the interface between compiler and stdlib.

[bcardiff]

Maybe a different expansion would another alternative for this

a = [1, b = 2, c = 3, 4]
c

Introducing temp variables for each element.

%e0 = 1
%e1 = b = 2
%e2 = c = 3
%e3 = 4
a = ::Array(typeof(c = 3)).build(1) do |__temp|
  __temp[0] = %e0
  __temp[1] = %e1
  __temp[2] = %e2
  __temp[2] = %e3
  1
end
c

[asterite]

won't work if the assignment is nested even deeper

[straight-shoota]

I thought we could keep it simple and avoid all those additional temp variables and block. This works:

__temp_2 = ::Array(typeof(c = 3)).new(1, __temp_2 = uninitialized typeof(c = 3))
__temp_2.to_unsafe[0] = c = 3
__temp_2

But it seems I've hit some unrelated compiler bug with this: #10018

[straight-shoota]

We could skip that uninitialized default value and either use an actual value or add an undocumented Array constructor that sets @size = @capacity. The latter is probably best becaus it avoids unnecessary initialization of the buffer.

[straight-shoota]

This should be good now 👍

The literal now expands to:

__temp = ::Array(typeof(c = 3)).unsafe_build(1)
__temp.to_unsafe[0] = c = 3
c

I've updated the original description.

[asterite]

Could we change this to be:

__temp_1 = ::Array(Int8).unsafe_build(2)
__temp_2 = __temp_1.to_unafe
__temp_2[0] = 1
__temp_2[1] = 2
__temp_1

That way the to_unsafe call would be needed to be computed just once.

[straight-shoota]

I would have expected that call to be inlined. But sure, I'll change it.

[asterite]

Oh, actually it is inlined by the codegen because it's just returning an instance var. But the semantic phase will have to look it up once per each element, so maybe it's too much.

[straight-shoota]

I just realized yesterday that instead of introducing Array.unsafe_build we could have just used Array.build(size) { size } 🤦
We could probably refactor that and remove unsafe_build. It's not public API, so it can be done quickly.