make test on Windows 10 under MSYS fails to compile the code

[krader1961]

Running make test on Windows 10 results in this failure:

gcc_libinit_windows.c: In function ‘x_cgo_sys_thread_create’:
gcc_libinit_windows.c:57:12: error: implicit declaration of function ‘_beginthread’ [-Werr
or=implicit-function-declaration]
   57 |  thandle = _beginthread(func, 0, arg);
      |            ^~~~~~~~~~~~
cc1: all warnings being treated as errors

That is apparently due to go test -race ./... requiring the tdm-gcc rather than the gcc compiler provided by MSYS. As a consequence every unit test fails. Running go test ./... succeeds.

This leads me to several questions. For example, this seems to work on AppVeyor CI. However, I can't tell if that's because it runs go test ./... or tdm-gcc is being installed and used so as to allow make test to work. I can't tell which is true because I can't figure out how the Elvish CI environment on AppVeyor is configured. Nor is there any documentation on how to configure Windows to support building and testing Elvish on that platform.

[krader1961]

Also, it's not clear if tdm-gcc is a prerequisite for building the Windows elvish binary that is available at https://elv.sh/get/. In other words, which toolchains are supported? While MSYS appears to be required, as a practical matter, to use Elvish on Windows it appears only the standard Go toolchain is needed to build it -- albeit with tdm-gcc as a prereq in order to execute go test -race ./....

[xiaq]

Hmm, AppVeyor uses a plain go test - the config file is .appveyor.yml. And that's exactly because I had problems with go test -race on Windows.

golang/go#27089 mentions that go test -race on Windows requires (some) GCC, and presumably some GCC builds are compatible with Go while others are not (I didn't find any specific reference to tdm-gcc there).

I'll just remove windows from the make test rule as we can't reliably determine whether the Windows environment has a suitable GCC binary.

[xiaq]

Also, this isn't really an Elvish-specific problem, but a Go toolchain issue.