"could not import syscall/js" error message even though it builds and runs successfully

package main

import (
	"syscall/js"
)

func main() {
	js.Global().Call("alert", "Hello World")
}

When built with GOOS=js GOARCH=wasm go build main.go using Go 1.11 this produces a WASM binary without error. However VSCode shows that there's an error:

could not import syscall/js (can't find import: "syscall/js")

I think this has to do with that namespace being experimental while wasm support stabilizes over the coming versions. I'm given very little details about the error.

As a result of the namespace not being found, intellisense also doesn't work.

I'm running VSCode 1.26.1 on Linux Mint 19 x64 with Go 1.11

I reopened the project to investigate further and when I moused over the import with it's red squiggly line, I got this error:

build constraints exclude all Go files in /usr/local/go/src/syscall/js

I think the plugin doesn't use an altered GOOS and GOARCH when checking the code for errors.

I tried setting go.toolsEnvVars in the project settings but I'm still getting the could not import error on the import.

In Output I see:

/home/corey/src/goprojects/src/wasm-hw>Finished running tool: /home/corey/src/goprojects/bin/golint

/home/corey/src/goprojects/src/wasm-hw>Finished running tool: /usr/local/go/bin/go build -i -o /tmp/go-code-check.198072839 wasm-hw
go build runtime/internal/atomic: mkdir /usr/local/go/pkg/js_wasm: permission denied
go build runtime/internal/sys: open /usr/local/go/pkg/js_wasm/runtime/internal/sys.a: no such file or directory
go build internal/race: mkdir /usr/local/go/pkg/js_wasm: permission denied
go build sync/atomic: mkdir /usr/local/go/pkg/js_wasm: permission denied
go build internal/cpu: open /usr/local/go/pkg/js_wasm/internal/cpu.a: no such file or directory

/home/corey/src/goprojects/src/wasm-hw>Finished running tool: /usr/local/go/bin/go vet ./...

I've set my go.toolsEnvVars as follows:

{
  "go.toolsEnvVars": {
    "GOOS": "js",
    "GOARCH": "wasm",
    "GOROOT": "/usr/local/go",
    "GOPATH": "/home/corey/src/goprojects"
  }
}

GoRoot and GoPath reflect what the normal env variables are. I'm still getting the could not import error. I'm not sure why it's trying to do things in my /usr/local/go folder or how to tell it to build those files in $GOPATH/pkg.

Adding write privileges to the $GOROOT/pkg folder not only feels like a bad move, but it also doesn't entirely fix the problem. The error goes away but there's no intellisense for anything under js.

Experiencing the same issue.

settings: vscode setting adding goos=js

Can you try adding the setting "go.installDependenciesWhenBuilding": false. See #1464 for another case where the build process had permission issues

Ramya Rao (@ramya-rao-a)

Ramya Rao (@ramya-rao-a) Thanks, I followed your steps and the error is not coming out. However, there is still no IntelliSense for syscall/js package.

If there are any running process for gocode, close them
Run gocode -s -debug in a terminal and try for intellisense in VS Code. Results from gocode will show up in the terminal.

If the results from gocode show zero candidates, then the issue is with gocode

It indeed said zero candidates. I guess that's an upstream issue then.

Are you using modules?
Also, can you try again by setting GOOS=js GOARCH=wasm in your terminal before running gocode -s -debug. Remember to kill existing processes for gocode

And why is the GOPATH being set to /home/corey/src/goprojects? Shouldnt it be just /home/corey ?

It should be /home/corey/src/goprojects. /home/corey/src also has other non-Go project folders that I don't want mixed in with go projects.

I'll try setting env variables like you suggest when I get a chance.

What do you get when you run Go: Current GOPATH ?
Are you using the new modules feature in Go 1.11?

I tried setting env before starting gocode but it is still not spawning candidates :(

This issue has been closed automatically because it needs more information and has not had recent activity. Thank you for your contributions.

I think this issue should be reopened. I dug a little through the vscode-go code and found this line which masked all GOARCH and GOOS env.

https://github.com/Microsoft/vscode-go/blob/d1a9f9a8cd7428c552517d72af148b7b116b9ed0/src/goSuggest.ts#L185
After I got rid of this in a dev environment, the suggestions worked perfectly.

I am not sure how to reproduce the issue mentioned on the code comments before this line. However I think we should definitely at least add an exception for wasm/js

饺子w (Yumechi) (@eternal-flame-AD)

That's a great find 饺子w (Yumechi) (@eternal-flame-AD)!

The commit behind that change is f73f41d which was made as part of the PR #156 to fix the issue #140

Rebecca Stambler (@stamblerre) Any idea if the comment in the above commit still holds true?

饺子w (Yumechi) (@eternal-flame-AD) Can you try cross-compiling with say linux and see if your fix still works?

Ramya Rao (@ramya-rao-a)

Ramya Rao (@ramya-rao-a): gocode tracks the build.Context of requests, so if you explicitly set GOOS and GOARCH in a client request, it should work correctly.

Rebecca Stambler (@stamblerre)

Thanks Rebecca Stambler (@stamblerre)!

饺子w (Yumechi) (@eternal-flame-AD) Would you be interested in submitting a PR to fix this?

Yep.

I found that when GOOS and GOARCH are set, gocode barely tracks import correctly:( I have to run like sudo env GOOS=js GOARCH=wasm go install math/rand in order to get math/rand suggestions working on wasm/js

I found a solution to the problem that is enabling source import when spawning gocode daemon. Should we include this change in the PR?

diff --git a/src/goSuggest.ts b/src/goSuggest.ts
index a5d9e66..40a63d1 100644
--- a/src/goSuggest.ts
+++ b/src/goSuggest.ts
@@ -187,14 +187,11 @@ export class GoCompletionItemProvider implements vscode.CompletionItemProvider {
 				return reject();
 			}
 
-			// Unset GOOS and GOARCH for the `gocode` process to ensure that GOHOSTOS and GOHOSTARCH
-			// are used as the target operating system and architecture. `gocode` is unable to provide
-			// autocompletion when the Go environment is configured for cross compilation.
-			let env = Object.assign({}, getToolsEnvVars(), { GOOS: '', GOARCH: '' });
+			let env = Object.assign({}, getToolsEnvVars());
 			let stdout = '';
 			let stderr = '';
 
-			let goCodeFlags = ['-f=json'];
+			let goCodeFlags = ['-f=json','-source=true'];
 			if (!this.setGocodeOptions) {
 				goCodeFlags.push('-builtin');
 			}

Including the -source flag slows things down a lot.

Are you saying that if you add the source flag, you dont have to run go install on the packages for which you want completions?

Yeah. Or maybe only enabling this when cross compiling?

I think we could move this discussion to #2015 as the corrent topic is more related to detailed implementation of the fix.

饺子w (Yumechi) (@eternal-flame-AD)

The fix for this issue is now out in the latest update to the Go extension (0.6.92). Thanks 饺子w (Yumechi) (@eternal-flame-AD) and Rebecca Stambler (@stamblerre)!

Note: Part of the fix here is in gocode. Therefore, run the command Go: Install/Update Tools, select gocode and press Ok to update it

Navigation Menu

Repository navigation

"could not import syscall/js" error message even though it builds and runs successfully #1874

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"could not import syscall/js" error message even though it builds and runs successfully #1874

Description

Activity

coreyog commented on Aug 26, 2018

coreyog commented on Aug 26, 2018

eternal-flame-AD commented on Sep 4, 2018

ramya-rao-a commented on Sep 10, 2018

eternal-flame-AD commented on Sep 10, 2018

ramya-rao-a commented on Sep 11, 2018

eternal-flame-AD commented on Sep 11, 2018

ramya-rao-a commented on Sep 12, 2018

coreyog commented on Sep 12, 2018

ramya-rao-a commented on Sep 12, 2018

eternal-flame-AD commented on Sep 12, 2018

12 remaining items

vscodebot commented on Sep 20, 2018

eternal-flame-AD commented on Oct 14, 2018

eternal-flame-AD commented on Oct 14, 2018

ramya-rao-a commented on Oct 15, 2018

stamblerre commented on Oct 15, 2018

ramya-rao-a commented on Oct 15, 2018

eternal-flame-AD commented on Oct 16, 2018

ramya-rao-a commented on Oct 16, 2018

eternal-flame-AD commented on Oct 16, 2018

eternal-flame-AD commented on Oct 16, 2018

ramya-rao-a commented on Oct 17, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions