The linker needs to know the file system path of output in the flush
function because file paths inside the build artifacts reference each
other. Fixes a regression introduced in this branch.
This issue already existed in master branch, however, the more
aggressive caching of builtin.zig in this branch made it happen more
often. I added doc comments to AtomicFile to explain when this problem
can occur.
For the compiler's use case, error.AccessDenied can be simply swallowed
because it means the destination file already exists and there is
nothing else to do besides proceed with the AtomicFile cleanup.
I never solved the mystery of why the log statements weren't printing
but those are temporary debugging instruments anyway, and I am already
too many yaks deep to whip out another razor.
closes#14978
Without this commit, unrelated test builds using incremental cache mode
(self-hosted, no lld) would end up using the same cache namespace, which
is undesireable since concurrent builds will clobber each other's work.
This happened because of passing the root module to
addModuleToCacheHash. In the case of a test build, the root module
actually does not connect to the rest of the import table. Instead, the
main module needs to be passed, which has "root" in its import table.
The other call to addModuleTableToCacheHash which is in
addNonIncrementalStuffToCacheManifest already correctly passes the main
module.
In the future, I think this problem can be fully addressed by obtaining
an advisory lock on the output binary file. However, even in that case,
it is still valuable to make different compilations use different cache
namespaces lest unrelated compilations suffer from pointless thrashing
rather than being independently edited.
Instead of making its own inside create. 10 out of 10 calls to create()
had already an arena in scope, so this commit means that 10 instances of
Compilation now reuse an existing arena with the same lifetime rather
than creating a redundant one.
In other words, this very slightly optimizes initialization of the
frontend in terms of memory allocation.
Now, link.File will always be null when -fno-emit-bin is specified, and
in the case that LLVM artifacts are still required, the Zcu instance has
an LlvmObject.
before this commit it was trying to hash based on resolved bin_file
settings, but bin_file was always null since cache mode is always whole
when this function is called! hash based on the lf_open_opts instead.
This reintroduced flag makes zig build behave the same as the previous
commit. Without this flag, the default behavior is now changed to
display compilation errors inline with the rest of error messages and
the build tree context.
This behavior is essential for making sense of error logs from projects
that have two or more steps emitting compilation errors which is why it
is now the default.
* move wasi_emulated_libs into Compilation
- It needs to be accessed from Compilation, which needs to potentially
build those artifacts.
* Compilation: improve error reporting for two cases
- the setMiscFailure mechanism is handy - let's use it!
* fix one instance of incorrectly checking for emit_bin via
`comp.bin_file != null`. There are more instances of this that need to
be fixed in a future commit.
* fix renameTmpIntoCache not handling the case where it needs to make
the "o" directory in the zig-cache directory.
- while I'm at it, simplify the logic for handling the fact that
Windows returns error.AccessDenied rather than
error.PathAlreadyExists for failure to rename a directory over
another one.
* fix missing cache hash additions
- there are still more to add in a future commit -
addNonIncrementalStuffToCacheManifest is called when bin_file is
always null, and then it incorrectly checks if bin_file is non-null
and only then adds a bunch of stuff to the cache hash. It needs to
instead add to the cache hash based on lf_open_opts.
This is necessary because on COFF, the entry symbol name is not known
until the linker has looked at the set of global symbol names to
determine which of the four possible main entry points is present.
use_llvm=false does not always mean there needs to be a zig compiler
backend available. In particular, when there is no zig compilation unit,
use_llvm=false and yet no zig backend will be used to produce code.
In Compilation.create, update the resolved config to account for the
default resolution of the root module. This makes it so that, for
example, reading comp.config.any_non_single_threaded is valid in order
to determine whether any module has single_threaded=false.
Now that we always pass --image-base to LLD, including when Zig chooses
the default value, LLD is complaining about 32-bit architectures because
it requires being at least equal to the max page size, which is 64K.
When using the build system to do unit testing, it lowers to --mod
arguments which were incorrectly tripping a "zig test requires a source
file argument" error.
* fix relationship between createEmpty/open (similar logic as
607111aa758002bc51914b7dc800b23927c931b8)
* still resolve the start symbol when linking libc because when zig is
the linker it still needs to know the entry symbol.
* make use_llvm=false when there is no zig compilation unit.
when linking libc, the entry point is within libc.
when producing C code, the entry point is decided when compiling the C
code and does not need to be known up front.
fixes a false positive "error: unknown target entry point" when using
-ofmt=c.
