Open emmaly opened 8 years ago
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
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
orGOOS=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 callset GOOS=windows; atom.exe
everything seems to work butset 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 bego build
orgo test
orgo fmt
. When I save when usingGOOS=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 assyscall.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 theGOOS
value that I expect to see. When I run any usual commands, such asgo 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 runningGOOS=windows
):After clicking the "Go Get" in the above alert: