| Age | Commit message (Collapse) | Author |
|---|
|
We definitely want a shared lock on a cache hit. Without this, we get a
deadlock when Zig is asked to compile the same C source file multiple
times as part of the same compilation.
This is a partial revert of 8ccb9a6ad327a4d7fbc321b33d4aa66a27a1f5ee.
cc @kcbanner
|
|
|
|
close stage1 issues
|
|
- C compilation flows didn't hold an exclusive lock on the cache manifest file when writing to it in all cases
- On windows, explicitly unlock the file lock before closing it
|
|
There are still a few occurrences of "stage1" in the standard library
and self-hosted compiler source, however, these instances need a bit
more careful inspection to ensure no breakage.
|
|
This change has been extracted to #13786 and can be solved separately
than this branch.
|
|
|
|
|
|
Also, make -Donly-c prevent Autodoc from being included in the binary.
This produces a 2.6 MiB zig.wasm file. 781 KB if piped through zstd.
|
|
After this commit, the self-hosted compiler does not offer the option to
use stage1 as a backend anymore.
|
|
closes #13535
|
|
Closes #13174
|
|
* Update for the breaking changes to std.fs.path.resolve. This had a
happy side effect of deleting some error handling code which is no
longer needed.
* Introduce cache_exempt_flags field to CSourceFile. This is used only
for include directories when building libc++ and libc++abi which
depend only on the zig lib path.
* libc_include_dir_list is only added to the cache hash when it
contains directories which have been obtained from system probing. It
is exempt when the directories depend only on the zig lib path.
|
|
Before, cache manifest files would have absolute file paths. This is
problematic for two reasons:
* Absolute file paths are not portable. Some operating systems such as
WASI have trouble with them. The files themselves are less portable;
they cannot be migrated from one user's home directory to another's.
And finally they can break due to file paths exceeding maximum path
component size.
* They would prevent some advanced use cases of Zig, where the lib dir
has a different path in a different invocation but is ultimately the
same Zig version and lib directory as before.
This commit adds a new column that specifies the prefix directory for
each file. 0 is an escape hatch and has the previous behavior. The other
two prefixes introduced are zig lib directory, and the cache directory.
This means files in zig-cache manifests can reference files local to
these directories.
In practice, this means it is possible to use a different file path for
the zig lib directory in a subsequent run of zig and have it still take
advantage of the global cache, provided that the files inside remain
unchanged.
closes #13050
|
|
There was no check for linker errors after flushing,
which meant that if the link failed the build would
continue and try to copy the non-existant exe, and
also write the manifest as if it had succeeded.
Also adds parsing of lld output, which is surfaced at the
end of the compilation with the other errors instead
of via stderr
|
|
Custom test runner
|
|
name mangling
|
|
Previously the compiler would crash on branching on undefined values
if you tried using `zig test` with a freestanding target since there
was no start code referencing `builtin.test_functions`.
Closes #12554
|
|
|
|
|
|
|
|
This reverts commit 06310e3d4eb47fed88b175891cb5865bb050f020, reapplying
commit a430630002bf02162ccbf8d3eb10fd73e490cefd.
I deeply apologize to @moosichu and those affected by this bug. The
original fix was actually fine. When I reverted it, I misremembered
how the Cache API works. I thought the fix was going to introduce
nondeterminism into the hash, but I forgot that the order of files in
the manifest doesn't actually matter when checking for a cache hit.
Actually, it does matter a little bit. This fix has a subtle downside
which is that it does introduce the possibility of false negatives when
checking for cache hits of 2+ iterations ago. For example, if the code
goes from "foo", to "bar", and then back to "foo", it may look like a
cache miss when it should have been a hit because 2 iterations ago the
code was the same. However, this is an uncommon use case, and all it
does is cause a bit of wasted time and disk space. That said, my
suggestion from earlier still applies and would be a nice follow-up
enhancement to this fix:
The proper solution to this is to, in whole cache mode, append the hash
inputs to some data structure, and then after the compilation is
complete, do some kind of sorting on the hash inputs so that they will
be the same order every time, then apply them in sequence. No lock on
the Cache object is needed for this scheme.
closes #11063
|
|
C backend fixes
|
|
Plan9: Fix The Backend
|
|
|
|
|
|
same as std.build.LibExeObjStep.make() for `zig build-exe`
closes #12419
|
|
|
|
with this, the tests should pass
|
|
|
|
Windows gives AccessDenied if you delete a directory which contains open
file handles. This could be triggered when using CacheMode.whole when
cross compiling macho test binaries.
|
|
build.zig: add a 'compile' step to compile the self-hosted compiler
without installing it.
Compilation: set cache mode to whole when using the LLVM backend and
--enable-cache is passed.
This makes `zig build` act the same as it does with stage1. Upside is
that a second invocation of `zig build` on an unmodified source tree
will avoid redoing the compilation again. Downside is that it will
proliferate more garbage in the project-local cache (same as stage1).
This can eventually be fixed when Zig's incremental compilation is more
robust; we can go back to having LLVM use CacheMode.incremental and rely
on it detecting no changes and avoiding doing the flush() step.
|
|
|
|
Before this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
After this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
This matches stage1 behavior:
```
$ zig test -fstage1 lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
All tests are still run if `zig test` is run directly on `lib/std/std.zig`:
```
$ zig test lib/std/std.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
`zig build test-std` is unaffected by this change.
Closes #12926
|
|
Pulls out the -g cc flag addition to the common area so that it is also
applied to assembly files.
|
|
Closes #7668
Closes #12141
|
|
|
|
The changes from https://reviews.llvm.org/D119173 mean that __config no
longer defaults the libc++ ABI to 1, relying on external configuration.
This means Zig must provide the external configuration.
This fixes static libraries built with zig with -lc++ to have the
standard __1 namespace prefix, which had previously regressed in the
llvm15 branch.
|
|
When linking libc and compiling natively, Zig tries to integrate with
the system C compiler. However, this caused Zig to fail when no system C
compiler is installed, despite the fact that Zig is perfectly capable of
compiling & linking libc without one.
This commit makes Zig fall back to using its own ability to provide libc
in the case that no C compiler is installed. For glibc, it means
sometimes getting the warning "zig cannot build new glibc version abc,
providing instead xyz".
Ideally, Zig would do some more validation about the system libraries
being linked against, and report an error in case it could not provide
the exact correct libc version of the system libraries (or that the
system libraries themselves conflict with each other), however, I think
it is fair to call that a separate enhancement.
|
|
Before, Zig tried to use its own libc files (e.g. glibc) when there were
no system libs being linked. This prevented building against native
glibc on systems that have newer glibc than the ones Zig provides.
Closes #12797
|
|
This adds the following for passthrough to lld:
- `--print-gc-sections`
- `--print-icf-sections`
- `--print-map`
I am not adding these to the cache manifest, since it does not change
the produced artifacts.
Tested with an example from #11398: it successfully prints the resulting
map and the GC'd sections.
|
|
This is problematic because in practice it depends on whether the
compiler backend supports it too, as evidenced by the TODO comment about
LLVM not supporting some architectures that in fact do support tail
calls.
Instead this logic is organized strategically in src/target.zig, part of
the internal compiler source code, and the behavior tests in question
duplicate some logic for deciding whether to proceed with the test.
The proper place to expose this flag is in `@import("builtin")` - the
generated source file - so that third party compilers can advertise
whether they support tail calls.
|
|
|
|
Follow-up for d5233ee85ce13cba3dd03e4c0c938cee193b9b19.
|
|
This commit enables `-u <symbol>` for ELF and `-include:<symbol>` for
COFF linkers for use internally. This means we do not expose these
flags to the users just yet, however, we make use of them internally
whenever required. One such use case is forcing inclusion of
`_tls_index` when linking for Windows with mingw and LTO and dead
code stripping enabled. This ensures we add `_tls_index` to the symbol
resolver as an undefined symbol and force the linker to include an atom
that provides it marking it a dead-code-stripping root - meaning it will
not be garbage collected by the linker no matter what.
|
|
Commit eb3f7d2f37cab1d3df7c4493b8239e802b83e521 changed the order of CLI
args passed to clang, making object-specific "extra flags" passed first.
However, these are supposed to be able to override other flags, and this
behavior is exploited by workarounds in mingw.zig to disable LTO.
This commit rectifies the situation by moving extra flags back to being
passed after the call to addCCArgs().
|
|
Avoids compile error on Windows due to not having execv capabilities.
Fixup for eb3f7d2f37cab1d3df7c4493b8239e802b83e521.
See #6768
|
|
When the entire purpose of this compilation is to perform a single zig
cc operation we could "tail call" clang by doing an execve, and any use
of the caching system would actually be problematic since the user is
presumably doing their own caching by using dep file flags.
Fixes #12317
|
|
This reverts 6d679eb2bcbe76e389c02e0bb4d4c4feb2847783 and additionally
changes the command line parameters passed to Clang to match.
Clang 14 defaults to DWARFv5 which is an interesting choice. v5 has been
out for 5 years and yet Valgrind does not support it, and apparently
neither does either GDB or LLD, I haven't determined which, but I wasn't
able to use GDB to debug my LLVM-emitted dwarf 5 zig code that was linked
with LLD.
A couple years ago when I was working on the self-hosted ELF linker, I
emitted DWARFv5 but then downgraded to v4 when I realized that third
party tools were stuck in the past. Years later, they still are.
Hopefully, Clang 14's bold move will inspire third party tools to get
their shit together, however, in the meantime, everything's broken, so
we're passing `-gdwarf-4` to clang and instructing LLVM to emit DWARFv4.
Note that Zig's std.debug code *does* support DWARFv5 already as of a
previous commit that I made today.
|
|
This was present in stage1 but missing from self-hosted.
|
