This hack was initially introduced as we would export all symbols
unconditionally, including non-function definitions. This would cause
an error from the Wasmtime runtime engine, which this flag would
suppress. As we now properly export symbols, this flag is no longer
needed and any user running into this error can manually include it.
This commit also adds the `--import-symbols` ability to build.zig
When we're compiling compiler_rt for any WebAssembly target, we do
not want to expose all the compiler-rt functions to the host runtime.
By setting the visibility of all exports to `hidden`, we allow the
linker to resolve the symbols during linktime, while not expose the
functions to the host runtime. This also means the linker can
properly garbage collect any compiler-rt function that does not get
resolved. The symbol visibility for all target remains the same as
before: `default`.
No longer automatically append the `--export` flag for each exported
function unconditionally. This was essentially a hack to prevent
binary bloat caused by compiler-rt symbols being always included in
the final binary as they were exported and therefore not garbage-
collected. This is no longer needed as we now support the ability to
set the visibility of exports.
This essentially reverts 6d951aff7e32b1b0252d341e66517a9a9ee98a2d
In #1622, when targeting WebAsembly, the --allow-undefined flag
became unconditionally added to the linker.
This is not always desirable.
First, this is error prone. Code with references to unkown symbols
will link just fine, but then fail at run-time.
This behavior is inconsistent with all other targets.
For freestanding wasm applications, and applications that only use
WASI, undefined references are better reported at compile-time.
This behavior is also inconsistent with clang itself. Autoconf and
cmake scripts checking for function presence think that all tested
functions exist, but then resulting application cannot run.
For example, this is one of the reasons compilation of Ruby 3.2.0
to WASI fails with zig cc, while it works out of the box with clang.
But all applications checking for symbol existence before compilation
are affected.
This reverts the behavior to the one Zig had before #1622, and
introduces an `import_symbols` flag to ignore undefined symbols,
assuming that the webassembly runtime will define them.
* allow file level `union {}` to parse as tuple field
this was found while fuzzing zls.
* before this patch the input `union {}` crashed the parser. after
this, it parses correctly just like `struct {}`.
* adds behavior tests for both inputs `struct {}` and `union {}`,
checking that each becomes a file level tuple field.
Otherwise, we were prematurely committing `__LINKEDIT` segment LC
with outdated size (i.e., without code signature being taken into account).
This would scaffold into strict validation failures by Apple tooling.
Can occur when trying to open a directory for iteration but the 'List folder contents' permission of the directory is set to 'Deny'.
This was found because it was being triggered during PATH searching in ChildProcess.spawnWindows if a PATH entry did not have 'List folder contents' permission, so this fixes that as well (note: the behavior on hitting this during PATH searching is to treat it as the directory not existing and therefore will fail to find any executables in a directory in the PATH without 'List folder contents' permission; this matches Windows behavior which also fails to find commands in directories that do not have 'List folder contents' permission).
* pthread_key_t should also be available for non-android platforms
* Also change the type to c_uint because Linux pthreadtypes.h typedefs it as "unsigned int"
Partially addresses #13950
The extended instructions starting with opcode `0xFC` are refactored
to make the work the same as the SIMD instructions. This means a
`Mir` instruction no longer contains a field 'secondary'. Instead,
we use the `payload` field to store the index into the extra list
which contains the extended opcode value. In case of instructions
such as 'memory.fill' which also have an immediate value, such
values will also be stored in the extra list right after the
instruction itself. This makes each `Mir` instruction smaller.
These errdefer where never executed, while this didn't bother the stage1
compiler, it caused an error in stage2.
The fix is just removing those errdefer which doesn't change any
behaviour because they were never executed in the first place.
This reverts commit aa3964477f662ea5487aa4a1e4595d174e49a89d.
This declaration is already provided by operating-system-specific files.
This is not the correct solution to the problem.
See #14013Reopens#13950
these were found while fuzzing zls.
this patch prevents overflow for the following file contents and adds
tests for them.
* `enum(u32)` - causes overflow in std.zig.Ast.fullContainerDecl()
* `*x` - causes overflow in std.zig.Ast.fullPtrType()
* `**x` - causes overflow in std.zig.Ast.firstToken()
When reading a document with nested sections, it is not easy to discover
the depth of the current section.
Add support for nested section numbers, from the h2 to the h4 heading,
in the format "lv1. ", "lv1.lv2. ", "lv1.lv2.lv3. ". The "Zig Version"
and "Table of Content" sections are excluded.
The section numbers are implemented in CSS, with the CSS rules declared
inside a @media rule. Currently the @media rule targets all media.
This merges the paths from flushModule and linkWithZld to a single
function that will write the entire WebAssembly module to the file.
This reduces the chance of mistakes as we do not have to duplicate
the logic. A similar action may be needed later for linkWithLLD.
Fixes a regression caused by https://github.com/ziglang/zig/pull/13983
From the added comment:
We still search the path if the cwd is absolute because of the
"cwd set in ChildProcess is in effect when choosing the executable path
to match posix semantics" behavior--we don't want to skip searching
the PATH just because we were trying to set the cwd of the child process.
Normally when we want a pointer to the end of a struct we just add 1 to
the struct pointer. However, when it is a zero-bit struct, the pointer
type being used during lowering is often a dummy pointer type that
actually points to a non-zero-bit type, so we actually want to add 0
instead, since a zero-bit struct begins and ends at the same address.
