You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The go/types.Config struct has a Sizes field that specifies the function that the type checker should use to compute the size of a type. This function is itself a function of the CPU architecture and potentially the OS or toolchain as well. Only the underlying build system (go list, blaze, bazel) knows authoritatively what size to use, so go/packages should obtain this information from the build system rather than guessing based on GOARCH as it does now. One way to do this is to ask the underlying build system to compile a tiny program and inspect the compiler output.
The text was updated successfully, but these errors were encountered:
When using the go command, go env -json provides GOOS/GOARCH but not the compiler.
go list -e -f {{context}} provides all three (semi-related #27915)
But you can only use that info reliably when compiler = gc since go/types only has size info for gc (though presumably they're the same for gccgo and it's approximately safe to assume no other compilers exist).
In general, compiling a test program sounds necessary but it might be faster to skip that step when using the go command and the go command is using the gc compiler?
Yes, it's fine to skip the compilation step if you can compute the result accurately some other way. The necessary logic will be driver-specific, and each writer should know what range of OS/ARCH pairs are feasible.
The
go/types.Config
struct has aSizes
field that specifies the function that the type checker should use to compute the size of a type. This function is itself a function of the CPU architecture and potentially the OS or toolchain as well. Only the underlying build system (go list, blaze, bazel) knows authoritatively what size to use, so go/packages should obtain this information from the build system rather than guessing based on GOARCH as it does now. One way to do this is to ask the underlying build system to compile a tiny program and inspect the compiler output.The text was updated successfully, but these errors were encountered: