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_main fail to build when to upgrade golang.org/x/tools #3640

Closed
hawkingrei opened this issue Aug 4, 2023 · 2 comments · Fixed by #3730
Closed

nogo_main fail to build when to upgrade golang.org/x/tools #3640

hawkingrei opened this issue Aug 4, 2023 · 2 comments · Fixed by #3730

Comments

@hawkingrei
Copy link
Contributor

What version of rules_go are you using?

What version of gazelle are you using?

What version of Bazel are you using?

Build label: 6.3.1-homebrew

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

if you update the tools like this

    go_repository(
        name = "org_golang_x_tools",
        build_file_proto_mode = "disable_global",
        importpath = "golang.org/x/tools",
        sum = "h1:ojD5zOW8+7dOGzdnNgersm8aPfcDjhMp12UfG93NIMc=",
        version = "v0.11.1",
    )

you will get the error

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
external/io_bazel_rules_go/go/tools/builders/nogo_main.go:237:11: not enough arguments in call to pkg.facts.Encode
        have ()
        want (bool)
external/io_bazel_rules_go/go/tools/builders/nogo_main.go:399:54: not enough arguments in call to facts.NewDecoder(pkg.types).Decode
        have (func(pkg *types.Package) ([]byte, error))
        want (bool, func(pkgPath string) ([]byte, error))

What operating system and processor architecture are you using?

Any other potentially useful information about your toolchain?

What did you do?

What did you expect to see?

What did you see instead?

@fmeum
Copy link
Collaborator

fmeum commented Aug 4, 2023

@sluongng Do you happen to have a recommendation here? Should we just update the version used by rules_go and force users to update with us?

@sluongng
Copy link
Contributor

sluongng commented Aug 4, 2023

I think we also ran into a separate issue with x/[email protected] over on Gazelle side bazelbuild/bazel-gazelle#1579. It seems like the upstream library is introducing quite a few breaking changes in this release (cc: @adonovan)

Should we just update the version used by rules_go and force users to update with us?

Yeah, there is no way we could accommodate a matrix of 3rd party deps version ranges.
At most, we could provide a release note suggesting how to patch rules_go if you want to keep on using older versions of x/tools.

I think we need to bump x/tools version in both rules_go and gazelle to the latest and do new releases.

fmeum pushed a commit to bazelbuild/bazel-gazelle that referenced this issue Sep 6, 2023
This PR prepares a new minor release 0.33.0 which includes no large breaking changes, yet some enhancements to Bzlmod ecosystem, including a new archive_override tag for the go_deps extension.

This PR does not include an update to the x/tools dependency because it is not included in the go.mod file, and there is a known bug: bazelbuild/rules_go#3640

This PR also adds a missing license header to files in the repository.
jeromep-stripe pushed a commit to jeromep-stripe/bazel-gazelle that referenced this issue Mar 22, 2024
This PR prepares a new minor release 0.33.0 which includes no large breaking changes, yet some enhancements to Bzlmod ecosystem, including a new archive_override tag for the go_deps extension.

This PR does not include an update to the x/tools dependency because it is not included in the go.mod file, and there is a known bug: bazelbuild/rules_go#3640

This PR also adds a missing license header to files in the repository.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants