zig: 0.9.1 -> 0.10.1 #210324

strager · 2023-01-12T08:09:06Z

Description of changes

Things done

AndersonTorres · 2023-01-12T13:57:49Z

It does more than merely add Zig. Why not concentrate this on the llvm? After that I can rebase and test on my already open PR.

strager · 2023-01-12T19:13:58Z

It does more than merely add Zig. Why not concentrate this on the llvm? After that I can rebase and test on my already open PR.

See my note at the top of the PR:

This pull request is based on #209536. Please only consider the last commit in my PR.

andrewrk

Looks great. I like what you did with coreutils env.

AndersonTorres · 2023-01-12T22:02:04Z

See my note at the top of the PR:

Sorry, I can't ignore the whole context.

If you are saying that I should pretend your PR contains the zig update and nothing else (therefore, you are not willing to take any responsibility about the other commits in this PR), then I should equally pretend this PR is superfluous and close it.

What does your "look only to the latest commit please" pull request bring to the table that can't be grafted on the already opened one?

strager · 2023-01-12T22:15:22Z

If you are saying that I should pretend your PR contains the zig update and nothing else (therefore, you are not willing to take any responsibility about the other commits in this PR), [...]

This is not what I meant. I meant that only the last commit in this PR is really up for review. I also meant that this PR should merge only after #209536 merges. I should have worded it more clearly.

I wanted to express this in the GitHub PR tool, but it wouldn't let me pick #209536's branch as the base branch.

[...], then I should equally pretend this PR is superfluous and close it.

Huh? I don't understand. Why should we pretend that my PR is superfluous? The purpose of this PR is to share the Zig update commit (8054072) which I called out twice now.

You are free to ignore my PR, but I don't know why you're being what I perceive as hostile (e.g. suggesting my PR be closed).

What does your "look only to the latest commit please" pull request bring to the table that can't be grafted on the already opened one?

The already-opened PR (#199947) was owned by you, so I could not modify it (I think). And even if I could, I think it'd be unprofessional for me to change your PR.

I tested my PR. Even better, CI can test my PR. If I exclude the LLVM commits (which is what I think you're suggesting), CI could not test my PR.

andrewrk · 2023-01-12T22:23:01Z

@AndersonTorres it is common for a PR to be opened in anticipation of another one being merged. This allows to move forward faster, since it can be reviewed ahead of time, tested ahead of time, and then rebased once the prerequisite PR is merged.

You are not being asked to pretend anything; only to wait until the other PR is merged before dealing with this PR. Or, if you feel generous, you can offer review on the last commit in this PR, potentially saving a future review round trip for yourself and for @strager.

vegerot · 2023-01-12T22:29:23Z

@strager I support you. Have you considered setting the base branch of your PR to #209536 ?

That has other weirdnesses too, like someone merging this PR before #209536 is merged would mess that PR up. But it would accurately show the diff.

Besides, if you believe this PR shouldn’t be merged now (for some reason) then consider marking it as a Draft until then.

Just my opinion, but imo since this PR is getting so much pushback I would change the base branch and mark it as a Draft

Edit: I see you did try changing the branch. In that case, forget Anderson

vegerot · 2023-01-12T22:31:44Z

(or look into a tool like ReviewStack / Sapling) that is more capable of handling these kinds of reviews

Et7f3 · 2023-01-13T02:30:57Z

@AndersonTorres it is common for a PR to be opened in anticipation of another one being merged. This allows to move forward faster, since it can be reviewed ahead of time, tested ahead of time, and then rebased once the prerequisite PR is merged.

using commit of another PR also has the advantages to test two PR at once. We see that llvm if working fine (ci of my PR) + another project that use it the test suite of zig confirm llvm is working. Here I reviewed this PR and @strager will be able to work on the PR while waiting for llvm to be merged so multithreading :)

I tested to build and it seem to fail on x86_64-darwin I got this error from the log:

thread 47121201 panic: attempt to unwrap error: OSVersionDetectionFail
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
[ 90%] Building CXX object CMakeFiles/zigstage1.dir/src/stage1/heap.cpp.o
[ 91%] Building CXX object CMakeFiles/zigstage1.dir/src/stage1/ir.cpp.o
[ 91%] Building CXX object CMakeFiles/zigstage1.dir/src/stage1/ir_print.cpp.o
[ 92%] Building CXX object CMakeFiles/zigstage1.dir/src/stage1/mem.cpp.o
[ 92%] Building CXX object CMakeFiles/zigstage1.dir/src/stage1/os.cpp.o
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/os.zig:2812:19: 0x107aaac62 in std.os.mkdiratZ (zig2)
        .NOENT => return error.FileNotFound,
                  ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/os.zig:2767:9: 0x107aaa968 in std.os.mkdirat (zig2)
        return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
        ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/fs.zig:1426:9: 0x107aaa876 in std.fs.Dir.makeDir (zig2)
:
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/process.zig:373:46: 0x107b33362 in std.process.getEnvVarOwned (zig2)
        const result = os.getenv(key) orelse return error.EnvironmentVariableNotFound;
                                             ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/os.zig:2812:19: 0x107aaac62 in std.os.mkdiratZ (zig2)
        .NOENT => return error.FileNotFound,
                  ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/os.zig:2767:9: 0x107aaa968 in std.os.mkdirat (zig2)
        return mkdiratZ(dir_fd, &sub_dir_path_c, mode);
        ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/fs.zig:1426:9: 0x107aaa876 in std.fs.Dir.makeDir (zig2)
        try os.mkdirat(self.fd, sub_path, default_new_dir_mode);
        ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/os.zig:1745:22: 0x107c80c1d in std.os.openatZ (zig2)
            .PERM => return error.AccessDenied,
                     ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/fs.zig:1175:13: 0x107aa2b62 in std.fs.Dir.openFileZ (zig2)
            try os.openatZ(self.fd, sub_path, os_flags, 0);
            ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/fs.zig:1102:9: 0x107a9ead0 in std.fs.Dir.openFile (zig2)
        return self.openFileZ(&path_c, flags);
        ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/fs.zig:2041:20: 0x107cd04bb in std.fs.Dir.readFile (zig2)
        var file = try self.openFile(file_path, .{});
                   ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/zig/system/darwin/macos.zig:71:13: 0x107b2e147 in std.zig.system.darwin.macos.detect (zig2)
            return error.OSVersionDetectionFail;
            ^
/tmp/nix-build-zig-0.10.0.drv-0/source/lib/std/zig/system/NativeTargetInfo.zig:72:23: 0x107b2d527 in std.zig.system.NativeTargetInfo.detect (zig2)
            .macos => try darwin.macos.detect(&os),
                      ^
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/main.zig:4945:5: 0x107a78d82 in main.detectNativeTargetInfo (zig2)
    return std.zig.system.NativeTargetInfo.detect(cross_target);
    ^
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/main.zig:3902:29: 0x107a73c35 in main.cmdBuild (zig2)
        const target_info = try detectNativeTargetInfo(cross_target);
                            ^
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/main.zig:261:9: 0x1079ff26a in main.mainArgs (zig2)
        return cmdBuild(gpa, arena, cmd_args);
        ^
???:?:?: 0x1093f690c in ___zig_fail_unwrap (???)
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/stage1.zig:56:43: 0x1079fe268 in main (zig2)
        stage2.mainArgs(gpa, arena, args) catch unreachable;
                                          ^
???:?:?: 0x1149a451d in ??? (???)
???:?:?: 0x0 in ??? (???)
make[2]: *** [CMakeFiles/stage3.dir/build.make:71: CMakeFiles/stage3] Abort trap: 6
make[1]: *** [CMakeFiles/Makefile2:260: CMakeFiles/stage3.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

I can't debug right now (because I already debug another Darwin failure) and it seems more zig specific. I have Darwin sandbox activated.

I don't know if the call stack is optimized/normal or a bug ???:?:?: 0x1093f690c in ___zig_fail_unwrap (???)

AndersonTorres · 2023-01-13T04:12:12Z

This is not what I meant. I meant that only the last commit in this PR is really up for review. I also meant that this PR should merge only after #209536 merges. I should have worded it more clearly.

OK.

Why should we pretend that my PR is superfluous?

In a certain sense, both PRs cannot be merged as is, because they modify the same files, have the same ending purpose, and any one of them can be accepted to the prejudice of the other.

The only relevant difference between mine and yours is the cherry-picking of LLVM-related snippets that, according to you, are not the most relevant part of this PR.

At least in a large sense, one of them must go. Or, if you think this is too harsh, your PR supercedes or at least is equivalent to mine.

I don't know why you're being what I perceive as hostile (e.g. suggesting my PR be closed).

You did not explain what was your purpose when you opened this PR. Your two messages

#199947 (comment)

#210324 (comment)

say absolutely nothing besides "hey I opened a PR".

And even if I could, I think it'd be unprofessional for me to change your PR.

You could cherry-pick the same way you did with the LLVM-related ones. At least I would be able compare the effective differences between them and hopefully merge a conjoined work.

pkgs/development/compilers/zig/default.nix

AndersonTorres · 2023-01-13T04:23:47Z

pkgs/development/compilers/zig/default.nix

@@ -59,16 +38,20 @@ stdenv.mkDerivation rec {
    export HOME=$TMPDIR;
  '';

+  patchPhase = ''


Suggested change

patchPhase = ''

postPatch = ''

strager · 2023-01-13T04:53:29Z

@Et7f3 I tried on my AArch64 macOS machine. I get a different failure:

[snip]
warning(link): directory not found for '-L/nix/store/g8b81w9kpb82gm7702ca692mp5flm7
pf-apple-framework-CoreFoundation-11.0.0/lib'                                      
thread 24436935 panic: incorrect alignment                                         
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/link/MachO/Object.zig:114:72: 0x
101565863 in link.MachO.Object.parse (zig2)
                    @alignCast(@alignOf(macho.nlist_64), &self.contents[symtab.symo
ff]),
                                                                       ^
/private/tmp/nix-build-zig-0.10.0.drv-0/source/src/link/MachO/Archive.zig:230:21: 0
x10157a5af in link.MachO.Archive.parseObject (zig2)
    try object.parse(gpa, cpu_arch);
                    ^
[snip]

I'll debug what I see, and maybe that will fix the x86_64 build too.

andrewrk · 2023-01-13T04:55:39Z

0.10.1 will be tagged soon, within 1-2 weeks. This could potentially be fixed by one of the many bug fixes that made it into that tag.

You might consider testing with the 0.10.x branch.

strager · 2023-01-13T06:26:32Z

You might consider testing with the 0.10.x branch.

I see the same problem with the 0.10.x branch, but the build works on my MacBook Pro on master (Zig commit 7cb2f9222da38d687e8708dd5d94d3175cc77995). I'm bisecting now.

andrewrk · 2023-01-13T20:38:18Z

Speaking for upstream, unfortunately, there are a lot of bug fixes in master branch that cannot be cherry-picked to 0.10.x because the branches have already diverged quite a bit. So unless the fix is a small patch that can be applied cleanly, we may be stuck with the bug in 0.10.1. I expect the quality of 0.11.0 to be much higher (this is related to deleting the old compiler which happened after releasing 0.10.0).

AndersonTorres · 2023-01-13T22:00:49Z

If this minor release series will be "irredeemably buggy", should we bring the unstable/master release instead?

TBH I was planning this a long time ago, but there was no serious use for a master branch of zig.

AndersonTorres · 2023-01-14T03:02:31Z

@andrewrk, is there a policy of Long Term Support on Zig? Or an update in a minor version is sufficient to consider it deprecated?

andrewrk · 2023-01-14T03:19:13Z

Zig follows Semantic Versioning.

edrex · 2023-01-19T20:42:28Z

zig 0.10.1 released today https://github.com/ziglang/zig/releases/tag/0.10.1

Aside: I tried using this to package some Zig river utils (stacktile and levee) and they error out in the same way (curl https://termbin.com/0ejca with ANSI color) so I'm waiting on 0.10.1 to try again.

Anton-4 · 2023-01-21T18:28:40Z

@AndersonTorres do you have the time to review this again or might someone else be able to help out?

We at roc-lang are also blocked on this PR and I would really appreciate your input :)

AndersonTorres · 2023-01-21T18:32:27Z

There are many blockers to solve here. The code does not even compile outside x64-linux.

Anton-4 · 2023-01-21T18:54:55Z

I see, in any case, thanks for your quick reply!

@strager could it be that using zig 0.10.1 here would fix the issues on darwin?

strager · 2023-01-24T08:35:27Z

@strager could it be that using zig 0.10.1 here would fix the issues on darwin?

Nope. Zig 0.10.1 on Darwin still has issues.

strager · 2023-01-24T08:35:49Z

There are many blockers to solve here.

What blockers are you referring to?

strager · 2023-01-24T08:36:53Z

I updated this PR to use Zig 0.10.1 instead of Zig 0.10.0.

wegank · 2023-01-28T06:56:11Z

Please rebase :-)

Several Zig-using packages are broken with a newer version of Zig, and other packages are blocked on a Zig upgrade. Prepare for two Zig versions side-by-side by renaming default.nix to 0.9.1.nix.

On Linux, upgrade Zig to version 0.10.1. On macOS/Darwin, Zig version 0.10.1 is broken, so keep 0.9.1. Several Zig-using packages are broken with Zig version 0.10.1, so pin those packages to Zig version 0.9.1.

strager · 2023-01-28T08:01:55Z

LLVM 15 landed in #194634. I rebased my PR on top of it.

wegank · 2023-02-01T00:13:29Z

@AndersonTorres Is this PR good to go?

AndersonTorres · 2023-02-01T00:20:35Z

LGTM

ncdu 2.x is written in zig [1]. Zig is not stable. It was recently updated from 0.9.x to 0.10.x [2]. Some logic tried to keep 0.9.x on macOS [3], but it did not work [4]. ``` error: Package ‘zig-0.10.1’ in /nix/store/bqq0f9qwk3nn3icrzl5sfpmfbqb6yz95-nixpkgs/pkgs/development/compilers/zig/0.10.nix:59 is marked as broken, refusing to evaluate. ``` [1] https://dev.yorhel.nl/doc/ncdu2 [2] NixOS/nixpkgs#210324 [3] NixOS/nixpkgs@db76c9e [4] NixOS/nixpkgs#214545

strager requested a review from matthewbauer as a code owner January 12, 2023 08:09

strager mentioned this pull request Jan 12, 2023

zig: 0.9.1 -> 0.10.0 #199947

Closed

13 tasks

ofborg bot added the 8.has: package (new) label Jan 12, 2023

ofborg bot requested review from AndersonTorres, lovek323, 7c6f434c, andrewrk, primeos, dtzWill and aiotter January 12, 2023 08:21

ofborg bot added 10.rebuild-darwin: 11-100 10.rebuild-linux: 11-100 labels Jan 12, 2023

andrewrk approved these changes Jan 12, 2023

View reviewed changes

strager mentioned this pull request Jan 12, 2023

Add llvm packages 15 #209536

Closed

13 tasks

AndersonTorres reviewed Jan 13, 2023

View reviewed changes

pkgs/development/compilers/zig/default.nix Outdated Show resolved Hide resolved

AndersonTorres reviewed Jan 13, 2023

View reviewed changes

strager force-pushed the zig-0.10.0 branch from 010d23d to 745da0d Compare January 14, 2023 07:26

ofborg bot requested a review from AndersonTorres January 14, 2023 07:38

strager force-pushed the zig-0.10.0 branch from 745da0d to 47940bc Compare January 24, 2023 08:36

strager changed the title ~~zig: 0.9.1 -> 0.10.0~~ zig: 0.9.1 -> 0.10.1 Jan 24, 2023

strager mentioned this pull request Jan 28, 2023

llvmPackages_15: init at 15.0.7 #194634

Merged

92 tasks

strager added 2 commits January 28, 2023 00:01

zig: rename to zig_0_9 to prepare for version 0.10

aea9b20

Several Zig-using packages are broken with a newer version of Zig, and other packages are blocked on a Zig upgrade. Prepare for two Zig versions side-by-side by renaming default.nix to 0.9.1.nix.

zig_0_10: init at 0.10.1

db76c9e

On Linux, upgrade Zig to version 0.10.1. On macOS/Darwin, Zig version 0.10.1 is broken, so keep 0.9.1. Several Zig-using packages are broken with Zig version 0.10.1, so pin those packages to Zig version 0.9.1.

strager force-pushed the zig-0.10.0 branch from 47940bc to db76c9e Compare January 28, 2023 08:01

ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 and removed 10.rebuild-darwin: 11-100 10.rebuild-linux: 11-100 labels Jan 28, 2023

This was referenced Jan 28, 2023

river: 0.2.1 -> 0.2.3 #213167

Merged

ncdu_2: 2.2.1 -> 2.2.2 #213169

Merged

wegank merged commit 70a2347 into NixOS:master Feb 1, 2023

Anton-4 mentioned this pull request Feb 21, 2023

bad alignment cast in macho linking code ziglang/zig#14558

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

zig: 0.9.1 -> 0.10.1 #210324

zig: 0.9.1 -> 0.10.1 #210324

strager commented Jan 12, 2023 •

edited

AndersonTorres commented Jan 12, 2023

strager commented Jan 12, 2023

andrewrk left a comment

AndersonTorres commented Jan 12, 2023

strager commented Jan 12, 2023

andrewrk commented Jan 12, 2023 •

edited

vegerot commented Jan 12, 2023 •

edited

vegerot commented Jan 12, 2023

Et7f3 commented Jan 13, 2023 •

edited

AndersonTorres commented Jan 13, 2023

AndersonTorres Jan 13, 2023

strager commented Jan 13, 2023

andrewrk commented Jan 13, 2023 •

edited

strager commented Jan 13, 2023

andrewrk commented Jan 13, 2023

AndersonTorres commented Jan 13, 2023

AndersonTorres commented Jan 14, 2023

andrewrk commented Jan 14, 2023

edrex commented Jan 19, 2023

Anton-4 commented Jan 21, 2023

AndersonTorres commented Jan 21, 2023

Anton-4 commented Jan 21, 2023

strager commented Jan 24, 2023

strager commented Jan 24, 2023

strager commented Jan 24, 2023

wegank commented Jan 28, 2023

strager commented Jan 28, 2023

wegank commented Feb 1, 2023

AndersonTorres commented Feb 1, 2023

zig: 0.9.1 -> 0.10.1 #210324

zig: 0.9.1 -> 0.10.1 #210324

Conversation

strager commented Jan 12, 2023 • edited

Description of changes

Things done

AndersonTorres commented Jan 12, 2023

strager commented Jan 12, 2023

andrewrk left a comment

Choose a reason for hiding this comment

AndersonTorres commented Jan 12, 2023

strager commented Jan 12, 2023

andrewrk commented Jan 12, 2023 • edited

vegerot commented Jan 12, 2023 • edited

vegerot commented Jan 12, 2023

Et7f3 commented Jan 13, 2023 • edited

AndersonTorres commented Jan 13, 2023

AndersonTorres Jan 13, 2023

Choose a reason for hiding this comment

strager commented Jan 13, 2023

andrewrk commented Jan 13, 2023 • edited

strager commented Jan 13, 2023

andrewrk commented Jan 13, 2023

AndersonTorres commented Jan 13, 2023

AndersonTorres commented Jan 14, 2023

andrewrk commented Jan 14, 2023

edrex commented Jan 19, 2023

Anton-4 commented Jan 21, 2023

AndersonTorres commented Jan 21, 2023

Anton-4 commented Jan 21, 2023

strager commented Jan 24, 2023

strager commented Jan 24, 2023

strager commented Jan 24, 2023

wegank commented Jan 28, 2023

strager commented Jan 28, 2023

wegank commented Feb 1, 2023

AndersonTorres commented Feb 1, 2023

strager commented Jan 12, 2023 •

edited

andrewrk commented Jan 12, 2023 •

edited

vegerot commented Jan 12, 2023 •

edited

Et7f3 commented Jan 13, 2023 •

edited

andrewrk commented Jan 13, 2023 •

edited