Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nogo: unexpected container type in IndexExpr #3164

Open
uhthomas opened this issue May 24, 2022 · 1 comment
Open

nogo: unexpected container type in IndexExpr #3164

uhthomas opened this issue May 24, 2022 · 1 comment

Comments

@uhthomas
Copy link

What version of rules_go are you using?

0.32.0

What version of gazelle are you using?

0.25.0

What version of Bazel are you using?

5.1.2

Does this issue reproduce with the latest releases of all the above?

Yes.

What operating system and processor architecture are you using?

macos aarch64, also tested on Linux x86_64

Any other potentially useful information about your toolchain?

Seems related to golang/go#52834, but using golang.org/x/tools v0.1.11-0.20220518213611-904e24e9fcf9 does not seem to make a difference.

What did you do?

nogo(
    name = "nogo",
    visibility = ["//visibility:public"],
    deps = ["@org_golang_x_tools//go/analysis/passes/buildssa"],
)
type A struct{}

func someFunc[T any]() {}

var _ = someFunc[A]

What did you expect to see?

A successful build.

What did you see instead?

(13:13:40) ERROR: /Users/thomas/<redacted>.a failed: (Exit 1): builder failed: error executing command bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/external/go_sdk/builder compilepkg -sdk external/go_sdk -installsuffix darwin_arm64 -src <redacted>.go -embedroot '' ... (remaining 22 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox
compilepkg: panic: unexpected container type in IndexExpr: func[T any]()

goroutine 18 [running]:
golang.org/x/tools/go/ssa.(*builder).expr0(0x1400018f9f0, 0x1400035b6c0, {0x104851e28?, 0x140001902a0?}, {0x7, {0x104851638, 0x140002e3f00}, {0x0, 0x0}})
        external/org_golang_x_tools/go/ssa/builder.go:897 +0x2080
golang.org/x/tools/go/ssa.(*builder).expr(0x1048515c0?, 0x1400035b6c0, {0x104851e28?, 0x140001902a0?})
        external/org_golang_x_tools/go/ssa/builder.go:610 +0x134
golang.org/x/tools/go/ssa.(*builder).assign(0x104814940?, 0x14000316f60?, {0x104852690?, 0x1049beac0}, {0x104851e28?, 0x140001902a0?}, 0x0?, 0x0)
        external/org_golang_x_tools/go/ssa/builder.go:583 +0x320
golang.org/x/tools/go/ssa.(*Package).build(0x140000cd000)
        external/org_golang_x_tools/go/ssa/builder.go:2477 +0x9b4
sync.(*Once).doSlow(0x140001d4240?, 0x1400019e000?)
        GOROOT/src/sync/once.go:68 +0x10c
sync.(*Once).Do(...)
        GOROOT/src/sync/once.go:59
golang.org/x/tools/go/ssa.(*Package).Build(...)
        external/org_golang_x_tools/go/ssa/builder.go:2413
golang.org/x/tools/go/analysis/passes/buildssa.run(0x14000302ea0)
        external/org_golang_x_tools/go/analysis/passes/buildssa/buildssa.go:73 +0x13c
main.(*action).execOnce(0x140000a0630)
        external/io_bazel_rules_go/go/tools/builders/nogo_main.go:301 +0x764
sync.(*Once).doSlow(0x0?, 0x0?)
        GOROOT/src/sync/once.go:68 +0x10c
sync.(*Once).Do(...)
        GOROOT/src/sync/once.go:59
main.(*action).exec(0x0?)
        external/io_bazel_rules_go/go/tools/builders/nogo_main.go:245 +0x44
main.execAll.func1(0x0?)
        external/io_bazel_rules_go/go/tools/builders/nogo_main.go:239 +0x50
created by main.execAll
        external/io_bazel_rules_go/go/tools/builders/nogo_main.go:237 +0x48
@farhaven
Copy link
Contributor

We're seeing the same with rules_go 0.33.0

farhaven added a commit to farhaven/rules_go that referenced this issue Jun 22, 2022
…Go >=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jun 22, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jun 23, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jul 12, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jul 14, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jul 18, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
farhaven added a commit to farhaven/rules_go that referenced this issue Jul 18, 2022
…=1.18

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix bazelbuild#3211 (and probably bazelbuild#3164 as well).
linzhp pushed a commit that referenced this issue Jul 19, 2022
…=1.18 (#3212)

This mirrors what golang.org/x/tools/go/packages does when loading packages.

Should fix #3211 (and probably #3164 as well).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants