This option can be used to produce a C backend build of the self-hosted
compiler, which only has the C backend enabled. Once the C backend is
capable of self-hosting, this will be a way for us to replace our stage1
codebase with a C backend build of self-hosted, which we can then use
for bootstrapping. See #5246 for more details.
Using this option right now results in a crash because the C backend is
not yet passing all the behavior tests.
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.
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.
Now that we ship our own linker for MachO by default in both stage1
and stage2, we need a way to enable logs for verbose debugging.
This commit adds `ZIG_ENABLE_LOGGING` cmake option which is equivalent
to stage2's `-Dlog` flag.
To enable it when building stage1 with cmake, add:
```
cmake .. -DZIG_ENABLE_LOGGING=on
```
Previously you had to recompile if you wanted to change the log scopes
that get printed. Now, log scopes can be set at runtime, and -Dlog
controls whether all logging is available at runtime.
Purpose here is a nicer development experience. Most likely stage2
developers will always want -Dlog enabled and then pass --debug-log
scopes when debugging particular issues.
* remove the -Ddump-zir thing. that's handled through --verbose-ir
* rework Fn to have an is_inline flag without requiring any more memory
on the heap per function.
* implement a rough first version of dumping typed zir (tzir) which is
a lot more helpful for debugging than what we had before. We don't
have a way to parse it though.
* keep track of whether the inline-ness of a function changes because
if it does we have to go update callsites.
* add compile error for inline and export used together.
inline function calls and comptime function calls are implemented the
same way. A block instruction is set up to capture the result, and then
a scope is set up that has a flag for is_comptime and some state if the
scope is being inlined.
when analyzing `ret` instructions, zig looks for inlining state in the
scope, and if found, treats `ret` as a `break` instruction instead, with
the target block being the one set up at the inline callsite.
Follow-up items:
* Complete out the debug TZIR dumping code.
* Don't redundantly generate ZIR for each inline/comptime function
call. Instead we should add a new state enum tag to Fn.
* comptime and inlining branch quotas.
* Add more test cases.
restore "Comply with semantic versioning pre-release format"
restore "stage2: SemVer compliance for development builds"
restore "Remove 'g' prefix from commit hash in Zig semver"
This reverts commit d96d8639e5.
This reverts commit e8810f5794.
This reverts commit 9afe5859a3.
restore cmake to be capable of figuring out the zig version
restore config.h and config.zig. config.h is used to detect whether we
should propagate cmake configuration information to build.zig; however
it can be overridden with -Dstatic-llvm.
fix not passing -DZIG_LINK_MODE with zig build.
when using the cmake build path, build.zig no longer tries to call
llvm-config. Instead it relies 100% on the LLVM_LIBRARIES cmake variable.
build.zig logic reworked and simplified.
The main idea here is that there are now 2 ways to get a stage1 zig
binary:
* The cmake path. Requirements: cmake, system C++ compiler, system
LLVM, LLD, Clang libraries, compiled by the system C++ compiler.
* The zig path. Requirements: a zig installation, system LLVM, LLD,
Clang libraries, compiled by the zig installation.
Note that the former can be used to now take the latter path.
Removed config.h.in and config.zig.in. The build.zig script no longer is
coupled to the cmake script.
cmake no longer tries to determine the zig version. A build with cmake
will yield a stage1 zig binary that reports 0.0.0+zig0. This is going to
get reverted.
`zig build` now accepts `-Dstage1` which will build the stage1 compiler,
and put the stage2 backend behind a feature flag.
build.zig is simplified to only support the use case of enabling LLVM
support when the LLVM, LLD, and Clang libraries were built by zig. This
part is probably sadly going to have to get reverted to make package
maintainers happy.
Zig build system addBuildOption supports a couple new types.
The biggest reason to make this change is that the zig path is an
attractive option for doing compiler development work on Windows. It
allows people to work on the compiler without having MSVC installed,
using only a .zip file that contains Zig + LLVM/LLD/Clang libraries.
Deleted 16,000+ lines of c++ code, including:
* an implementation of blake hashing
* the cache hash system
* compiler.cpp
* all the linking code, and everything having to do with building
glibc, musl, and mingw-w64
* much of the stage1 compiler internals got slimmed down since it
now assumes it is always outputting an object file.
More stuff:
* stage1 is now built with a different strategy: we have a tiny
zig0.cpp which is a slimmed down version of what stage1 main.cpp used
to be. Its only purpose is to build stage2 zig code into an object
file, which is then linked by the host build system (cmake) into
stage1. zig0.cpp uses the same C API that stage2 now has access to,
so that stage2 zig code can call into stage1 c++ code.
- stage1.h is
- stage2.h is
- stage1.zig is the main entry point for the Zig/C++
hybrid compiler. It has the functions exported from Zig, called
in C++, and bindings for the functions exported from C++, called
from Zig.
* removed the memory profiling instrumentation from stage1.
Abandon ship!
* Re-added the sections to the README about how to build stage2 and
stage3.
* stage2 now knows as a comptime boolean whether it is being compiled
as part of stage1 or as stage2.
- TODO use this flag to call into stage1 for compiling zig code.
* introduce -fdll-export-fns and -fno-dll-export-fns and clarify
its relationship to link_mode (static/dynamic)
* implement depending on LLVM to detect native target cpu features when
LLVM extensions are enabled and zig lacks CPU feature detection for
that target architecture.
* C importing is broken, will need some stage2 support to function
again.
* build.zig: repair the ability to link against llvm, clang, and lld
* move the zig cc arg parsing logic to stage2
- the preprocessor flag is still TODO
- the clang arg iterator code is improved to use slices instead of
raw pointers because it no longer has to deal with an extern
struct.
* clean up error printing with a `fatal` function and use log API
for messages rather than std.debug.print
* add support for more CLI options to stage2 & update usage text
- hooking up most of these new options is TODO
* clean up the way libc and libc++ are detected via command line
options. target information is used to determine if any of the libc
candidate names are chosen.
* add native library directory detection
* implement the ability to invoke clang from stage2
* introduce a build_options.have_llvm so we can comptime branch
on whether LLVM is linked in or not.
