#1037409 golang-golang-x-exp ftbfs with gccgo-go (both gccgo-12 and gccgo-13)

Package:
src:golang-golang-x-exp
Source:
src:golang-golang-x-exp
Submitter:
Pirate Praveen
Date:
2026-06-03 06:31:00 UTC
Severity:
normal
#1037409#5
Date:
2023-06-12 12:53:39 UTC
From:
To:
Building with golang-any changed to gccgo-go to force gccgo on amd64,
build fails with error. Full build log attached. Either this should be
fixed or dependency should be updated to golang-go instead of golang-any.

golang.org/x/exp/maps
# golang.org/x/exp/maps
src/golang.org/x/exp/maps/maps.go:10:10: error: expected ‘(’
    10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
       |          ^
src/golang.org/x/exp/maps/maps.go:10:13: error: invalid character 0x7e
in input file
    10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
       |             ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘]’
    11 |         r := make([]K, 0, len(m))
       |         ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘;’ or newline
after top level declaration
src/golang.org/x/exp/maps/maps.go:12:9: error: expected declaration
    12 |         for k := range m {
       |         ^
src/golang.org/x/exp/maps/maps.go:14:9: error: expected declaration
    14 |         }
       |         ^
src/golang.org/x/exp/maps/maps.go:15:9: error: expected declaration
    15 |         return r
       |         ^
src/golang.org/x/exp/maps/maps.go:16:1: error: expected declaration
    16 | }
       | ^
#1037409#10
Date:
2023-10-23 22:39:18 UTC
From:
To:
Control: severity -1 important

Seems like gccgo is not able to recognize tilde -- could that be an
issue at the toolchain level itself?

I'm also reducing the severity to important since this does build in
principle. Perhaps the B-D should be changed to golang-go explicitly.

Best,
Nilesh
#1037409#17
Date:
2026-06-03 06:30:21 UTC
From:
To:
Isn't it better to use B-D:golang-any and catch these failures in the
build logs, instead of changing to B-D:golang-go which would mean they
hang indefinitely waiting for a build dependency that doesn't exist on
the ports that doesn't have golang-any?  I would regard this as a bug in
the gccgo-go environment that doesn't support some language elements.
If that bug were to be fixed, it seems bad to have modified this package
to use golang-go which would then have to be changed back to golang-any.
I think this is a fairly common problem for many Go packages, so would
be nice to have a generic approach to dealing with this.  Does this
problem cause any practical problem in normal environments?

/Simon