-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make self-hosted the default compiler #12368
Conversation
bf23aa9
to
0326d61
Compare
YOOOOOOOOOOOOOOOOO |
Hang on a minute. #89 now says
So what's the plan there? Do we fall back to stage1 if we see it? Do we just break all code? I feel like I must be out of the loop here. |
See #12345 |
Re failures on macOS, I haven't been able to repro locally on arm64, however, I did notice that for folks linking against a system provided LLVM (e.g., installed via Homebrew, etc.), they will now be forced to manually specify system include and search dirs as well as sysroot path. In order to avoid this silliness, here's my patch suggestion: diff --git a/src/main.zig b/src/main.zig
index d041036b9..758d27084 100644
--- a/src/main.zig
+++ b/src/main.zig
@@ -2375,14 +2375,9 @@ fn buildOutputType(
}
}
- if (comptime builtin.target.isDarwin()) {
- // If we want to link against frameworks, we need system headers.
- if (framework_dirs.items.len > 0 or frameworks.count() > 0)
- want_native_include_dirs = true;
- }
-
if (sysroot == null and cross_target.isNativeOs() and
- (system_libs.count() != 0 or want_native_include_dirs))
+ (system_libs.count() != 0 or want_native_include_dirs or
+ comptime builtin.target.isDarwin()))
{
const paths = std.zig.system.NativePaths.detect(arena, target_info) catch |err| {
fatal("unable to detect native system paths: {s}", .{@errorName(err)}); In other words, if we are native and targeting Darwin, add system include and search dirs by default, and additionally, try locating the sysroot automatically too. |
I did hit this when running a couple of test suites on arm64 macOS:
|
Instead of breaking existing projects with the upgrade, could sema detect usage of async (or other unsupported feature) and automatically switch to stage1? |
I thought about this. I think that the convenience it brings is outweighed by the confusion it might cause, of people not knowing which compiler implementation they are using. I think it should be an intentional choice, and the first question I'm going to ask someone when they report a bug is, "what CLI invocation are you using?" which will tell me which compiler they are using. If it depended on the code, bugs would be harder to diagnose. Also keep in mind this is transitional period. At some point between now and the next release, this option just disappears entirely. Also note that for your project you can set stage1 = true in your build script, preventing any users from having to follow any extra directions. |
The aarch64-linux CI failure is #12360 |
0326d61
to
bae5cb3
Compare
I fail at the same test
|
bae5cb3
to
17511a4
Compare
39cc242
to
dc29145
Compare
d3be887
to
4437f05
Compare
eb31461
to
d5d829e
Compare
This updates to a stage3 freebsd tarball.
For both macOS and FreeBSD.
Instead of a switch in a bash file we just properly name the pipeline steps. Also use zig build to produce the release artifact.
it was returning a pointer to a parameter.
This includes a few recent bug fixes which may solve the Windows CI failure.
Simplify the script by not creating an unnecessary build directory and then changing directories to and from it.
This was present in stage1 but missing from self-hosted.
* accept forward and backward slashes in file paths * strip multiple extensions; e.g. if the basename is "test.exe.obj" then it strips to "test".
7152a58
to
e78e9f3
Compare
empirically this avoids a segfault on the CI.
Congratulations @andrewrk ! This is huge! |
Some recent change makes slice concatenation runtime (merge #12368), so the example needs to be explicitly made comptime.
stage2 has been merged and set as default around end of aug 2022 in ziglang/zig#12368. since then the main focus has been on this new stage2 compiler. with the release of 0.10.1 the stage2 is fairly useable now and it is the way forward, towards zig 0.11 or 1.0. read more about difference in https://github.com/ziglang/zig/wiki/Self-Hosted-Compiler-Upgrade-Guide another good read on the relevant topic is https://ziglang.org/news/goodbye-cpp/
stage1 is available behind the
-fstage1
flag.closes #89
Merge Blockers
General
add valgrind integration to self-hostedI'll do this laterx86_64-freebsd
aarch64-linux:
x86_64-linux:
x86_64-macos:
x86_64-windows: