Use -Werror (with exceptions) on Windows builds

[topolarity]

See JuliaLang/julia#54836 (comment)

I'm not sure we're ready to enable -Werror comprehensively on Windows (esp. retroactively), but this warning is a common one that is almost aways a bug to encounter.

[giordano]

I'm not sure we're ready to enable -Werror comprehensively on Windows

Last time I looked at a Windows build log there were still loads of warnings, but that was long time ago probably. If now they're all gone I think it should be safe to enable -Werror in the pipeline for master: we should have separate pipelines for the backport branches, right? And if a PR fails because it's on top of a very old revision of master than e rebase/merge should be enough to fix that.

[topolarity]

I think we still have a few warnings unfortunately, such as:

C:/msys64/mingw32/i686-w64-mingw32/include/psdk_inc/intrin-impl.h:2164:1: warning: array subscript 0 is outside array bounds of 'long unsigned int[0]' [-Warray-bounds]
--
  | 2164 \| __buildreadseg(__readfsdword, unsigned __LONG32, "fs", "l")
  | \| ^~~~~~~~~~~~~~

[topolarity]

On second thought... we should be able to get away with

-Werror -Wno-error=undef -Wno-error=unused-but-set-variable -Wno-error=strict-prototypes -Wno-error=attributes -Wno-error=array-bounds -Wno-error=infinite-recursion -Wno-error=c++-compat

Several of those seem straightforward to resolve, but it'd be nice to get the -Werror coverage in the mean time for those that can't.

Do you know how to provide a string with spaces to the JL_CFLAGS in the custom .arches format?

[giordano]

Do you know how to provide a string with spaces to the JL_CFLAGS in the custom .arches format?

No ☹️ I presume you already considered playing with various quotes?

[topolarity]

I think I found an incantation that works

(ShellCheck is not in love with it, but I can find no simple alternative that works and the wiki does specifically allow exceptions in https://www.shellcheck.net/wiki/SC2207)

Looks like this needs treehash signing before CI will give it a test run.

[ararslan]

We can't build v1.12.0-rc3 binaries for Windows because of this:

On x86-64 (log):

C:/workdir/src/debuginfo.cpp:307:14: error: variable 'catchjmp' set but not used [-Werror=unused-but-set-variable]
  307 |     uint8_t *catchjmp = NULL;
      |              ^~~~~~~~

On i686 (log):

C:/workdir/src/module.c:16:30: error: redeclaration of 'jl_bpart_get_kind' with different visibility (old visibility preserved) [-Werror]
   16 | EXTERN_INLINE_DEFINE uint8_t jl_bpart_get_kind(jl_binding_partition_t *bpart) JL_NOTSAFEPOINT;
      |                              ^~~~~~~~~~~~~~~~~

The commit that fixed the warning on x86-64 (JuliaLang/julia#59634) isn't on the release branch. That commit wouldn't fix the warning on i686 though.

I think we need to revert this in order to build the release binaries for Windows, then reapply (some version of?) it, and in the meantime backport the aforementioned commit to all relevant branches so that the next release won't hit the same situation.

cc @KristofferC

[giordano]

Don't the various minor versionz have separate pipelines?

[DilumAluthge]

Don't the various minor versionz have separate pipelines?

Yes, but by default each pipeline uses julia-buildkite#master.

[DilumAluthge]

It's easy to point a pipeline to a different branch. E.g. we could create a julia-buildkite#release-1.12 branch, and then point the 1.12 Buildkite config to that branch.

But by default, it defaults to julia-buildkite#master.

[DilumAluthge]

Let's proceed with the revert for now, just to unblock Alex.

This weekend, I'll set up some release branches in this repo.

And then we can re-land this PR once I have the release branches set up.

[ararslan]

Looks like we have a few release branches on this repo, but the most recent is for 1.9.

[DilumAluthge]

Looks like we have a few release branches on this repo, but the most recent is for 1.9.

I'll make release branches for 1.10, 1.11, and 1.12 then.

[DilumAluthge]

Looks like we have a few release branches on this repo, but the most recent is for 1.9.

I'll make release branches for 1.10, 1.11, and 1.12 then.

The release branches exist now.