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
x/tools/imports: does not know about "syscall/js" #27590
Labels
arch-wasm
WebAssembly issues
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
dmitshur
added
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
arch-wasm
WebAssembly issues
labels
Sep 10, 2018
Change https://golang.org/cl/134176 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Sep 10, 2018
Go 1.11 has been released; it's time to update zstdlib so imports knows about API additions that went into Go 1.11. Unfortunately, this does not include the syscall/js package that was added in Go 1.11 for WebAssembly. This is because it's not included in the GOROOT/api/go1.11.txt file. Getting it into imports can/will be done in a future CL (after some discussion of the best way to do it). Previously: - https://golang.org/cl/93195 (Go 1.10) - https://golang.org/cl/49150 (Go 1.9) Updates golang/go#27590. Change-Id: I229d7c0a658b0d8090b58cfe844c95b4cb0b2212 Reviewed-on: https://go-review.googlesource.com/134176 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
I tried to add it to API/go1.11.txt but it was after the freeze and it ended up nontrivial so I didn't rush it. For now I'd hard code the entries in goimports. |
dmitshur
added
NeedsFix
The path to resolution is known, but the work has not been done.
and removed
NeedsDecision
Feedback is required from experts, contributors, and/or the community before a change can be made.
labels
Sep 10, 2018
Change https://golang.org/cl/170014 mentions this issue: |
dmitshur
added a commit
to gopherjs/gopherjs.github.io
that referenced
this issue
Dec 1, 2019
GopherJS 1.12-2 has added support for syscall/js package, so it should be available as part of imports. The syscall/js API is not included in the GOROOT/api/go1.*.txt files at this time, and so it needs to be added to mkstdlib.go explicitly. Use the mkapi.go program to determine the syscall/js API. Regenerate zstdlib.go with the updated generator, using Go 1.12.13: go1.12.13 generate github.com/gopherjs/gopherjs.github.io/playground/internal/imports Updates golang/go#27590
dmitshur
added a commit
to gopherjs/gopherjs.github.io
that referenced
this issue
Dec 2, 2019
GopherJS 1.12-2 has added support for syscall/js package, so it should be available as part of imports. The syscall/js API is not included in the GOROOT/api/go1.*.txt files at this time, and so it needs to be added to mkstdlib.go explicitly. Use the mkapi.go program to determine the syscall/js API. Regenerate zstdlib.go with the updated generator, using Go 1.12.13: go1.12.13 generate github.com/gopherjs/gopherjs.github.io/playground/internal/imports Updates golang/go#27590
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
arch-wasm
WebAssembly issues
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
I've recently sent CL 134176 to update zstdlib.go (the generated file that contains information about the Go standard library) to include the new Go 1.11 API additions.
However,
syscall/js
package wasn't added to the GOROOT/api/go1.11.txt file that is used to generate zstdlib.go, so that's not enough to getsyscall/js
support intogoimports
.Does anyone know if excluding
syscall/js
package from api/go1.11.txt was an intentional decision (becausesyscall/js
is considered experimental and exempt from the Go compatibility promise), or an unintentional outcome?If the latter, we should resolve this issue by first updating api/go1.11.txt, then regenerating
imports
.If the former, then we need to make a decision of whether
x/tools/imports
should know aboutsyscall/js
anyway. If so, we can do some custom work here to get it in. I've done similar stuff for a copy ofimports
used by the GopherJS Playground, so I'm happy to do it./cc @neelance @bradfitz @josharian @andybons
The text was updated successfully, but these errors were encountered: