On some systems (esp. systems that use unique hashed file-paths for
library-versions like Nix), we can't expect LLVM and Clang to share
lib/bin directories.
The best we can do is find the matching clang libraries in the
CMAKE_LIBRARY_PATH provided by the environment
`getdents` on Linux can return `ENOENT` if the directory referred to by the fd is deleted during iteration. Returning null when this happens makes sense because:
- `ENOENT` is specific to the Linux implementation of `getdents`
- On other platforms like FreeBSD, `getdents` returns `0` in this scenario, which is functionally equivalent to the `.NOENT => return null` handling on Linux
- In all the usage sites of `Iterator.next` throughout the standard library, translating `ENOENT` returned from `next` as null was the best way to handle it, so the use-case for handling the exact `ENOENT` scenario specifically may not exist to a relevant extent
Previously, ENOENT being returned would trigger `os.unexpectedErrno`.
Closes#12211
When lowering the return type for Wasm if the calling convention is `C`,
it now correctly lower it according to what clang does as specified in:
https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
This makes use of the same logic as the Wasm backend, ensuring the
generated code does not diverge in function signatures.
When passing arguments accross the C-ABI for the Wasm target,
we want slightly different behavior than x86_64.
For instance: a struct with multiple fields must always be passed
by reference, even if its ABI size fits in a single integer.
However, we do pass larger integers such as 128bit by value,
which LLVM will correctly lower to use double arguments instead.
This reverts commit 7cbd586ace46a8e8cebab660ebca3cfc049305d9.
This is causing a fail to build from source:
```
./lib/std/fmt.zig:492:17: error: cannot format optional without a specifier (i.e. {?} or {any})
@compileError("cannot format optional without a specifier (i.e. {?} or {any})");
^
./src/link/MachO/Atom.zig:544:26: note: called from here
log.debug(" RELA({s}) @ {x} => %{d} in object({d})", .{
^
```
I looked at the code to fix it but none of those args are optionals.
Expose 2 functions from std.json. These functions take a slice of bytes
and forward them to a given writer as a JSON encoded string.
The use case I have for this is in a custom JsonStringWriter. This writer
takes data and automatically encodes it as JSON string characters and
forwards it to an underlying writer. I use this JsonStringWriter in
combination with std.fmt.format to go directly from a format string/arg
pair to JSON. This way I don't have to format my string into a separate
buffer first and encode it afterwards, which avoids the need to create
a temporary buffer to hold the unencoded but formatted string.
This change relaxes the restriction added in the prior commit that LLD
should be alongside LLVM.
This also leaves unresolved the issue of making sure the link mode
(static or shared) of LLD matches that of LLVM/Clang. That would be an
unfortunate restriction, since LLD seems to be provided only as a static
lib on some distros.
This commit reworks the LLVM/Clang/LLD discovery process for CMake. The
biggest changes are that:
1. We search for LLVM from most preferred directory to least, skipping
any `llvm-config` that is the wrong version, or that doesn't
support the requested link mode ("static" or "shared").
2. `ZIG_PREFER_CLANG_CPP_DYLIB` has been renamed to `ZIG_SHARED_LLVM`,
to better align with `ZIG_STATIC_LLVM`.
3. We only search for LLVM in the same directory alongside LLVM.
4. LLVM's link mode is forwarded to Clang, so that we can look for the
appropriate shared/static libraries.
5. We use `--link-static` when querying `--system-libs` from llvm-config,
so that this will include libz and other dependencies for
statically linking LLD
