profile
viewpoint
Michael Matloob matloob Google New York

google/skylark 1145

Skylark in Go: the Skylark configuration language, implemented in Go [MOVED to go.starlark.net]

matloob/contributing 37

CONTRIBUTING: The Talk

matloob/regexp 26

go regexp with RE2 DFA matcher port - golang.org/cl/12081

matloob/check 0

A set of utilities for checking Go sources

matloob/DefinitelyTyped 0

The repository for high quality TypeScript type definitions.

matloob/go-tools 0

Staticcheck – a collection of static analysis tools for working with Go code

matloob/screen 0

screen printing stuff

matloob/silly 0

silly silly silly

matloob/tinygo 0

Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

issue commentgolang/go

x/tools/go/ssa/interp: tests broken at Go CL 191198

Removing Soon because ssa/interp is not heavily used, and the test is no longer a time bomb.

bcmills

comment created time in 7 hours

issue commentgolang/go

x/tools/go/ssa: method calls sometimes have different count of arguments because of closure

I'm leaning against making this change, especially because I don't want to break anyone, but I'll let @finleyr be the final decider.

Matts966

comment created time in a day

issue commentgolang/go

cmd/go: TestExecutableGOROOT occasionally fails with "text file busy"

I've decided to go for the most extreme solution: to just convert the test to the script framework.

josharian

comment created time in 5 days

issue commentgolang/go

cmd/go: TestExecutableGOROOT occasionally fails with "text file busy"

alright, another CL on its way!

josharian

comment created time in 5 days

issue commentgolang/go

cmd/go: TestExecutableGOROOT occasionally fails with "text file busy"

Okay, let's see if it helps. Sent a CL to add the Sync in.

josharian

comment created time in 5 days

issue commentgolang/go

cmd/go: TestExecutableGOROOT is flaky

Yup, that gives me more confidence that it was the right call to convert tests to the script framework rather than put in t.Parallel. I'll remove this particular t.Parallel at if I can't figure out what's going on by EOD.

josharian

comment created time in 5 days

issue commentgolang/go

cmd/go: TestExecutableGOROOT is flaky

Hm, the only change we made to this test is adding the t.Parallel() call. I'll see if I can figure out what the problem is.

josharian

comment created time in 5 days

issue commentgolang/go

proposal: cmd/go: add GOMODCACHE

Okay, @bcmills and @jayconrod, what do y'all think?

mvdan

comment created time in 7 days

issue commentgolang/go

x/tools/go/analysis/passes/nilness: add -sound option

Okay, I'm curious what the data type of the fact would be.

Matts966

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: add GOMODCACHE

Based on @jayconrod and @bcmills's comments on the codereview, (and offline discussions I had with them) it looks like there are two unresolved issues we need to figure out before we can move forward. I'll let them correct me if I have a misunderstanding:

First, this proposal is to create a GOMODCACHE set to $GOPATH/pkg/mod by default. This leaves open the question of w here the sumdb directory goes. Currently, it lives in $GOPATH/pkg/sumdb. I think we wouldn't want to put the sumdb directory in $GOMODCACHE/../sumdb: it would be surprising behavior to create a new directory side-by-side with the user supplied directory name. Two alternatives would be (a) to start putting the sumdb in $GOMODCACHE/sumdb, and migrate over the old sumdb at $GOPATH/pkg/mod to the new location. The alternative is to set GOMODCACHE to $GOPATH/pkg by default, and put put the module cache in $GOMODCACHE/mod and the sumdb in $GOMODCACHE/sumdb. My preference is for the first option because the second option is a bit clunky.

The second issue isn't directly addressed in this proposal, but in our discussion, it seemed worth bringing up. Do we want to specify a relationship between the GOMODCACHE variable, and what we could set GOPROXY to be to proxy from the module cache? According to the proposal we have, it would be GOPROXY=file://$GOMODCACHE/cache/download.

mvdan

comment created time in 7 days

issue commentgolang/go

x/tools/analysis/singlechecker: method calls sometimes have different count of arguments because of closure

cc @findleyr

If I understand this comment, the problem is that the arguments first function call, x.method() include the receiver argument, while the arguments for m() don't. This looks consistent to me: the first function has a reciever, while the second is niladic. It seems like this behavior is intended.

Matts966

comment created time in 7 days

issue commentgolang/go

x/tools/go/packages: Load function throws "argument list too long" error

I think the solution to this is to have go/packages split the arguments to go list (or to the underlying GOPACKAGESDRIVER if it's set) and make multiple calls to the driver. those results should be able to just be merged (removing duplicates if, for example, -deps is set as a go list argument). The pcakage structures returned by the driver are independent, and the driver should return consistent ids over several calls. Then those can be supplied to the "refining" stage where we parse/typecheck the packages.

awelc

comment created time in 12 days

issue commentgolang/go

x/tools/go/analysis/passes/nilness: add -sound option

I don't quite understand the algorithm: my main question is what does the fact you want to export signify?

I think we can answer that question, and then make an experimental fact that you can try using in the alternate version of the analysis. I'm not sure that I'd be the best person to review the actual analysis code, though.

Matts966

comment created time in 12 days

issue commentgolang/go

x/tools/go/packages, go/ast: NewPackage causes SIGSEGV

When that's happened (NeedY requires NeedX), it's been a bug, and we've fixed it. The principle of the Need fields are that if a need field says it's going to populate a field, that field should be populated (which sounds obvious, but we've had a number of bugs where that didn't happen, and I think that's what you were running into @josharian). I think the difference here is that the documentation is correct, but inconvenient.

perillo

comment created time in 12 days

issue closedgolang/go

x/tools/go/packages, go/ast: NewPackage causes SIGSEGV

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.14rc1 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="on" GOARCH="amd64" GOBIN="/home/manlio/.local/bin" GOCACHE="/home/manlio/.cache/go-build" GOENV="/home/manlio/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/manlio/.local/lib/go:/home/manlio/src/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/manlio/sdk/go1.14rc1" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/manlio/sdk/go1.14rc1/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build928658787=/tmp/go-build -gno-record-gcc-switches" GOROOT/bin/go version: go version go1.14rc1 linux/amd64 GOROOT/bin/go tool compile -V: compile version go1.14rc1 uname -sr: Linux 5.5.2-arch1-1 /usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.31. gdb --version: GNU gdb (GDB) 8.3.1 </pre></details>

What did you do?

With main.go from https://play.golang.org/p/d0Nm2xOm74F, and in a directory with a go.mod file:

go run main.go

What did you expect to see?

The program to exit normally.

What did you see instead?

The following stacktrace:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x4d789b]

goroutine 1 [running]:
panic(0x648e20, 0x867330)
	/home/manlio/sdk/go1.14rc1/src/runtime/panic.go:1060 +0x420 fp=0xc00017d950 sp=0xc00017d8a8 pc=0x431df0
runtime.panicmem(...)
	/home/manlio/sdk/go1.14rc1/src/runtime/panic.go:212
runtime.sigpanic()
	/home/manlio/sdk/go1.14rc1/src/runtime/signal_unix.go:687 +0x3da fp=0xc00017d980 sp=0xc00017d950 pc=0x44792a
go/token.(*FileSet).file(0x0, 0x5e, 0xc000156400)
	/home/manlio/sdk/go1.14rc1/src/go/token/position.go:452 +0x2b fp=0xc00017d9c8 sp=0xc00017d980 pc=0x4d789b
go/token.(*FileSet).PositionFor(0x0, 0x5e, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
	/home/manlio/sdk/go1.14rc1/src/go/token/position.go:492 +0x61 fp=0xc00017da18 sp=0xc00017d9c8 pc=0x4d7b21
go/token.(*FileSet).Position(...)
	/home/manlio/sdk/go1.14rc1/src/go/token/position.go:503
go/ast.(*pkgBuilder).error(0xc00017dc48, 0x5e, 0xc000156400, 0x14)
	/home/manlio/sdk/go1.14rc1/src/go/ast/resolve.go:22 +0x6e fp=0xc00017dac0 sp=0xc00017da18 pc=0x4edaee
go/ast.(*pkgBuilder).errorf(0xc00017dc48, 0x5e, 0x68f5af, 0x13, 0xc00017dc38, 0x1, 0x1)
	/home/manlio/sdk/go1.14rc1/src/go/ast/resolve.go:26 +0x7f fp=0xc00017db08 sp=0xc00017dac0 pc=0x4edd1f
go/ast.NewPackage(0x0, 0xc00010d3b0, 0x0, 0x0, 0xc000208228, 0x1, 0x1)
	/home/manlio/sdk/go1.14rc1/src/go/ast/resolve.go:162 +0xa51 fp=0xc00017de58 sp=0xc00017db08 pc=0x4eec41
main.main()
	/home/manlio/src/go/src/bugs/ast-newpackage/main.go:37 +0x2d2 fp=0xc00017df88 sp=0xc00017de58 pc=0x612982
runtime.main()
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:203 +0x212 fp=0xc00017dfe0 sp=0xc00017df88 pc=0x434822
runtime.goexit()
	/home/manlio/sdk/go1.14rc1/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc00017dfe8 sp=0xc00017dfe0 pc=0x460c51

goroutine 2 [force gc (idle)]:
runtime.gopark(0x69aeb8, 0x8705b0, 0x1411, 0x1)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:304 +0xe0 fp=0xc000030fb0 sp=0xc000030f90 pc=0x434c00
runtime.goparkunlock(...)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:310
runtime.forcegchelper()
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:253 +0xb7 fp=0xc000030fe0 sp=0xc000030fb0 pc=0x434ab7
runtime.goexit()
	/home/manlio/sdk/go1.14rc1/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc000030fe8 sp=0xc000030fe0 pc=0x460c51
created by runtime.init.6
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:242 +0x35

goroutine 3 [GC sweep wait]:
runtime.gopark(0x69aeb8, 0x870740, 0x140c, 0x1)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:304 +0xe0 fp=0xc0000317a8 sp=0xc000031788 pc=0x434c00
runtime.goparkunlock(...)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:310
runtime.bgsweep(0xc00004c000)
	/home/manlio/sdk/go1.14rc1/src/runtime/mgcsweep.go:70 +0x9c fp=0xc0000317d8 sp=0xc0000317a8 pc=0x421d1c
runtime.goexit()
	/home/manlio/sdk/go1.14rc1/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc0000317e0 sp=0xc0000317d8 pc=0x460c51
created by runtime.gcenable
	/home/manlio/sdk/go1.14rc1/src/runtime/mgc.go:214 +0x5c

goroutine 4 [GC scavenge wait]:
runtime.gopark(0x69aeb8, 0x870700, 0x140d, 0x1)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:304 +0xe0 fp=0xc000031f78 sp=0xc000031f58 pc=0x434c00
runtime.goparkunlock(...)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:310
runtime.bgscavenge(0xc00004c000)
	/home/manlio/sdk/go1.14rc1/src/runtime/mgcscavenge.go:237 +0xd0 fp=0xc000031fd8 sp=0xc000031f78 pc=0x420320
runtime.goexit()
	/home/manlio/sdk/go1.14rc1/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc000031fe0 sp=0xc000031fd8 pc=0x460c51
created by runtime.gcenable
	/home/manlio/sdk/go1.14rc1/src/runtime/mgc.go:215 +0x7e

goroutine 17 [finalizer wait]:
runtime.gopark(0x69aeb8, 0x89aad8, 0x1410, 0x1)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:304 +0xe0 fp=0xc00002c758 sp=0xc00002c738 pc=0x434c00
runtime.goparkunlock(...)
	/home/manlio/sdk/go1.14rc1/src/runtime/proc.go:310
runtime.runfinq()
	/home/manlio/sdk/go1.14rc1/src/runtime/mfinal.go:175 +0xa3 fp=0xc00002c7e0 sp=0xc00002c758 pc=0x4179d3
runtime.goexit()
	/home/manlio/sdk/go1.14rc1/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc00002c7e8 sp=0xc00002c7e0 pc=0x460c51
created by runtime.createfing
	/home/manlio/sdk/go1.14rc1/src/runtime/mfinal.go:156 +0x61
exit status 2

With go1.13.7 the stack trace of goroutine 1 is a bit different:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x4d53fb]

goroutine 1 [running]:
panic(0x6546e0, 0x871280)
	/usr/lib/go/src/runtime/panic.go:722 +0x2c2 fp=0xc000119928 sp=0xc000119898 pc=0x42cca2
runtime.panicmem(...)
	/usr/lib/go/src/runtime/panic.go:199
runtime.sigpanic()
	/usr/lib/go/src/runtime/signal_unix.go:394 +0x3ec fp=0xc000119958 sp=0xc000119928 pc=0x4413cc
sync.(*RWMutex).RLock(...)
	/usr/lib/go/src/sync/rwmutex.go:48
go/token.(*FileSet).file(0x0, 0x5e, 0xc0000fa3a0)
	/usr/lib/go/src/go/token/position.go:452 +0x2b fp=0xc0001199a0 sp=0xc000119958 pc=0x4d53fb
go/token.(*FileSet).PositionFor(0x0, 0x5e, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/lib/go/src/go/token/position.go:492 +0x61 fp=0xc0001199f0 sp=0xc0001199a0 pc=0x4d5681
go/token.(*FileSet).Position(...)
	/usr/lib/go/src/go/token/position.go:503
go/ast.(*pkgBuilder).error(0xc000119c20, 0x5e, 0xc0000fa3a0, 0x14)
	/usr/lib/go/src/go/ast/resolve.go:22 +0x6e fp=0xc000119a98 sp=0xc0001199f0 pc=0x4eb91e
go/ast.(*pkgBuilder).errorf(0xc000119c20, 0x5e, 0x69fe23, 0x13, 0xc000119c10, 0x1, 0x1)
	/usr/lib/go/src/go/ast/resolve.go:26 +0x7f fp=0xc000119ae0 sp=0xc000119a98 pc=0x4ebb4f
go/ast.NewPackage(0x0, 0xc0000e2a50, 0x0, 0x0, 0xc0001030c8, 0x1, 0x1)
	/usr/lib/go/src/go/ast/resolve.go:162 +0xa51 fp=0xc000119e30 sp=0xc000119ae0 pc=0x4eca71
main.main()
	/home/manlio/src/go/src/bugs/ast-newpackage/main.go:37 +0x2d2 fp=0xc000119f60 sp=0xc000119e30 pc=0x616172
runtime.main()
	/usr/lib/go/src/runtime/proc.go:203 +0x21e fp=0xc000119fe0 sp=0xc000119f60 pc=0x42e9ee
runtime.goexit()
	/usr/lib/go/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc000119fe8 sp=0xc000119fe0 pc=0x458b31

The error seems to be in

s.mutex.RLock()

closed time in 12 days

perillo

issue commentgolang/go

x/tools/go/packages, go/ast: NewPackage causes SIGSEGV

Okay, i think it's fair to want Fset set when NeedSyntax is, but I'd like to see more demand for it before I make an API change. I'll close this issue for now, if you want to open an issue about setting Fset when NeedSyntax is set, we can see if there are others who want it.

perillo

comment created time in 12 days

issue commentgolang/go

x/tools/go/analysis/passes/nilness: add -sound option

Hm, I don't know if adding Objects to BasicBlocks is the right idea: multiple objects could correspond to a basic block. I wonder if @findleyr has opinions about how facts about the SSA should be reported.

Another question: I wonder how this is going to be exposed: do you want to make the fact visible so that another Analysis, outside tools, would use it (preferred by me), or do you want to put the new Analysis in tools? We just drop most of the analyses in we have in go/analysis/passes as a default for gopls, but we wouldn't want to do that here, because we already have a very similar analysis.

Matts966

comment created time in 14 days

issue commentgolang/go

cmd/go: error not reported for packages in vendor/ in module mode, without vendoring

Hm, I'm on the "it may just be confusing" side: my intuition is either

*  "vendor" is meaningless outside of mod=vendor mode, acting like a normal package (which would be confusing be cause mod=vendor would result in a different build when it's on or off)

or better * the only directory that's allowed to be named vendor must be in the root directory of a module, and when mod=vendor is off, all the source contained in that directory is ignored, and an error is reported if code is contained directly in vendor/

jayconrod

comment created time in 14 days

issue commentgolang/go

x/tools/go/analysis/passes/nilness: add -sound option

cc @findleyr

Would the facts returned by nilness be unexported types? We'd also have to make it clear that the basic block references point back to the SSA returned by the SSA analysis.

Matts966

comment created time in 15 days

issue commentgolang/go

x/lint: golint does not recognize Unwrap methods

Lint is really noisy and my preference is to keep its behavior fixed. If you want to send a CL to add Unwrap to the list of known methods I'd be okay with it.

perillo

comment created time in 18 days

issue commentgolang/go

x/tools/go/packages: loader doesn't handle/recognize "context canceled" error

cc @stamblerre

This sounds reasonable to me, i'll let rstambler confirm if it's okay.

mmirolim

comment created time in 18 days

issue commentgolang/go

x/tools/packages: Swig causes generated C++ sources in CompiledGoFiles

This looks like a valid problem. I wonder why this is happening? The SwigCXXFiles should be put in other sources along with the rest of the non-go source files.

noahgoldman

comment created time in 18 days

issue commentgolang/go

x/tools/go/analysis/passes/nilness: add -sound option

I wonder if we should make that a separate analysis? (Maybe refactoring the nilness checking code to be parameterized so it can be used by nilness and the separate analysis). It's a lot easier to enable/disable analyses instead of passing flags.

Matts966

comment created time in 18 days

issue closedgolang/go

x/tools/go/packages: GoFiles should be sorted

The GoFiles field in packages is the concatenation of GoFiles and CgoFiles from go list. go list returns the two fields sorted (although it seems to not be documented), but packages does not sort its own GoFiles.

closed time in 20 days

perillo

issue commentgolang/go

x/tools/go/packages: GoFiles should be sorted

Okay, I'll close. Thanks!

perillo

comment created time in 20 days

issue commentgolang/go

cmd/go: default GOBIN to GOPATH[0]/bin when outside of GOPATH?

sounds good to me

sslavic

comment created time in 20 days

issue commentgolang/go

x/tools/go/analysis/analysistest: support modules

Hm, I think Option 1 would create some problems because running the test would modify the module is contained in, and that could be very surprising.

Option 2 would be more desirable depending on how it works.

muirdm

comment created time in 20 days

issue commentgolang/go

x/tools/go/packages: GoFiles should be sorted

I'd prefer not to specify the ordering of GoFiles. We want it to be deterministic but I think that otherwise, the more flexibility the api has, the better.

perillo

comment created time in 20 days

issue commentgolang/go

x/tools/go/analysis/analysistest: support modules

Just to understand this a bit better, do you mean that the test code in the test tree can depend on an external module and download it?

muirdm

comment created time in 20 days

issue commentgolang/go

x/tools/gopls: no references are found due to `go list -deps` error

Okay, I can't reproduce this locally. I'm wondering if the version of gopls@master you built also pinned tools at master? (It's not enough to get gopls@master because it pins tools to an old pseudoversion in its go.mod). What happens if you upgrade to gopls@latest (which includes the newest version of tools in its go.mod), and try the command then?

urandom

comment created time in 25 days

issue commentgolang/go

x/tools/gopls: no references are found due to `go list -deps` error

Thanks for the repro, I'll see what's going on.

The weird thing is that I'm getting the "#" in my stderr:

$ go list -json -compiled uandom.go >/dev/null
# pkg-config --cflags  -- vips vips vips vips
Package vips was not found in the pkg-config search path.
Perhaps you should add the directory containing `vips.pc'
to the PKG_CONFIG_PATH environment variable
No package 'vips' found
Package vips was not found in the pkg-config search path.
Perhaps you should add the directory containing `vips.pc'
to the PKG_CONFIG_PATH environment variable
No package 'vips' found
Package vips was not found in the pkg-config search path.
Perhaps you should add the directory containing `vips.pc'
to the PKG_CONFIG_PATH environment variable
No package 'vips' found
Package vips was not found in the pkg-config search path.
Perhaps you should add the directory containing `vips.pc'
to the PKG_CONFIG_PATH environment variable
No package 'vips' found
pkg-config: exit status 1
urandom

comment created time in 25 days

issue commentgolang/go

x/tools/gopls: no references are found due to `go list -deps` error

I'm a bit stumped as to why this is happening. It would be really helpful if there was a repo we could try to reproduce this with locally so we can try to debug this. Is that something you could give us?

urandom

comment created time in a month

issue commentgolang/go

x/tools/go/packages: TestOverlayDeps extremely flaky at head

I have no idea how the failure could be related to that CL.

bcmills

comment created time in a month

issue commentgolang/go

x/tools/go/packages: TestOverlayDeps extremely flaky at head

Looking at this now

bcmills

comment created time in a month

issue commentgolang/go

x/tools/go/analysis: migrate golint to use go/analysis

cc @hyangah, who I think has done some work on this.

I think golist should stay in a separate repository. We could put the passes in tools (though I'd prefer not to) but the binary itself should not be in tools.

stamblerre

comment created time in a month

issue commentgolang/go

x/tools/gopls: no references are found due to `go list -deps` error

In general, go list needs to be able to work for our tools to work. Does your project build with go build? Do you use a Makefile (or other build system) that sets the cgo environment variables? If so, you'd need to set the environment variables for gopls.

urandom

comment created time in a month

issue commentgolang/go

x/tools/go/packages: "conflicting information" error when importing internal or main package

Okay, I see. I neglected to see that the field on the 'real' version of the package was DepsErrors. But I'm still curious then if it's possible to bubble up the DepsErrors (since an error in the deps should mean an error in the package itself) and drop the version of the package with the error itself.

Is that what you're proposing for the right behavior of go/packages? That we find DepsErrors on broken packages and bubble them up? Also, by incomplete, do we mean that the type information is incomplete? Do we have that information if we haven't built the package?

jayconrod

comment created time in a month

issue closedgolang/go

x/tools/go/gopackage: add Dir field to the Package struct

Currently, the Package struct does not have a Dir field, but instead there is a Dir field in the Config struct, specifying the directory in which to run the build system's query tool.

With relative queries, like . or ./... it is possible to get a relative path to a .go source file. However with queries like fmt or golang.org/x/time/rate, the caller has no way to obtain relative file names.

This may be a problem for some tools, like my https://github.com/perillo/goprint. Showing something like golang.org/x/time/rate ... /home/manlio/.local/lib/go/pkg/mod/golang.org/x/time@v0.0.0-20191024005414-555d28b269f0/rate/rate.go instead of golang.org/x/time/rate ... rate.go on the page top header is a bit problematic.

closed time in a month

perillo

issue commentgolang/go

x/tools/go/gopackage: add Dir field to the Package struct

Okay, that's reasonable. I'll close this issue.

perillo

comment created time in a month

issue commentgolang/go

cmd/go: go list starts the Package.Error.Err field with a newline

Just for my curiousity, is this breaking something or is it purely an aesthetic concern?

perillo

comment created time in a month

issue commentgolang/go

cmd/go: panics listing ./... in GOROOT/src

I put together a change that emits an error

heschik

comment created time in a month

issue commentgolang/go

x/tools/go/gopackage: add Dir field to the Package struct

We don't plan to add a Dir field to the Package struct because not all build systems have a concept of a directory for the package.

So in a sense, the concept of a relative file name to a package doesn't exist in general, for all build systems.

But I'd like to understand your example better, by asking a question to help me understand: Is golang.org/x/time/rate ... rate.go, in the format of <package path> ... <package-relative file name> ? If so, why wouldn't it work to emit <package path> ... <file base name>? It should be what you want almost all of the time. Could we do something else to make it work ?

perillo

comment created time in a month

issue commentgolang/go

x/tools/go/packages: "conflicting information" error when importing internal or main package

It looks like the importing package already includes the error, at least in this case (see snippet of go list -json output below). I'm wondering if we can just drop the second version of the package, with the error. Are there cases where the error doesn't appear on the importing package?

I'm also wondering if why we need the second version of the package since the error already appears on the importing package.

{
	"Dir": "/Users/matloob/Desktop/m/b",
	"ImportPath": "example.com/m/b",
	"Name": "main",
	"Target": "/Users/matloob/go/bin/b",
	"Root": "/Users/matloob/Desktop/m",
	"Module": {
		"Path": "example.com/m",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/m",
		"GoMod": "/Users/matloob/Desktop/m/go.mod",
		"GoVersion": "1.13"
	},
	"DepOnly": true,
	"Stale": true,
	"StaleReason": "build ID mismatch",
	"GoFiles": [
		"b.go"
	],
	"Deps": [
		"internal/bytealg",
		"internal/cpu",
		"runtime",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"unsafe"
	],
	"Error": {
		"ImportStack": [
			"example.com/m/a",
			"example.com/m/b"
		],
		"Pos": "a/a.go:3:8",
		"Err": "import \"example.com/m/b\" is a program, not an importable package"
	}
}
{
	"Dir": "/Users/matloob/Desktop/m/a",
	"ImportPath": "example.com/m/a",
	"Name": "a",
	"Root": "/Users/matloob/Desktop/m",
	"Module": {
		"Path": "example.com/m",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/m",
		"GoMod": "/Users/matloob/Desktop/m/go.mod",
		"GoVersion": "1.13"
	},
	"Match": [
		"./..."
	],
	"Stale": true,
	"StaleReason": "stale dependency: example.com/m/b",
	"GoFiles": [
		"a.go"
	],
	"Imports": [
		"example.com/m/b"
	],
	"Deps": [
		"example.com/m/b",
		"internal/bytealg",
		"internal/cpu",
		"runtime",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"unsafe"
	],
	"DepsErrors": [
		{
			"ImportStack": [
				"example.com/m/a",
				"example.com/m/b"
			],
			"Pos": "a/a.go:3:8",
			"Err": "import \"example.com/m/b\" is a program, not an importable package"
		}
	]
}
{
	"Dir": "/Users/matloob/Desktop/m/b",
	"ImportPath": "example.com/m/b",
	"Name": "main",
	"Target": "/Users/matloob/go/bin/b",
	"Root": "/Users/matloob/Desktop/m",
	"Module": {
		"Path": "example.com/m",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/m",
		"GoMod": "/Users/matloob/Desktop/m/go.mod",
		"GoVersion": "1.13"
	},
	"Match": [
		"./..."
	],
	"Stale": true,
	"StaleReason": "build ID mismatch",
	"GoFiles": [
		"b.go"
	],
	"Deps": [
		"internal/bytealg",
		"internal/cpu",
		"runtime",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"unsafe"
	]
}
jayconrod

comment created time in a month

issue commentgolang/go

x/tools/cmd/stringer: stringer should not use go/types

I'm not sure exactly what's happening, but it seems like running "go list -json -compiled" is doing a fair amount of extra work, even after a build happens.

Here are commands I ran on the example code, in modules mode, (I had to change the license detector import to v3 since v2's go.mod seems to be broken):

$ go clean -cache && time go build && time go list -compiled >/dev/null && time go list -compiled >/dev/null && time go list -compiled >/dev/null && gopackages -mode types . >/dev/null

# initial build
real	0m2.381s
user	0m10.230s
sys	0m2.811s

# first run of go list -compiled
real	0m3.547s
user	0m3.132s
sys	0m2.248s

# second run of go list -compiled
real	0m0.326s
user	0m0.383s
sys	0m0.469s

# gopackages -mode types
real	0m0.317s
user	0m0.395s
sys	0m0.477s

And go/packages passes the -compiled flag to go list in most modes because it needs the compiled source most of the time to fall back to when export data is missing.

robpike

comment created time in a month

issue commentgolang/go

cmd/go: module-mode import path check is more restrictive than GOPATH mode

Following up here as requested in @rsc's comment on golang.org/cl/212198.

I'm not sure what we did historically, but it looks like now, we do two checks when go-getting in GOPATH mode: first, we call cmd/go/internal/get.CheckImportPath, which is a copy of the definition of CheckImportPath in golang.org/x/mod/module, except that it additionally allows unicode letters as components of import paths (through an edit in its copy of pathOK).

As I understand from reading the code, the get.CheckImportPath call is the only check we do for "vanity" import paths. After that check, when we look up which VCS system is being used, for non-vanity paths, the paths need to match against regexps is vcsPaths. Only the GitHub import path regexp allows non-ascii Unicode letters (not in the repo name, but it paths within a repo). And as I understand it we don't do any stricter checks for vanity import paths. So in effect, non-ascii Unicode letters are only allowed in vanity import paths and in (some) components of Github import paths.

bcmills

comment created time in a month

issue commentgolang/go

x/tools/go/loader: data race reported while running TestCycles

I'm able to reproduce this on linux/amd64 with tools at golang/tools@774c71f and go built from golang/go@82a2f825b7. But it's incredibly rare...

It doesn't show up with -count=1000 but does with -count=10000.

dmitshur

comment created time in a month

issue commentgolang/go

x/mobile/cmd/gomobile: gomobile init fails in an empty module

You're running the go list command from gomubile, right?

When you run the command go list -e -f '{{range context.ReleaseTags}}{{if eq . "go1.14"}}{{.}}{{end}}{{end}}' you're implicitly telling go list to list the package ., the current directory. And that package doesn't exist so go mobile complains.

If you want that command to always succeed you can add a package you know always to exist, such as something in the standard library.

hajimehoshi

comment created time in a month

issue commentgolang/go

go/types: data race in representableConst in Go 1.13 and earlier [1.13 backport]

Including the rationale from the original change. go/types and go/packages (through the go/types dependency) will have a race in 1.13 without this fix.

The race in go/packages reported in #31749 was fixed at tip, but is still an issue for Go 1.13 and earlier, and is showing up in the go/packages race failure reported in #36605.

That race is caused by a race in go/types which in turn is caused by go/constant.Float64Val() calling Rat.Float64 in math/big, which has a race reported in #34919 , and subsequently fixed in tip.

Fixing this race in go/types on Go 1.13 and earlier requires backporting CL 201205 to those releases. (Alternatively, we could fix the race by adding a workaround in go/constant or go/types, but that would be more work). I'm not sure if fixing this is worth a backport but we might as well have the discussion. If we decide not to go with the backport, we'll have to accept a race in go/packages and disable some of its tests in race mode in Go 1.13 and earlier.

gopherbot

comment created time in a month

issue commentgolang/go

go/types: data race in representableConst in Go 1.13 and earlier [1.12 backport]

Including the rationale from the original change. go/types and go/packages (through the go/types dependency) will have a race in 1.13 without this fix.

The race in go/packages reported in #31749 was fixed at tip, but is still an issue for Go 1.13 and earlier, and is showing up in the go/packages race failure reported in #36605.

That race is caused by a race in go/types which in turn is caused by go/constant.Float64Val() calling Rat.Float64 in math/big, which has a race reported in #34919 , and subsequently fixed in tip.

Fixing this race in go/types on Go 1.13 and earlier requires backporting CL 201205 to those releases. (Alternatively, we could fix the race by adding a workaround in go/constant or go/types, but that would be more work). I'm not sure if fixing this is worth a backport but we might as well have the discussion. If we decide not to go with the backport, we'll have to accept a race in go/packages and disable some of its tests in race mode in Go 1.13 and earlier.

gopherbot

comment created time in a month

issue commentgolang/go

go/types: data race in representableConst in Go 1.13 and earlier

cc @dmitshur

matloob

comment created time in a month

issue commentgolang/go

go/types: data race in representableConst in Go 1.13 and earlier

@gopherbot backport please 1.12 1.13

matloob

comment created time in a month

issue openedgolang/go

go/types: data race in representableConst in Go 1.13 and earlier

The race in go/packages reported in #31749 was fixed at tip, but is still an issue for Go 1.13 and earlier, and is showing up in the go/packages race failure reported in #36605.

That race is caused by a race in go/types which in turn is caused by go/constant.Float64Val() calling Rat.Float64 in math/big, which has a race reported in #34919 , and subsequently fixed in tip.

Fixing this race in go/types on Go 1.13 and earlier requires backporting CL 201205 to those releases. (Alternatively, we could fix the race by adding a workaround in go/constant or go/types, but that would be more work). I'm not sure if fixing this is worth a backport but we might as well have the discussion. If we decide not to go with the backport, we'll have to accept a race in go/packages and disable some of its tests in race mode in Go 1.13 and earlier.

created time in a month

issue commentgolang/go

x/tools/go/packages: returns package with no sources in a directory that only contains a test

My philosophy is that go/packages should depart as little as possible, so my preference is that we consider this intended behavior.

To me it seems like go list is trying to satisfy two different models of packages: the one where test packages aren't distinct from non-test packages, before -test existed (where fields like TestGoFiles make sense) and the model when the -test flag is passed where we consider the test and non test packages as independent packages. So this creates a bit of a conflict: go/packages wants to completely exist in the world of the second model, while go list needs to be backwards compatible. I think it's okay to compromise and have weird warts like this in the name of simplicity, though I could be convinced otherwise.

stamblerre

comment created time in a month

issue commentgolang/go

x/tools/go/packages: race detected during execution of various tests

I suspected they wouldn't... the problem is that the users of the code are also in the standard library, so the primary workaround is unworkable for the same reason.

dmitshur

comment created time in a month

issue commentgolang/go

x/tools/go/packages: race detected during execution of various tests

The failure in go/packages looks like #34919. (Which explains why it's only occurring in 1.13 -- #34919 has been fixed on tip).

The fix is a pretty simple cl: golang.org/cl/201205, but I don't know what the bar is for cherry picking something like that in. go/packages relies on it being safe to do concurrent reads of package types, and changing that would be a pretty invasive change, so I don't think we'd want to go down the route of modifying go/packages.

I tried cherrypicking the fix CL (golang.org/cl/201205) and running the tests in race mode and it seems to fix the issue.

@dmitshur, What do you think?

dmitshur

comment created time in a month

issue commentgolang/go

x/tools/go/packages: race detected during execution of various tests

I'll take a look at the go/packages races

dmitshur

comment created time in a month

issue commentgolang/go

x/tools/gopls: support non-vet analyses

I don't know what the reason was that we hadn't added them before, but my guess was that we started conservative when we added the initial set, and just neglected to add others when we expanded the set of analyses we used to include non-vet analyses.

hnlq715

comment created time in a month

issue commentgolang/go

x/tools/go/packages: Load returned packages with errors when specifying GOOS

It's okay to ignore errors. go/packages already tries to do the best it can, and if the information that gomobile needs doesn't depend on perfect code then it should work fine as is.

Specifically for this bug, what I meant was that if we can't depend on Load returning a package if cgo can't run. That's what this bug was originally filed for. But that doesn't mean that tools can't work on the results of go/packagse.

hajimehoshi

comment created time in a month

issue commentgolang/go

x/tools/go/packages: Load returned packages with errors when specifying GOOS

Right: windows returns an error like the following:

# runtime/cgo
gcc_libinit_windows.c:7:10: fatal error: 'windows.h' file not found

I don't think we can get this to work in general.

hajimehoshi

comment created time in a month

issue commentgolang/go

x/tools/go/packages: Load returned packages with errors when specifying GOOS

I think I'll need some help filling in my knowledge of android: I tried to go a go list in your example module: $ CGO_ENABLED=1 GOOS=android go list -e -json -compiled example.com/m

# runtime/cgo
gcc_android.c:6:10: fatal error: 'android/log.h' file not found
{
	"Dir": "/Users/matloob/Desktop/hajimehoshi",
	"ImportPath": "example.com/m",
	"Name": "lib",
	"Root": "/Users/matloob/Desktop/hajimehoshi",
	"Module": {
		"Path": "example.com/m",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/hajimehoshi",
		"GoMod": "/Users/matloob/Desktop/hajimehoshi/go.mod",
		"GoVersion": "1.13"
	},
	"Match": [
		"example.com/m"
	],
	"CgoFiles": [
		"c.go"
	],
	"IgnoredGoFiles": [
		"main.go"
	],
	"Imports": [
		"C",
		"unsafe",
		"runtime/cgo",
		"syscall"
	],
	"Deps": [
		"errors",
		"internal/bytealg",
		"internal/cpu",
		"internal/oserror",
		"internal/race",
		"internal/reflectlite",
		"runtime",
		"runtime/cgo",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"sync",
		"sync/atomic",
		"syscall",
		"unsafe"
	]
}

I don't totally see what's going on but it looks like the problem is that we need the android C libs (like android/log.h to build this. So in general, we won't be able to get the true cgo-processed files unless we're running on a system configured correctly to build android. (And I guess this will be a problem for other platforms as well).

I'm really hesitant about stubbing out the C package with a fake empty package because the results are not totally correct. I wonder what our other options are. Can gomobile guarantee the android C libs exist by setting the right environment variables, etc? Can it inject a fake C package if it knows it will work?

hajimehoshi

comment created time in a month

IssuesEvent

issue commentgolang/go

x/tools/go/packages: Load returned packages with errors when specifying GOOS

Hm okay, I'll take another look.

hajimehoshi

comment created time in a month

delete branch matloob/tinygo

delete branch : dev

delete time in 2 months

pull request commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

As soon as @matloob can perhaps address my last feedback https://github.com/tinygo-org/tinygo/pull/819/files#r363045397 then I think we're good.

Done

matloob

comment created time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha f3c8fa23897e9a96c778f2a7e68303dc3adf5c45

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

+{+    "inherits": ["nrf52840"],+    "build-tags": ["circuitplay_bluefruit"],+    "flash-method": "msd",+    "msd-volume-name": "CPLAYBTBOOT",+    "msd-firmware-name": "firmware.uf2",+    "uf2-family-id": 2913282112,

Done

matloob

comment created time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

 type TargetSpec struct { 	FlashMethod      string   `json:"flash-method"` 	FlashVolume      string   `json:"msd-volume-name"` 	FlashFilename    string   `json:"msd-firmware-name"`+	UF2FamilyID      uint32   `json:"uf2-family-id"`

Sounds good! and this allows us to distinguish between no family id (empty string) and a family id of zero!

matloob

comment created time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha d80bc90f821751af9ab834f2652fdf3ecef20eb6

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha 9eb3d35e850aeeedbbb8464ec8237e36c881395e

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

+{+    "inherits": ["nrf52840"],+    "build-tags": ["circuitplay_bluefruit"],+    "flash-method": "msd",+    "msd-volume-name": "CPLAYBTBOOT",+    "msd-firmware-name": "firmware.uf2",+    "uf2-family-id": "0xADA52840",

Done

matloob

comment created time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

 type TargetSpec struct { 	FlashMethod      string   `json:"flash-method"` 	FlashVolume      string   `json:"msd-volume-name"` 	FlashFilename    string   `json:"msd-firmware-name"`+	UF2FamilyID      uint32   `json:"uf2-family-id"`

Done. Now I'm wondering how this ever worked for me...

matloob

comment created time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

++MEMORY+{+    FLASH_TEXT (rw) : ORIGIN = 0x00000000+0x26000, LENGTH = 796K /* SoftDevice S140. See https://learn.adafruit.com/introducing-the-adafruit-nrf52840-feather/hathach-memory-map */

Done

matloob

comment created time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

+// +build circuitplay_bluefruit++package machine++const HasLowFrequencyCrystal = true++// Hardware pins+const (+	P0_00 Pin = 0

Done

matloob

comment created time in 2 months

Pull request review commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

 type TargetSpec struct { 	FlashMethod      string   `json:"flash-method"` 	FlashVolume      string   `json:"msd-volume-name"` 	FlashFilename    string   `json:"msd-firmware-name"`+	UF2FamilyID      uint32   `json:"uf2-family-id"`

Done

matloob

comment created time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha 365f483bbba723745e734cf96de83f0b5c003ae4

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

issue commentgolang/go

cmd/go: go list reports a mangled ImportPath for a relative path that is not a valid Go package

Yes, we definitely should not return inconsistent ImportPath fields, even when there's an error.

nmiyake

comment created time in 2 months

issue commentgolang/go

x/tools/go/packages: NeedExportsFile and Package.ExportFile are inconsistent

Okay, let's add a TODO. I'm already dissatisfied having the deprecated LoadModes. I'd be more comfortable going with Option 1 once Godoc and the discovery site better hide deprecated APIs, or even once there's a plan for a v1...

mvdan

comment created time in 2 months

issue openedgolang/go

cmd/go: convert tests using testdata files to script framework

I'd like to convert the cmd/go tests using testdata/src as their GOPATH to the script framework. We don't run those tests in parallel because we don't want concurrent go command runs started by the tests using the same GOPATH. While we can modify the test framework to copy the testdata files to a isolated temp directory GOPATH for those tests, I think it's simpler to just convert those tests to the script framework, and that has the additional benefit that we keep the test logic and data together in the same files making the tests easier to read.

created time in 2 months

issue commentgolang/go

x/tools/go/packages: NeedExportsFile and Package.ExportFile are inconsistent

Ugh, I'm ashamed of this.

I'm leaning towards option 2, as much as it's bad. Option 1 is okay, but it means that we'll have two names around forever. Even if it's deprecated, it will always be in the godoc, and code, and it's just a little bit more confusion. Option 3 means that we'd have to fill out both fields forever, which isn't optimal

mvdan

comment created time in 2 months

PR opened tinygo-org/tinygo

targets: add target circuitplay-bluefruit

Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads

Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

+161 -8

0 comment

6 changed files

pr created time in 2 months

PR closed tinygo-org/tinygo

targets: add target circuitplay-bluefruit

Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads

Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

+161 -8

1 comment

6 changed files

matloob

pr closed time in 2 months

pull request commenttinygo-org/tinygo

targets: add target circuitplay-bluefruit

I'm going to close and reopen this so that it's from/to the dev branch instead of master.

matloob

comment created time in 2 months

push eventmatloob/tinygo

Dmitri Goutnik

commit sha 71a380ce8c622480eb4df50f9f43f2e63c00bccc

Add initial FreeBSD support

view details

Ayke van Laethem

commit sha a5a90a57b9a575ce7605219d0342a6dc04e800b3

main: remove getting a serial port in gdb subcommand Remove this code for two reasons: 1. It is not needed. 2. It breaks `tinygo gdb` for debugging QEMU targets (such as cortex-m-qemu).

view details

Michael Matloob

commit sha 9c7aa6c69de532b39932edaebbbf813efc783508

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha 040aae4fa4e124393323a9ed7716394bcd98c8ad

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha f5a43ee53def0723bc221a188a0b652ac329f18e

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

issue openedtinygo-org/tinygo

machine: add support for Circuit Playground Bluefruit

Hello, I'd like to add support for the Adafruit Circuit Playground Bluefruit (https://www.adafruit.com/product/4333). I've got a change here: https://github.com/tinygo-org/tinygo/pull/817.

created time in 2 months

PR opened tinygo-org/tinygo

targets: add target circuitplay-bluefruit

Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads

Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

+165 -8

0 comment

6 changed files

pr created time in 2 months

push eventmatloob/tinygo

Michael Matloob

commit sha 42ff567aa64635d40dcc21e41c6872bd5bdd03af

targets: add target circuitplay-bluefruit Add a target for the Adafruit Circuit Playground Bluefruit, which is based on the nRF52840. Adds the necessary code for the machine package and the json and linker script files in the targets directory. The machine package code is based on board_circuitplay_express.go, with modifications made by consulting the wiring diagram on the adafruit website here: https://learn.adafruit.com/adafruit-circuit-playground-bluefruit/downloads Also adds support to the uf2 conversion packacge to set the familyID field. The Circuit Playground Bluefruit firmware rejects uf2 files without the family id set to 0xADA52840 (and without the flag specifying that the family id is present).

view details

push time in 2 months

fork matloob/tinygo

Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

https://tinygo.org

fork in 2 months

issue commentgolang/go

go/doc: Examples includes example functions with returns

I think we should remove them, and let the vet check flag them.

dmitshur

comment created time in 2 months

issue commentgolang/go

cmd/vet: copylock does not warn when "lock_type_var = *func_return_pointer_to_locktype()"

I'd be okay with the option in your edit in theory, but I'm not convinced it's possible to get it right, and don't know if it's worth the effort.

cracker-ww

comment created time in 2 months

issue commentgolang/go

x/tools/go/analysis/passes/tests: should it re-use go/doc's example classification logic, or continue to implement its own?

This change might be cumbersome because we'd still have to match up the examples returned from go/doc.Examples with the one that's being checked in checkExample, and some of the logic in checkExample will need to stay (checking arguments, return types) because go/doc.Examples throws the function signature.

dmitshur

comment created time in 2 months

issue commentgolang/go

cmd/vet: copylock does not warn when "lock_type_var = *func_return_pointer_to_locktype()"

This code is intentional. See here: https://go-review.googlesource.com/c/go/+/24711/

Maybe we should improve the comment?

cracker-ww

comment created time in 2 months

issue commentgolang/go

cmd/go: error isn't properly reported when running go list on cgo package with missing pkg-config

I'm abandoning the change. We've decided that the cost of the change is greater than the benefit. Because it's impossible to determine which package the error belongs to, we'd have to drop the error (or add errors to all packages) to work around it.

In general it's hard for go/packages to work correctly for code that doesn't build.

muirdm

comment created time in 3 months

issue commentgolang/go

cmd/go: error isn't properly reported when running go list on cgo package with missing pkg-config

What was the error it failed with? we're probably going to have to put another special case in go/packages to ignore that error...

muirdm

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: gopls can't start without pkg-config

I'm going to repurpose this bug to fix the issue in go list.

Note that even when the issue is fixed in go list, if go/packages or gopls are operating on a project that has a dependency on a cgo package that cgo can't successfully be run on, they won't have access to the full set of sources (which need to be generated by cgo). So they might still have problems for those projects.

Of course if none of the packages you're working on have a dependency on the offending package, things should work.

muirdm

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: gopls can't start without pkg-config

I can reproduce the underlying go list issue with the following layout:

foo/go.mod:

module foo

go1.13

foo/foo.go:

package foo

// #cgo pkg-config: bar
import "C"

output of go list -json -compiled . in directory foo:

{
	"Dir": "/Users/matloob/Desktop/foo",
	"ImportPath": "foo",
	"Name": "foo",
	"Root": "/Users/matloob/Desktop/foo",
	"Module": {
		"Path": "foo",
		"Main": true,
		"Dir": "/Users/matloob/Desktop/foo",
		"GoMod": "/Users/matloob/Desktop/foo/go.mod",
		"GoVersion": "1.13"
	},
	"Match": [
		"."
	],
	"Stale": true,
	"StaleReason": "build ID mismatch",
	"CgoFiles": [
		"foo.go"
	],
	"CgoPkgConfig": [
		"bar"
	],
	"Imports": [
		"C",
		"unsafe",
		"runtime/cgo",
		"syscall"
	],
	"Deps": [
		"errors",
		"internal/bytealg",
		"internal/cpu",
		"internal/oserror",
		"internal/race",
		"internal/reflectlite",
		"runtime",
		"runtime/cgo",
		"runtime/internal/atomic",
		"runtime/internal/math",
		"runtime/internal/sys",
		"sync",
		"sync/atomic",
		"syscall",
		"unsafe"
	]
}

I'm going to send a cl to suppress the error in go/packages. There are still two problems in go list. The first is that -e isn't being respected. The second is that no error is being generated in the package output by go list.

muirdm

comment created time in 3 months

issue commentgolang/go

x/tools/go/packages: test timeout on freebsd-amd64-race builder

I'm not sure what we should do. Should we decrease the timeout?

bcmills

comment created time in 3 months

issue commentgolang/go

x/mobile: build failing when using go modules

It sounds reasonable to me.

mirza-s

comment created time in 3 months

issue commentgolang/go

x/tools/gopls: support module-local implementation request

The change has been submitted. Please try it out and let me know if you encounter any issues.

Thanks!!

litleleprikon

comment created time in 3 months

more