Previously, ZIR was per-function so we could simply allocate a slice for
all ZIR instructions. However now ZIR is whole-file, so we need a sparse
mapping of ZIR to AIR instructions in order to not waste memory.
Previously, stage2 used a global decl_table for all Decl objects, keyed
by a 16-byte name hash that was hopefully unique. Now, there is a tree
of Namespace objects that own their named Decl objects.
Let mmap allocate a block of memory that's wide enough to use with
MADV_WIPEONFORK, madvise granularity is the current system page size
(using a static buffer of mem.page_size bytes would be wrong, that's the
minimum page size).
As a result, we don't zero some random chunk of memory every time we
fork the process.
Fixes#7609
There was missing incremental compilation logic in the MachO linker
code, causing test failures. With this logic ported over from the
corresponding ELF logic, tests pass again.
Previously the frontend incorrectly called freeDecl for structs, which
never got allocateDecl called for them. There was simply a missing check
for hasCodeGenBits().
In c8b78706b74d16ed21113096d2b47717abb53d4d I incorrectly made it be the
line offset from Decl to function lbrace; it needed to be line offset
from lbrace to rbrace.
* Advance line and PC prior to ending sequence in debug line program
for a fn_decl. This is equivalent to closing scope in the debugger
and without it, the debugger will not map source-to-address info
as a result will not print the source when breaking at a symbol.
* Fix debug aranges sentinels to be of the size as the actual tuple
descriptor (assuming segment selector to be ommitted). In summary,
the sentinels were 32bit 0s, whereas they ought to be 64bit 0s.
* Make naming of symbols in the binary more consistent by prefixing
each symbol name with an underscore '_'.
Conflicts:
* build.zig
* src/Compilation.zig
* src/codegen/spirv/spec.zig
* src/link/SpirV.zig
* test/stage2/darwin.zig
- this one might be problematic; start.zig looks for `main` in the
root source file, not `_main`. Not sure why there is an underscore
there in master branch.
As it stands, the backend is incomplete, and there is no active contributor,
making it dead weight.
However, anyone is free to resurrect this backend at any time.
Just like when new parse errors occur during an update, when new AstGen
errors occur during an update, we do not reveal compile errors for Decl
objects which are inside of a newly failed File. Once the File passes
AstGen successfully, it will be compared with the previously succeeded
ZIR and the saved Decl compile errors will be handled properly.
