using the provided -L directories before checking if we need to integrate
with system library paths. This prevents false positive of invoking
system cc to find native paths when in fact all dependencies are
satisfied by -L (or --search-prefix to zig build).
* build.zig: remove detour through zig0. I'll add it back as an option
later. This means you can build stage1 with a freshly built zig
without detouring through zig0 again.
* remove unused file windows_script.bat
* drone.yml: remove unnecessary steps
* ninja doesn't need a jobs parameter
* build the release version of zig with zig build instead of cmake.
* build stage2 with -Dstatic-llvm -Duse-zig-libcxx
Instead of assuming that the zig version used with `zig build` is
appropriate for building the self-hosted compiler component, we follow
the same path as the cmake build script and build zig0, using that to
produce zig1.o, re-linking to produce stage1.
This allows an arbitrarily old Zig version and corresponding build.zig
script to build all future versions of Zig from source via the bootstrap
compiler. In other words, it allows us to use `zig build` as an
alternative to cmake when bootstrapping.
In accordance with the requesting issue (#10750):
- `zig test` skips any tests that it cannot spawn, returning success
- `zig run` and `zig build` exit with failure, reporting the command the cannot be run
- `zig clang`, `zig ar`, etc. already punt directly to the appropriate clang/lld main(), even before this change
- Native `libc` Detection is not supported
Additionally, `exec()` and related Builder functions error at run-time, reporting the command that cannot be run
Instead of defaulting to false, just keep the option as optional to
communicate default to the build system.
Fixes one problem with building the compiler for single-threaded
targets.
An attempt to normalize some of the function names in build.zig. Normalize add*Dir to add*Path. Also use "Library" instead of the "Lib" abbreviation.
The PR does not remove the old names, only adds the new normalized ones to faciliate a transition period.
Replaces the inflate API from `inflateStream(reader: anytype, window_slice: []u8)` to
`decompressor(allocator: mem.Allocator, reader: anytype, dictionary: ?[]const u8)` and
`compressor(allocator: mem.Allocator, writer: anytype, options: CompressorOptions)`
from zig-specific options to generally recognized zig build options that
any project can take advantage of. See the updated usage text for more
details.
Each element of the output JSON has the VM address of the generated
binary nondecreasing (some elements might occupy the same VM address
for example the atom and the relocation might coincide in the address
space).
The generated JSON can be inspected manually or via a preview tool
`zig-snapshots` that I am currently working on and will allow the user
to inspect interactively the state of the linker together with the
positioning of sections, symbols, atoms and relocations within each
snapshot state, and in the future, between snapshots too. This should
allow for quicker debugging of the linker which is nontrivial when
run in the incremental mode.
Note that the state will only be dumped if the compiler is built with
`-Dlink-snapshot` flag on, and then the compiler is passed `--debug-link-snapshot`
flag upon compiling a source/project.
This supports the case when it is known that LLVM, Clang, LLD were built
with Clang (or `zig c++`). This commit updates the Linux CI script to
pass this since we build using a zig tarball.
There was some new code in master branch enumerating all the targets and
a new target was added so we needed to add the glue code.
This commit also introduces some build options to support experimental
LLVM targets.
* rework `build_options` to integrate with the FileSource abstraction
* support mapping as an arbitrarily named package
* support mapping to multiple different artifacts
* use hash of contents for options filename
This way, we can explicitly signal if a test requires the presence
of macOS SDK to build. For instance, when testing our in-house
MachO linker for correctly linking Objective-C, we require the
presence of the SDK on the host system, and we can enforce this
with `-Denable-macos-sdk` flag to `zig build test-standalone`.
The motivation for this commit is that there exists source files which
produce ast-check errors, but crash stage1 or otherwise trigger stage1
bugs. Previously to this commit, Zig would run AstGen, collect the
compile errors, run stage1, report stage1 compile errors and exit if
any, and then report AstGen compile errors.
The main change in this commit is to report AstGen errors prior to
invoking stage1, and in fact if any AstGen errors occur, do not invoke
stage1 at all.
This caused most of the compile error tests to fail due to things such
as unused local variables and mismatched stage1/stage2 error messages.
It was taking a long time to update the test cases one-by-one, so I
took this opportunity to unify the stage1 and stage2 testing harness,
specifically with regards to compile errors. In this way we can start
keeping track of which tests pass for 1, 2, or both.
`zig build test-compile-errors` no longer works; it is now integrated
into `zig build test-stage2`.
This is one step closer to executing compile error tests in parallel; in
fact the ThreadPool object is already in scope.
There are some cases where the stage1 compile errors were actually
better; those are left failing in this commit, to be addressed in a
follow-up commit.
Other changes in this commit:
* build.zig: improve support for -Dstage1 used with the test step.
* AstGen: minor cosmetic changes to error messages.
* stage2: add -fstage1 and -fno-stage1 flags. This now allows one to
download a binary of the zig compiler and use the llvm backend of
self-hosted. This was also needed for hooking up the test harness.
However, I realized that stage1 calls exit() and also has memory
leaks, so had to complicate the test harness by not using this flag
after all and instead invoking as a child process.
- These CLI flags will disappear once we start shipping the
self-hosted compiler as the main compiler. Until then, they can be
used to try out the work-in-progress stage2.
* stage2: select the LLVM backend by default for release modes, as long
as the target architecture is supported by LLVM.
* test harness: support setting the optimize mode
Before this change, when one or more of name or value are not known at
comptime, build.zig files must allocate and do the concatanation, which can be
cumbersome, and also adds a redundant allocation when name and value are
slices. The new version only does a single allocation directly in the builder's
allocator to concatonate name and value.
The origional behavior is available in defineCMacroRaw, for use in situations
such as parseing c compiler arguments.
Additionally, several places have been updated to use the new funtions.
Now that `@import` of a non-existent file name is a compile error, the
Zig installation needs to include files that end with test.zig. However
we still want to avoid bloat in the installation size, so we blank them
out instead of omitting them entirely.
Now AstGen of the full standard library can complete successfully on a
Zig installation rather than erroring out with file not found.
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.
* `-lc++` now implies `-lc`.
* `-lunwind` is now pulled out into a separate `link_libunwind` flag in
the frontend driver code. This allows a project to request zig to
provide libunwind even if the default situation that causes it to be
implicitly added, is not active.
* build.zig: ask for -lunwind when building the self-hosted compiler on
Linux. Otherwise we get linker errors with unresolved symbols to
libunwind.
* for cross testing stage2 tests, we use `darling shell` command
since the path to the tested binary is relative to cwd
* for the `zig test` command, we simply use `darling` since the
path to the binary is absolute
With this change, it is now possible to use zig-bootstrap as the
initial C/C++ compiler, and then build stage2 with the resultant
stage1 without the need to link any system libs!
On CI, we have been running into OOM issues when running the test
suite on Windows for quite some time.
Unfortunately, we are very close to having the same issues on Linux
as well. Some additional comptime work immediately makes these builds
fail as well.
Add a new `test-toolchain` step, that tests everything except `std.*`
and documentation.
On CI, call `test-toolchain`, `test-std` and `docs` separately
instead of the `test` big hammer that emcompasses all of them.
Change the special case we made for Windows to the same code as other
platforms.
This is a stopgap measure that stage2 will eventually make useless.
Until then, it gives us some headroom.
Change `linux_script` by the way to only output the log of failing
steps. This shrinks the Linux CI log from a bazilion lines down to
something more humanely manageable.
