Add GOARM64 platform constraints

[jarreds]

See https://go.dev/wiki/MinimumRequirements#arm64 for which options are surfaced in this PR.

What type of PR is this?

Feature

What does this PR do? Why is it needed?

Adds support for the GOARM64 environment variable via platform constraints, following the same pattern as the existing GOAMD64 and GOARM support.

New constraint settings under //go/constraints/arm64:

• Version: v8.0–v8.9, v9.0–v9.5 (defaults to v8.0 when unset)
• Extensions: lse and crypto (independent boolean constraint settings)

These are combined into the GOARM64 env var at build time, e.g. GOARM64=v9.0,lse,crypto.

Usage example:

platform(
    name = "my_arm64_platform",
    constraint_values = [
        "@platforms//cpu:aarch64",
        "@platforms//os:linux",
        "//go/constraints/arm64:v9.0",
        "//go/constraints/arm64:lse_on",
        "//go/constraints/arm64:crypto_on",
    ],
)

Which issues(s) does this PR fix?

Fixes #4556

Other notes for review

The implementation mirrors the existing amd64/arm pattern:

• go/constraints/arm64/BUILD.bazel — new constraint settings and values
• BUILD.bazel — go_config wired up with select() for version, lse, and crypto
• go/private/context.bzl — GoConfigInfo fields, go_config rule attrs, and GOARM64 env var construction

[fmeum]

I think that I would slightly prefer //go/constraints/lse:{on,off} for the constraints. We should also add explicit values for the defaults and declare them as the default on constraint_setting so that the selects don't need a default case.

@jayconrod @dzbarsky Do you agree or would you prefer different syntax?

[jarreds]

👍 I'll wait for consensus and then make the change.

[jayconrod]

Maybe a separate question: should this be a build_setting rather than a constraint_setting? build_setting is a user-specified flag that can modify how code is generated. constraint_setting is a property of the platform that affects toolchain selection. Since I don't think we need to select different toolchains based on GOARM64 or declare constraints in platform, build_setting seems like a better fit to me. It's similar to enabling -race or debug symbols.

[jayconrod]

If this is a build_setting, we could use a string_list_flag to let the user set it on the command line (or .bazelrc). We have a few flags already in //go/config.

[jarreds]

I think this is a good line of thinking. Perhaps one way to think a bit further would be to talk about usage. Here is currently how I began using this PR as-is:

platform_transition_filegroup(
    name = "server_image_linux_arm64",
    srcs = [":server_image"],
-   target_platform = "//:linux_arm64",
+   target_platform = "//:linux_arm64_graviton4",
)

Where the graviton4 platform had these ARM64 constraints set, and that kind of did all the magic downstream without having to think too much.

What might this look like with the build_setting?

Edit: we do target a couple of diff flavors of ARM64 in this one codebase, so the graviton4 flavor is not the only one.

[jayconrod]

You can use a transition to change any build setting. It looks like platform_transition_filegroup uses an internal transition that changes "//command_line_option:platforms" to the given label. transitions.bzl is the implementation.

platform_transition_filegroup looks like it can't handle any other settings, so it wouldn't work for this. Writing a new transition and similar wrapper rule would be a pretty small bit of code though.

Do you use //:linux_arm64_graviton4 for other toolchain selection outside of Go? Whether GOARM64 should be a constraint setting or a build setting is a little ambiguous to me. I'd only lean toward build setting for simplicity because Go doesn't need it for toolchain selection.

[dzbarsky]

Sorry, didn't get a notification on this thread, just stumbled upon it. I would slightly prefer to make this a constraint. While it's true that it doesn't affect compiler resolution, constraints have the advantage that they don't propogate into the exec configuration, which is usually fairly surprising for build flags. (I know there's work in Bazel itself to fix it but we support a few versions back so it will take a while before we can rely on that). Also, making it a constraint is more aligned with how platforms_contrib is thinking about modeling more complex platforms. @cerisier has been thinking about this problem a lot, he can share more

[fmeum]

I agree with David here, a constraint setting would match the intended semantics better, even if it takes a bit more effort to set up in rules_go.

[jayconrod]

Hmm, that's convincing. Let's go with a constraint setting then.

[dzbarsky]

BTW, I definitely don't want to block on this, but potentially this even belongs in @platforms_contrib so you can set it on your platform and all language rulesets can interpret it as appropriate. I think rust also has some rustc flags to set to target newer instruction sets, but it would be really nice to make it all work seamlessly.

I think once we figure that out we could potentially alias/deprecate these constraints, but not worth blocking progress here

[jayconrod]

Two additional things:

• Go build constraints like // go:build arm64.v8.1 can filter out source files. Let's make sure to apply those based on the GOARM64 setting. I don't think constraints are set based on lse or crypto, so don't worry about those. I'm not entirely sure where to add these settings, but go/build.Context.ToolTags might be the right place. We set go/build.Default.BuildTags in env.go.
• Let's test that setting GOARM64 works. A binary should be able to call runtime/debug.ReadBuildInfo() to read how it was built. There should be a key for GOARM64 in there. (Actually I'm not sure we populate that, so if we don't, we could just check that the build constraints are filtering the correct files.

[eightseventhreethree]

Really interested in this getting merged. Do we have an ETA when it will land?

[fmeum]

I'm planning to write a short design doc on this topic today and include this as an example. I hope to have a clear understanding of the design space at that point.

[fmeum]

The doc is out and it looks like it will be accepted: bazelbuild/bazel#28877

If you want to move this along, you could send a PR to add these constraints to https://github.com/bazel-contrib/platforms_contrib.