cmd/go: not print not-defaults arch-env

[qiulaidongfeng]

Go version

go version devel go1.23-38d8d01d3f Sat May 18 09:38:57 2024 +0800 windows/amd64

Output of go env in your module/workspace:

no need.

What did you do?

set GOAMD64=v3
./make.bat
..\bin\go env -changed

What did you see happen?

not print set GOAMD64=v3

What did you expect to see?

print set GOAMD64=v3

[gopherbot]

Change https://go.dev/cl/586241 mentions this issue: cmd/go: print not-defaults arch-env

[matloob]

I think the current behavior might be correct? When you run make.bat with GOAMD64=v3 you're essentially setting the default value for your go build to be v3. Then when you run env -changed, the default value is the same as the value in the environment so there should be no diff printed.

[qiulaidongfeng]

But I use

set GOAMD64=v1
make.bat
set GOAMD64=v3
..\bin\go env -changed

still won't print set GOAMD64=v3

[qiulaidongfeng]

For now, all arch-env , call EnvOrAndChanged the second parameter set now appears to be wrong, and its value is the relevant environment variable. (This means that there will be no non-default values because go will not get different values in internal/buildcfg and cmd/go/internal/cfg for the same environment variable such as GOAMD64.)

[qiulaidongfeng]

See https://go.dev/wiki/MinimumRequirements#amd64 , GOAMD64 default value is v1, set GOAMD64=v3 happen default value is v3 Nonconformity documentation.

[matloob]

Ultimately I think someone more familiar with dist and the GO microarchitecture variables should make the decision. But from my perspective the the "default" behavior is what happens when you don't change the environment.

Also we shouldn't be changing anything outside of the go command.

The behavior in

set GOAMD64=v1
make.bat
set GOAMD64=v3
..\bin\go env -changed

not printing set GOAMD64=v3 does seem incorrect. but we should be able to detect that without changing dist or the runtime

[qiulaidongfeng]

not printing set GOAMD64=v3 does seem incorrect. but we should be able to detect that without changing dist or the runtime

Most arch-env can, PR fix has been sent.

[gopherbot]

Change https://go.dev/cl/587177 mentions this issue: cmd/go: print some not-defaults arch-env

[qiulaidongfeng]

@matloob See https://go-review.googlesource.com/c/go/+/587177/comments/6ed22174_daf6f755?tab=comments , For now should submit https://go-review.googlesource.com/c/go/+/586241 or do other fix method?

[qiulaidongfeng]

I now confirm that when GOAMD64=v3, the default value of GOAMD64 is v3. If CL 586241 is going in the right direction, I can modify CL to ensure that the go command prints the default correctly and retain the current behavior of bootstrapping-when GOAMD64=v3, which defaults to v3.

[matloob]

I'm uncomfortable with exporting the defaultGO variables in buildcfg, but I can't think of a better way to do this. I wonder what the compiler team thinks about this. @cherrymui what do you think about exporting the defaultGO variables in buildcfg. Do you think that's okay?

[cherrymui]

I'm okay with exporting the defaultGO variables. It is an internal package anyway, and it is fine to be used by cmd/go. But I'm not really sure if we want to comparing them as strings. E.g. On ARM, the default is GOARM=7,hardfloat, but if you set GOARM=7 you get the same. Do we say it is "changed"?

[qiulaidongfeng]

But I'm not really sure if we want to comparing them as strings. E.g. On ARM, the default is GOARM=7,hardfloat, but if you set GOARM=7 you get the same. Do we say it is "changed"?

The current implementation running "go env-changed" will print because 7,hardfloat, and 7 are really two different values. (Whether the semantics are the same is not the same as whether the values are the same), CL will not be after, because exporting the defaultGO variables contain DefaultGOARM=7.

[matloob]

@cherrymui @qiulaidongfeng I think for the purposes of go env -changed printing that the value has changed if the strings have changed but the value hasn't is harmless. Similar to what @qiulaidongfeng said, we print that the value has changed for other variables when the values are different and the semantics are the same so I think it would be reasonable to do the same here? I think it would be reasonable to expect that anyone using go env -changed from a command line or script would understand that the semantics might not be different even if the values are.