go-plus
go-plus copied to clipboard
Windows with GOOS=linux fails to report bad syntax
I'm not sure where to continue my debugging. Sorry if I'm in the wrong place/package/etc.
I'm used to running Atom in Linux, but ever since I got a 4k laptop, my usual QubesOS install requires a magnifying glass because apparently I can't change the resolution nor the DPI scaling for whatever reason. So until that's resolved, I've resorted to using Windows 10 for a while, sadly. And so I need to be able to write cross-platform code in my (temporary) Windows dev environment.
I'm used to just calling GOOS=linux atom
or GOOS=windows atom
when in Linux and as best as I can remember it worked well. But when running in my current Windows 10 environment, when I call set GOOS=windows; atom.exe
everything seems to work but set GOOS=linux; atom.exe
doesn't. The failure seems to be somewhere in the works where it decides whether or not code has valid syntax. I figure that'd be go build
or go test
or go fmt
. When I save when using GOOS=linux
, it just always returns "no issues" even when there are obviously issues. I've supplied screenshots below to show the issue, which includes obviously bad code intended to trigger the error.
The reason I need to run GOOS=..
. is because I want to ensure that the auto-complete and syntax checking are applicable to the target OS I'm writing for. Usually I'm writing code for Linux, but sometimes I target Windows too. And if I'm using a method that doesn't exist in my target OS, I'd sure like to know about it, and I'd also like to know about the methods that are available in my target, such as syscall.NewLazyDLL
in Windows but not in Linux.
As a test, I've installed Quantum Shell (a package for Atom) that allows me to run commands in the Windows shell while in Atom. When I type set
it clearly shows the GOOS
value that I expect to see. When I run any usual commands, such as go build
, it gives me the success or failure that I would have expected to see. And because that's using the same environment variables that Atom is (supposedly) using, it seems that there's a bug somewhere, not just a bad environment variable on my part.
I'm running the following versions. According to Atom, all packages are up-to-date.
Atom 1.7.1 go-plus 4.1.0 autocomplete-go 1.0.6 builder-go 1.0.0 go-config 1.1.4 go-get 1.0.3 gofmt 1.1.6 gometalinter-linter 1.1.0 gorename 1.0.2 linter 1.11.4 navigator-godef 1.0.2 quantum-shell 0.7.1 tester-go 1.0.4
I am running no other community packages whatsoever.
Screenshots related to this issue:
When in Windows launching Atom with GOOS=linux
:
(it should NOT show "no issues")
Same as above, but launching in Windows with GOOS=windows
:
When in Windows launching Atom with GOOS=linux
(it doesn't appear when running GOOS=windows
):
After clicking the "Go Get" in the above alert:
I have a feeling that #343 is related in some way.
Your hunch is probably correct. We're using a regular expression to parse the output. Can you post the actual output from go install .
in the directory of the affected file?
$>go install .
!!# test/test1
!!.\test1.go:4: undefined: this_is_obviously_wrong
This is when GOOS=linux
:
Showing the ENV variables:
Same effect when running with GOOS=windows
but it actually shows the error in Atom:
Here is my script to run Atom with GOOS=windows
:
@echo off
path %PATH%;%PROGRAMFILES%\SCJ\PortableGit\bin
md %USERPROFILE%\go-personal
md %USERPROFILE%\go-personal\src
set GOPATH=%USERPROFILE%\go-personal
set GOOS=windows
"%LOCALAPPDATA%\atom\bin\atom.cmd" -n %USERPROFILE%\go-personal\src
Here is my script to run Atom with GOOS=linux
:
@echo off
path %PATH%;%PROGRAMFILES%\SCJ\PortableGit\bin
md %USERPROFILE%\go-personal
md %USERPROFILE%\go-personal\src
set GOPATH=%USERPROFILE%\go-personal
set GOOS=linux
"%LOCALAPPDATA%\atom\bin\atom.cmd" -n %USERPROFILE%\go-personal\src