We still want this compile error but I'm giving up on implementing it
correctly in stage1. It's been buggy and has false positives sometimes.
I left the test cases there, but commented out, so that when we go
through the stage1 compile error cases and get coverage for them in
stage2 we can reactivate the test cases.
closes#2154
It wasn't wrong info, but e.g. GDB couldn't handle non-power-of-two
enum tags. Now we tell debug info that enum tags are always power of two
size.
closes#4526closes#5432
This makes `@returnAddress()` return 0 for WebAssembly (when not using
the Emscripten OS) and avoids trying to capture stack traces for the
general purpose allocator on that target.
`std.GeneralPurposeAllocator` is now available. It is a function that
takes a configuration struct (with default field values) and returns an
allocator. There is a detailed description of this allocator in the
doc comments at the top of the new file.
The main feature of this allocator is that it is *safe*. It
prevents double-free, use-after-free, and detects leaks.
Some deprecation compile errors are removed.
The Allocator interface gains `old_align` as a new parameter to
`resizeFn`. This is useful to quickly look up allocations.
`std.heap.page_allocator` is improved to use mmap address hints to avoid
obtaining the same virtual address pages when unmapping and mapping
pages. The new general purpose allocator uses the page allocator as its
backing allocator by default.
`std.testing.allocator` is replaced with usage of this new allocator,
which does leak checking, and so the LeakCheckAllocator is retired.
stage1 is improved so that the `@typeInfo` of a pointer has a lazy value
for the alignment of the child type, to avoid false dependency loops
when dealing with pointers to async function frames.
The `std.mem.Allocator` interface is refactored to be in its own file.
`std.Mutex` now exposes the dummy mutex with `std.Mutex.Dummy`.
This allocator is great for debug mode, however it needs some work to
have better performance in release modes. The next step will be setting
up a series of tests in ziglang/gotta-go-fast and then making
improvements to the implementation.
This is an attempt to save memory when building self-hosted.
before:
Total bytes allocated: 5.941 GiB, deallocated: 2.259 GiB, remaining: 3.681 GiB
after:
Total bytes allocated: 5.933 GiB, deallocated: 2.253 GiB, remaining: 3.680 GiB
This commit makes it possible to obtain pointers to `extern` variables
at comptime.
- `ir_get_var_ptr` employs several checks to determine if the given
variable is eligible for obtaining its pointer at comptime. This
commit alters these checks to consider `extern` variables, which have
runtime values, as eligible.
- After this change, it's now possible for `render_const_val` to be
called for `extern` variables. This commit modifies
`render_const_val` to suppress the value generation for `extern`
variables.
- `do_code_gen` now creates `ZigValue::llvm_global` of `extern`
variables before iterating through module-level variables so that
other module-level variables can refer to them.
This solution is incomplete since there are several cases still
failing:
- `global_var.array[n..m]`
- `&global_var.array[i]`
- `&global_var.inner_struct.value`
- `&global_array[i]`
Closes#5349
* bring `construct_linker_job_macho` to parity with
`construct_linker_job_elf`
* macho now sets `-error-limit`
* macho on macOS now sets `-macosx_version_min` and `-sdk_version`
to `10.13` when running `zig0`
* macho now detects when `-l` prefix is not needed
* macho on macOS detects system libraries in a case-insensitive manner
* macho now ads user-specified libraries to linker command-line args
when condition `is_native_os != true`
* re-ordered some macho args positions to match elf positions
closes#5059closes#5067
Now that Big Sur does not have system libraries on the filesystem, zig can no longer read them and add them to the cache hash for the compiler id.
This changes it so that only the first library path returned by os_self_exe_shared_libs is added to the cache hash under Darwin. I looked into methods on getting the system version to keep parity with older versions, but @fengb reported that this works on Catalina (a version behind Big Sur)
Signed-off-by: Haze Booth <isnt@haze.cool>
This adds these two fields to a HashMap Entry:
uint32_t hash
uint32_t distance_from_start_index
Compared to master branch, standard library tests compiled 8.4% faster
and took negligible (0.001%) more memory to complete. The amount of
memory used is still down from before 8b82c40104 which moved indexes
to be stored separately from entries.
So, it turns out, keeping robin hood hashing plus separating indexes
did result in a performance improvement. What happened previously is
that the gains from separating indexes balanced out the losses from
removing robin hood hashing, resulting in a wash.
This also serves as an inspiration for adding a benchmark to
std.AutoHashMap and improving the implementation.
The indexes are stored separately using an array of
uint8_t, uint16_t, uint32_t, or size_t, depending on the number of
entries in the map.
Entries only contain a key and a value, no longer have
distance_from_start_index or is_used.
In theory this should be both faster and use less memory.
In practice it seems to have little to no effect. For the standard
library tests, vs master branch, the time had no discernable
difference, and it shaved off only 13 MiB of peak rss usage.
