When building Zig compiler from source using the build from the latest master branch:
$ git clone git@github.com:ziglang/zig && cd zig
$ /freshly-downloaded-zig/zig build --prefix stage4 -Dno-lib
Which standard library is used by the compiler? That is, if there’s an @import("std") in complier’s source code, would that std refer to files in the /freshly-downloaded-zig (like it wold do for any normal Zig program) or to files in the zig repository?
you can check by running zig env and looking at the std_dir value. It is determined based on the location of the zig executable.
from readme:
At runtime, the executable searches up the file system for the lib/ directory, relative to itself:
- lib/
- lib/zig/
- …/lib/
- …/lib/zig/
- (and so on)
To clarify, I am asking not about the general case, but about building the compiler itself. At some point, it has to use the lib from the repository itself, so there has to be some extra logic for this case, and I am curious which is that logic exactly.
This is a general question I’ve been thinking about recently, but it is also related to a particular issue I am facing. I am hacking on the compiler and I’ve modified AstGen.zig, but it seems that my changes are not “picked up”. So I am wondering if I am using the right AstGen in the first place.
Change in question:
(it includes if (true) @panic() in the AstGen.generate, just so that I can be sure I am using the right one)
I am building the compiler with
./zig-master build --prefix stage4 # also with and without `-Dno-lib`
Then, I am using this freshly build compiler to run a test:
$ ./stage4/bin/zig build test-cases -Dtest-filter="trailing"
And it just doesn’t panic where I expect it to
maybe try to specify the modified std library using the --zig-lib-dir [path] argument?
I think the answer you were given is relevant to your use case.
When I edit the zig stdlib I rebuild using your command and changes are picked up, but the zig executable I use was also compiled from that same repository (with -Dno-lib, placed under a directory nested inside build/) so it uses the repo’s /lib/std (by trying to find that path going up).
If you’re using a zig from a different installation it will use its own stdlib using the search algo mentioned in the other comment.
The output of AstGen (binary ZIR data) is cached per-file inside the z subdir of the respective cache directory. The cache namespace includes the zig version (e.g. 0.14.0-dev.202+ab4eeb770) which is how Zig users are protected from false positive cache hits.
When you modify AstGen and recompile the compiler, the zig version does not change unless you ask it to, so it hits the same cache namespace.
This is intentional, so you can test changes to the compiler that interact with existing cache artifacts. However, you must be aware of this when editing AstGen so that you can clear the ZIR cache or change the cache namespace to have your AstGen changes picked up.
Assuming I understand you correctly, there is no such extra logic. zig env is indeed reporting the very same lib directory that will be picked up when building the compiler itself.
Ok, yeah, sorry that it required three different people to say me this in a way that makes me understand 
To rephrase this, there are actually two different ways you can use zig-master downloaded from Download ⚡ Zig Programming Language to build the compiler:
Option A)
$ git clone https://github.com/ziglang/zig && cd zig
$ ~/downloads/zig-master/zig build
Option B)
$ git clone https://github.com/ziglang/zig && cd zig
$ cp ~/downloads/zig-master/zig ./zig
$ ./zig build
Although the compiler binary is the same, the standard library is different. Option A uses the standard library downloaded with zig-master, Option B uses the standard library from the Zig repository.
Here’s what actually happens on CI:
bootstrap “runs” a pre-compiled WASM zig compiler from the root directory of the repository, so it picks up the lib from the repository (indeed, unlike the case where you download a compiler from the internet, there’s no any other lib in sight). So that’s essentially Option B.
Note that those lines you linked are only the part of the CI script that is testing one particular way to build from source. The main testing that the CI does is later, on line 65:
This is the bulk of the testing that the CI is doing, and the binary that it uses is created by the cmake build process which you can see just a few lines up.
I’m not sure why you equate the bootstrap.c build to your Option B? It’s not mixing artifacts downloaded from master branch and a prebuilt binary. The only prebuilt things being used here is LLVM libraries and a C++ compiler (in the form of zig c++).