| Age | Commit message (Collapse) | Author |
|---|
|
|
|
zig code now can be made aware that it will not have any debug
information available at runtime.
|
|
Previously, the symbol name parameter of `@export` would be ignored for
variables, and the variable name would be used for the symbol name.
Now it works as expected.
See #2679
|
|
|
|
|
|
Follow the convention set by C so that lldb stops complaining about it.
|
|
TypeInfo: defs/Definition => decls/Declarations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
closes #2578
|
|
|
|
|
|
gen-h: do not output visibility macros when the build is static
|
|
See #2526
|
|
closes #1439
|
|
|
|
|
|
|
|
* `@clz`, `@ctz`, `@popCount`, `@bswap`, `@bitreverse` now
have a type parameter
* rename @bitreverse to @bitReverse
* rename @bswap to @byteSwap
Closes #2119
Closes #2120
|
|
* build-exe does include the startup code that supplies _start for the
wasm32-freestanding target. Previously this did not occur because
of logic excluding "freestanding".
* build-lib for wasm32-freestanding target gets linked by LLD. To avoid
infinite recursion, compiler_rt and zig libc are built as objects
rather than libraries.
- no "lib" prefix and ".wasm" extension instead of ".a". Rather than
build-lib foo.zig producing "libfoo.a", now it produces "foo.wasm".
* go back to using `.o` extension for webassembly objects
* zig libc only provides _start symbol for wasm when linking libc.
|
|
to be installed when linking libc.
When zig links against libc, it requires a dynamic linker path.
Usually this can be determined based on the architecture and operating
system components of the target. However on some systems this is not
correct; because of this zig checks its own dynamic linker.
When zig is statically linked, this information is not available, and so
it resorts to using cc -print-filename=foo to find the dynamic linker
path.
Before this commit, Zig incorrectly exited with an error if there was
no c compiler installed. Now, Zig falls back to the dynamic linker
determined based on the arch and os when no C compiler can be found.
|
|
optional capture value which is subset.
see #769
|
|
|
|
|
|
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.
|
|
Sadly due to a workaround for LLD linker limitations on macOS
we cannot put libuserland into an .a file; instead we have to use object
files. Again due to linker limitations, bundling compiler_rt.o into
another relocatable object also doesn't work. So we're left with
disabling stack probing on macOS for the stage1 self-hosted code.
These workarounds could all be removed if the macos support in the LLD
linker improved, or if Zig project had its own linker that did not have
these issues.
|
|
and use it when building libuserland.a
The self-hosted part of stage1 relies on zig's compiler-rt, and so we
include it in libuserland.a.
This should potentially be the default, but for now it's behind a linker
option.
self-hosted translate-c: small progress on translating functions.
|
|
see #1967
|
|
See #1967
|
|
Enabled on non-Windows systems only since it already requires stack
probes.
|
|
Previously if you had, for example:
extern "c" threadlocal var errno: c_int;
This would turn errno into a normal variable for --single-threaded
builds. However for variables with external linkage, there is an ABI
to uphold.
This is needed to make errno work for DragonFly BSD. See #2381.
|
|
When using `@memset` to set bytes to `undefined`, Zig notices this
case and does a single Valgrind client request rather than N.
Speeds up all allocators in safe modes.
Closes #2388
|
|
|
|
See #1964
|
|
|
|
Closes: #2165
|
|
This modifies the build process of Zig to put all of the source files
into libcompiler.a, except main.cpp and userland.cpp.
Next, the build process links main.cpp, userland.cpp, and libcompiler.a
into zig1. userland.cpp is a shim for functions that will later be
replaced with self-hosted implementations.
Next, the build process uses zig1 to build src-self-hosted/stage1.zig
into libuserland.a, which does not depend on any of the things that
are shimmed in userland.cpp, such as translate-c.
Finally, the build process re-links main.cpp and libcompiler.a, except
with libuserland.a instead of userland.cpp. Now the shims are replaced
with .zig code. This provides all of the Zig standard library to the
stage1 C++ compiler, and enables us to move certain things to userland,
such as translate-c.
As a proof of concept I have made the `zig zen` command use text defined
in userland. I added `zig translate-c-2` which is a work-in-progress
reimplementation of translate-c in userland, which currently calls
`std.debug.panic("unimplemented")` and you can see the stack trace makes
it all the way back into the C++ main() function (Thanks LemonBoy for
improving that!).
This could potentially let us move other things into userland, such as
hashing algorithms, the entire cache system, .d file parsing, pretty
much anything that libuserland.a itself doesn't need to depend on.
This can also let us have `zig fmt` in stage1 without the overhead
of child process execution, and without the initial compilation delay
before it gets cached.
See #1964
|
|
closes #2287
|
|
Previously the code for generating a panic crash expected
one of the parameters to be the error return trace. Now
it does not expect that parameter when g->have_err_ret_tracing
is false.
Closes #2276
|
|
|
|
|
|
|
|
|
|
This removes the compiler_rt.setXmm0 hack. Instead, for
the functions that use i128 or u128 in their parameter and
return types, we use `@Vector(2, u64)` which generates
the LLVM IR `<2 x i64>` type that matches what Clang
generates for `typedef int ti_int __attribute__ ((mode (TI)))`
when targeting Windows x86_64.
|
|
This was broken both in comptime code and in runtime code.
closes #1174
|
|
Closes #2152
See #1290
|
