* fix crash when doing field access of slice types. closes#2486
* remove the deprecated Child property from slice types
* add -Dskip-non-native build option to build script
Stuffing all the files together and compiling the resulting blob with
the main program is a terrible idea.
Some files, namely the .S ones, must be run trough the C preprocessor
before assembling them (#2437).
Beside that the aggregate may be mis-compiled due to the presence of
some flags that affect the following code.
For example let's consider two files, a.s and b.s
a.s
```
fn1:
ret
.data
data1:
.word 0
```
b.s
```
fn2:
ret
```
Now, fn1 and fn2 will be both placed in the .text section as intended if
the two files are compiled separately. But if we merge them the `.data`
flag ends up placing fn2 in the wrong section!
This fixes a nasty crash where musl's memset ended up in the
non-executable data segment, leading to too many hours of
head-scratching.
The `arena` instance being used bythe parse tree was valid and
pointed to valid memory, but existed as a local variable inside the
stack frame of the `parse` function (the `const arena`), which was never
stored anywhere before leaving the scope.
This meant that code above the `parse` function saw a valid instance of
an `ArenaAllocator` that pointed to the same backing memory, but didn't
posess any of the local state built up after the call to `parseRoot`,
basically the caller saw an empty arena.
This meant that when `deinit` was called, it saw an Arena with 0
allocations in it's `buffer_list` and wasn't able to destroy any of the
memory. This caused it to leak and caused FailingAllocator to balk.
The fix is to make sure the parse tree is using the same instance of
ArenaAllocator as is reported up the call stack, the one inside the
`Tree{}` object. I'm not sure why that field is marked with a comment
to remove it, as it's used by the `std.ast.Tree.deinit()` function, but
this change seems to solve the problem.
stage1 translate-c actually has this wrong. When exporting a function,
it's ok to use empty parameters. But for prototypes, "no prototype"
means that it has to be emitted as a function that accepts anything,
e.g. extern fn foo(...) void;
See #1964