cmd/cue: nil pointer reference panic when using "get go" #2046
Comments
|
I've probably done something I don't fully understand. but maybe this is also useful: |
LeonardAukea
changed the title
cue get gocue get go istio.io/api/networking/v1alpha3
|
I stumbled upon the same problem this morning. I found that all the other APIs from Istio are ok, only the networking one is giving the stack trace, on both API versions. Those are all ok: Those are giving the same stack trace as mentioned previously: |
mvdan
changed the title
cue get go istio.io/api/networking/v1alpha3 
|
I am seeing the same issue when importing stdlib packages. Digging in to it, it was failing because "io/fs" was not in the |
|
I'm able to reproduce what I think is the same problem using CUE version 0.5.0. Run these commands:
That yields the following failure. "cue get go" outputThat command does produce a bunch of CUE files, but fails before it can produce all of them. Unfortunately, it also produces files under the cue.mod/gen/{context,internal,io,net,syscall} directories too, recalling #1453. |
For this case, here's a workaround that I had forgotten about: cue get go github.com/open-policy-agent/gatekeeper/apis/mutations/v1 --exclude='Matchable$' That eliminates the dependency on controller-runtime's |
mvdan
added
get go
|
Super hackish but I was workaround this by manually generating the Istio schema from the protobuf at https://github.com/istio/api. I took advantage of the fact that Istio already uses cue to generate their CRDs and OpenAPI docs from the protobufs and added a statement to https://github.com/istio/tools/tree/master/cmd/cue-gen to print the cue definitions once they have been loaded into the script. This is not a robust solution but got me the schema output I was looking for. |
|
It looks like there may be a few conflated issues here. It seems the panic for The panic for |
Most Go APIs like go/types.Package.Path and go/packages.Package.PkgPath use full canonical package paths, whereas go/packages.Package.Imports uses source import paths as they appear in the import declarations. We mixed the two, using paths from go/types to index into Imports, resulting in nil packages in the edge cases when they are different. One such instance is vendored packages, whose full path may be "vendor/foo/bar" when they are simply imported as "foo/bar". This also fixes a similar panic with some type aliases, in particular when an alias points to an indirectly imported package, as such a package would be missing from the Imports map. The two added testscripts reproduced both panics without the fix, and now work as expected with the fix. Fixes #1607. Fixes #2046. Change-Id: I51df3465da76b39f031855982b48552604817f80 Signed-off-by: Thomas Way <thomas@6f.io>
Most Go APIs like go/types.Package.Path and go/packages.Package.PkgPath use full canonical package paths, whereas go/packages.Package.Imports uses source import paths as they appear in the import declarations. We mixed the two, using paths from go/types to index into Imports, resulting in nil packages in the edge cases when they are different. One such instance is vendored packages, whose full path may be "vendor/foo/bar" when they are simply imported as "foo/bar". This also fixes a similar panic with some type aliases, in particular when an alias points to an indirectly imported package, as such a package would be missing from the Imports map. The two added testscripts reproduced both panics without the fix, and now work as expected with the fix. Fixes #1607. Fixes #2046. Change-Id: I51df3465da76b39f031855982b48552604817f80 Signed-off-by: Thomas Way <thomas@6f.io> Co-authored-by: Daniel Martí <mvdan@mvdan.cc> Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Most Go APIs like go/types.Package.Path and go/packages.Package.PkgPath use full canonical package paths, whereas go/packages.Package.Imports uses source import paths as they appear in the import declarations. We mixed the two, using paths from go/types to index into Imports, resulting in nil packages in the edge cases when they are different. One such instance is vendored packages, whose full path may be "vendor/foo/bar" when they are simply imported as "foo/bar". This also fixes a similar panic with some type aliases, in particular when an alias points to an indirectly imported package, as such a package would be missing from the Imports map. The two added testscripts reproduced both panics without the fix, and now work as expected with the fix. Fixes #1607. Fixes #2046. Change-Id: I51df3465da76b39f031855982b48552604817f80 Signed-off-by: Thomas Way <thomas@6f.io> Co-authored-by: Daniel Martí <mvdan@mvdan.cc> Signed-off-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1173100 Reviewed-by: Paul Jolly <paul@myitcv.io> Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com> TryBot-Result: CUEcueckoo <cueckoo@gmail.com> (cherry picked from commit b648cf4)
Most Go APIs like go/types.Package.Path and go/packages.Package.PkgPath use full canonical package paths, whereas go/packages.Package.Imports uses source import paths as they appear in the import declarations. We mixed the two, using paths from go/types to index into Imports, resulting in nil packages in the edge cases when they are different. One such instance is vendored packages, whose full path may be "vendor/foo/bar" when they are simply imported as "foo/bar". This also fixes a similar panic with some type aliases, in particular when an alias points to an indirectly imported package, as such a package would be missing from the Imports map. The two added testscripts reproduced both panics without the fix, and now work as expected with the fix. Fixes #1607. Fixes #2046. Change-Id: I51df3465da76b39f031855982b48552604817f80 Signed-off-by: Thomas Way <thomas@6f.io> Co-authored-by: Daniel Martí <mvdan@mvdan.cc> Signed-off-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1173100 Reviewed-by: Paul Jolly <paul@myitcv.io> Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com> TryBot-Result: CUEcueckoo <cueckoo@gmail.com> (cherry picked from commit b648cf4) Reviewed-on: https://review.gerrithub.io/c/cue-lang/cue/+/1190977 TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>
What version of CUE are you using (
cue version)?$ cue version cue version v0.5.0-alpha.1 -compiler gc -ldflags -s -w CGO_ENABLED 0 GOARCH amd64 GOOS darwin GOAMD64 v1Does this issue reproduce with the latest release?
What did you do?
I ran the following commands:
go get istio.io/api/networking/v1alpha3 go: downloading istio.io/api v0.0.0-20221025180617-53adcb30720d go: downloading google.golang.org/protobuf v1.28.1 go: downloading google.golang.org/genproto v0.0.0-20221018160656-63c7b68cfc55 go: upgraded google.golang.org/genproto v0.0.0-20220624142145-8cd45d7dbd1f => v0.0.0-20221018160656-63c7b68cfc55 go: added istio.io/api v0.0.0-20221025180617-53adcb30720d cue get go istio.io/api/networking/v1alpha3Which returned:
What did you expect to see?
Some confirmation from the cli that the
cue get goloaded the definitions successfully, or at least not return an error.What did you see instead?
They seem to have been loaded in
cue.modeither way.cue.mod/gen/istio.io/api/networking └── v1alpha3 ├── destination_rule.pb_go_gen.cue ├── destination_rule_deepcopy.gen_go_gen.cue ├── destination_rule_json.gen_go_gen.cue ├── envoy_filter.pb_go_gen.cue ├── envoy_filter_deepcopy.gen_go_gen.cue ├── envoy_filter_json.gen_go_gen.cue ├── gateway.pb_go_gen.cue ├── gateway_deepcopy.gen_go_gen.cue ├── gateway_json.gen_go_gen.cue ├── service_entry.pb_go_gen.cue ├── service_entry_deepcopy.gen_go_gen.cue ├── service_entry_json.gen_go_gen.cue ├── sidecar.pb_go_gen.cue ├── sidecar_deepcopy.gen_go_gen.cue ├── sidecar_json.gen_go_gen.cue ├── virtual_service.pb_go_gen.cue ├── virtual_service_deepcopy.gen_go_gen.cue ├── virtual_service_json.gen_go_gen.cue ├── workload_entry.pb_go_gen.cue ├── workload_entry_deepcopy.gen_go_gen.cue ├── workload_entry_json.gen_go_gen.cue ├── workload_group.pb_go_gen.cue ├── workload_group_deepcopy.gen_go_gen.cue └── workload_group_json.gen_go_gen.cueThe text was updated successfully, but these errors were encountered: