profile
viewpoint
Bryan C. Mills bcmills Google Pittsburgh, PA

google/go-cmp 1791

Package for comparing Go values in tests

bcmills/go2go 11

sketches for the Go 2 Type Parameters proposal

bcmills/unsafeslice 7

Reference implementations for golang/go#38203 and golang/go#19367.

bcmills/k8s-mods 5

go.mod files specifying consistent versions of k8s.io dependencies

bcmills/go-experience-reports 1

Experience reports for the Go programming languange (http://golang.org/wiki/ExperienceReports)

bcmills/goissues 1

utility to export golang/go issues to CSV

bcmills/cespare-misc 0

Experiments and bad ideas

bcmills/extra-keyboards-for-chrome-os 0

Extra keyboard layouts and input methods for Chrome OS

bcmills/go-misc 0

Miscellaneous Go hacks

bcmills/issue29268 0

example repository for golang.org/issue/29268

issue openedgolang/go

cmd/go: 'go list' fails to populate Module field for test packages

example.com$ go version
go version devel +84152d57 Wed Jul 1 09:07:18 2020 +0000 linux/amd64

example.com$ go list -test -f '{{.ImportPath}} {{.Module}} {{.ForTest}}' .
example.com example.com
example.com.test <nil>
example.com [example.com.test] example.com example.com

-- a.go --
package a
-- a_test.go --
package a

import "testing"
-- go.mod --
module example.com

go 1.15

Note the <nil> entry in the Module field for the synthesized example.com.test package.

CC @jayconrod @matloob

created time in 2 days

issue commentgolang/go

proposal: os/exec: add option to send Interrupt instead of Kill on Context cancellation

@cpuguy83, we've had a bit more experience with gracefully terminating subprocesses in various parts of the Go project, and the pattern that is emerging seems to be a variant of (*exec.Cmd).Wait rather than exec.Command: https://github.com/golang/go/blob/cacac8bdc5c93e7bc71df71981fdf32dded017bf/src/cmd/go/script_test.go#L1091-L1098

andreynering

comment created time in 2 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 70e12bba0a64b29863de84df020b6d4a093f1e70

subtypes: fix typo in last paragraph Spotted by Jonathan Amsterdam.

view details

push time in 4 days

issue commentgolang/go

proposal: Go 2: interface methods

This is well into "new issue" territory, but how would you call func (r MyReceiver) io.Read([]byte) (int, error)?

Not sure — I haven't worked through the details yet, I just have a high-level sketch.

Probably:

n, err := io.Read(r, p)

but perhaps:

n, err := r.io.Read(p)
carnott-snap

comment created time in 4 days

issue commentgolang/go

cmd/go: go command isn't handling symlinks to directories named as *.go correctly

Turns out to be a very simple fix. This does not appear to be a regression in 1.14; I'm not sure whether it should go into 1.15 (since we're deep into the code freeze) or wait for 1.16.

fishy

comment created time in 7 days

issue commentgolang/go

cmd/go: offer a consistent "global install" command

@peebs

Honoring replaces is when you build a someone elses tested and tagged binary from main. That should only be built one way, not sometimes honoring the replaces and sometimes not.

Note that if you want to build exactly the same binary that someone else tested and built, you also need to set the same build tags and compiler and linker flags that they used, and if the package has any cgo dependencies you need to use the same C toolchain and library versions. If authors of binary tools want that level of control, I would argue that they really ought to package and release binaries, not just tag versions of the source code.

So really, there is a spectrum of control and reproducibility, and we're mostly discussing where within that spectrum to draw the line between “consumers can install with go get” vs. “consumers need to download a prebuilt binary and/or run a custom install script”.

mvdan

comment created time in 7 days

issue commentgolang/go

proposal: errgroup.Group-like Go method for sync.WaitGroup

See previously #23538 and #18022.

oguzyildiz1991

comment created time in 7 days

issue commentgolang/go

proposal: errgroup.Group-like Go method for sync.WaitGroup

I feel like it's not a crazy far-fetched idea since errgroup.Group already has this method.

I agree that this would be a reasonable addition to sync.WaitGroup, but note that the analogous API in errgroup.Group is much harder for callers to get right due to the error return value. (Using a context.WithContext and sync.WaitGroup directly, it's much too easy to accidentally cancel the Context too early and store a secondary error that occurs as a result, instead of the intended primary-cause error.)

Since sync.WaitGroup doesn't deal with errors or return values, there is less (but still non-trivial) risk of mismatched-Add bugs at the call site.

oguzyildiz1991

comment created time in 7 days

issue commentgolang/go

proposal: errgroup.Group-like Go method for sync.WaitGroup

And this would be a nice addition for semaphore.Weighted as well, what do you think?

I would rather add a semaphore to errgroup (#27837) than add goroutine-management to semaphore.Weighted.

oguzyildiz1991

comment created time in 7 days

issue commentgolang/go

cmd/go: get not using GOPROXY and bypassing operation to git

The answer is in your go env output:

set GONOPROXY=*

You have somehow set GONOPROXY to match all module paths — perhaps in your process environment, or perhaps via go env -w. If the latter, go env -u GONOPROXY should fix it.

VladimirDe

comment created time in 8 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 706f2eb752159c767840d6601778602865cc7d30

typelist: clarify comments in examples

view details

push time in 8 days

issue commentgolang/go

proposal: Go 2: interface methods

Regardless, this is an extant issue with method sets and flow style apis

Oh, absolutely. I don't like flow-style APIs either. 🙂 (I much prefer the “constructor with an Options struct” pattern.)

carnott-snap

comment created time in 8 days

issue commentgolang/go

proposal: Go 2: interface methods

Are you also implicitly arguing that method sets should require explicit, qualified references?

Yes..? But that's probably not feasible for Go at this point.

(I would like methods with standardized semantics to be qualified with the package, or perhaps the type, in which they are defined, so that instead of implementing func (r MyReceiver) Read([]byte) (int, error), you would implement func (r MyReceiver) io.Read([]byte) (int, error).)

carnott-snap

comment created time in 8 days

issue commentgolang/go

proposal: Go 2: add mechanism to remove API as a function of caller's go.mod "go 1.xx" version

The same reasoning applies to both. If we are going to break the behavior of an existing program, we should surface that break as an error at compile time, not as unexpected behavior at run time.

bradfitz

comment created time in 8 days

issue commentgolang/go

proposal: Go 2: interface methods

It sounds like you agree that method syntax sugar is better than global funcs, is this correct?

No, I strenuously disagree.

When I see context.WithTimeout(ctx, time.Minute), then I know that there is only one possible definition of WithTimeout and I can find it in the context package. (I can run 'go doc context.WithTimeout` — I don't need a fancy IDE hook to figure it out for me.)

When I see ctx.Timeout(time.Minute), now I have to do some analysis: what is the type of ctx, and is the method defined on that type, or on the underlying type?

Compare https://doc.rust-lang.org/rust-by-example/trait.html:

    let mut dolly: Sheep = …;

    dolly.talk();
    dolly.shear();
    dolly.talk();

When I see dolly.shear(), do I look for a definition (and documentation) on the Sheep type, or on the Animal trait? what about dolly.talk()?

In contrast, with the equivalent explicit method calls (which I believe are also valid in Rust):

    let mut dolly: Sheep = …;

    Animal::talk(dolly);
    Sheep::shear(dolly);
    Animal::talk(dolly);

Now I know exactly where to look for the documentation of each of those functions.

carnott-snap

comment created time in 8 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 798a889418445cc7f4c05d235e1f57841e10648e

typelist: simplify syntax and descriptions

view details

push time in 8 days

issue commentgolang/go

proposal: Go 2: interface methods

If the implementations of the interface can't implement the method, and instances of the interface don't retain the method, then it seems like this proposal is just syntactic sugar for calling global functions as if they were methods.

I've used languages that aggressively push global names over to method syntax (particularly Rust), and I don't like it: it's less verbose, but as a reader the “uniform” method syntax makes it much harder for me to figure out which calls are actually defined on the type vs. which ones are free functions defined elsewhere.

carnott-snap

comment created time in 8 days

issue commentgolang/go

proposal: Go 2: add mechanism to remove API as a function of caller's go.mod "go 1.xx" version

@danp, see https://golang.org/design/28221-go2-transitions#language-redefinitions.

bradfitz

comment created time in 8 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 4ef24188e5e325c1c894dca0a1d417a5308ad9b0

subtypes: revise to account for methods on defined types

view details

Bryan C. Mills

commit sha 4c47b63562d44ee6649047e7679b46d078eeb725

assignable: narrow allowed conversions to ensure that they can always occur directly

view details

push time in 9 days

issue commentgolang/go

proposal: Go 2: interface methods

What would such a method mean if the dynamic type of the interface value also implements a method with the same signature?

What would happen if a value that does not implement the method is assigned to some other interface type that does not provide an implementation? Would its dynamic (concrete) type change by virtue of being assigned from one interface to another? (Interface values do not change in such a way today.)

carnott-snap

comment created time in 9 days

issue commentgolang/go

proposal: io: new Timeout interface implemented by errors

Note that this can be implemented using an Is method on errors that currently have a Timeout method that returns true, so it should be entirely backward compatible.

That can be done for errors in the standard library, but we cannot easily update user-defined timeout errors to do the same. (See https://github.com/golang/go/issues/33411#issuecomment-517534266.)

carnott-snap

comment created time in 9 days

issue commentgolang/go

cmd/go2go: anonymous func with generics

@dolmen, it would arguably be more consistent to allow a function declaration at local scope, which could then be parameterized. (A function declaration — unlike a function literal — is not a value, so the questions about the type of that value would be moot.)

mattn

comment created time in 9 days

issue closedgolang/go

cmd/go: use version control to discover the main module's version?

This is a follow-on to #26404 and #29228.

When a binary is build from within a module's source tree, the output from runtime/debug.ReadBuildInfo currently reports that module as having version (devel).

If the source tree is a pristine checkout from a version-control system — or is within the (read-only) module cache — we could instead interrogate the version-control system to find the corresponding version or pseudo-version to embed.

However, that has a couple of caveats:

  1. It would require us to run VCS commands within the user's source tree. Historically, running VCS commands has been a source of entirely too many go command vulnerabilities, so we would really like to avoid issuing VCS commands except when they are absolutely necessary.
  2. Given a commit, we can produce a pseudo-version for that commit, but we can't tell whether that commit has been published to the origin. It would be nice to preserve the invariant that only published versions are advertised in debug info, but that may incur an extra network fetch.
  3. Within a module, we apply that module's replacements and exclusions, and the user's VCS checkout may also have applied some transformations. (devel) currently provides a clue that those module-specific changes are in effect: if we were to indicate an explicit version instead, we would need to provide some way to indicate that replacements and exclusions were applied.

(CC @jayconrod @rsc @hyangah)

closed time in 9 days

bcmills

issue commentgolang/go

cmd/go: use version control to discover the main module's version?

Duplicate of #37475

bcmills

comment created time in 9 days

issue commentgolang/go

cmd/go: use version control to discover the main module's version?

Proposal #37475 is approved, so closing this as a duplicate.

bcmills

comment created time in 9 days

issue commentgolang/go

internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional

Note that there are a few other environment variables that affect compiler behavior that are also not supported in go/env or tracked as test inputs:

  • GO_GCFLAGS (#18222)
  • GOSSAFUNC, GOSSAHASH (#31290; see especially https://github.com/golang/go/issues/31290#issuecomment-482094899)
  • possiblyGOCLOBBERDEADHASH, and GO_SSA_PHI_LOC_CUTOFF (but I couldn't find any remaining sites in the code that actually consume these variables, so maybe they're gone now).
  • GSHS_LOGFILE: https://github.com/golang/go/blob/7e71c9c3edbf5b7a8608d6f739c20420a618e0ab/src/cmd/compile/internal/ssa/func.go#L734 https://github.com/golang/go/blob/567556d78657326c99b8fa84ec2a5ee511a0941b/src/cmd/go/internal/work/exec.go#L286-L292

However, GOROOT_FINAL is somewhat different from those in that it is interpreted directly by cmd/go.

dmitshur

comment created time in 9 days

issue commentgolang/go

internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional

Hmm, that's an interesting question. The main purpose of cfg.KnownEnv is to control which variables may be stored (and read) from the go/env configuration file, but today we do not read GOROOT_FINAL from that file: https://github.com/golang/go/blob/daf70d6c1688a1ba1699c933b3c3f04d6f2f73d9/src/cmd/go/internal/cfg/cfg.go#L336-L344

On the other hand, it really does affect the behavior of cmd/go for all binaries that depend on std, not just during make.bash.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

I think Jay's suggestion to backport CL 214387 is probably the right approach for 1.14 and 1.13.

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: TestBuildIDContainsArchModeEnv/386 fails on linux/386 in Go 1.14 and 1.13, not 1.15

I don't think there's anything left to do for 1.15.

(Users don't typically check for staleness explicitly anyway, so they don't care what specific text we use to report it as long as we correctly deduce whether targets actually need to be rebuilt. Since they don't care about the specific text, we shouldn't either.)

dmitshur

comment created time in 9 days

issue commentgolang/go

cmd/go: offer a consistent "global install" command

For bbolt... if you have a dependency that isn't merging fixes for critical issues (such as memory-corruption bugs) in a timely manner, it may be wise to reconsider use of that dependency.

On the other hand, that seems like a clear case where making it easier to use replace to paper over the problem produces a better local state at the cost of a worse global state: that would substantially reduce the incentive to get the fixes merged upstream at all, and if you're worried about fragmenting the user base, “~everyone carrying the same local patches” does not seem any better than “some projects moving over to a fork”.

mvdan

comment created time in 9 days

issue commentgolang/go

cmd/go: offer a consistent "global install" command

For sqlite, perhaps it would make sense to invert the sense of the build tags..? If programs are slightly larger with the tags, and some programs are missing necessary functionality without them, then it seems like the default behavior should be “slightly larger” instead of “missing necessary functionality”. In other words: this still seems like a usability issue to fix upstream.

mvdan

comment created time in 9 days

issue commentgolang/go

cmd/go: offer a consistent "global install" command

@egonelbre, for the grpc case, would it make sense to (instead of forking) send an upstream patch to implement a +build constraint that drops the problematic dependency? Then you could set a build tag to prune the dependency from your binary, instead of needing to maintain local patches.

mvdan

comment created time in 9 days

issue commentgolang/go

cmd/go: unable to "go get" repository with external LFS server (go modules)

See also https://github.com/golang/go/issues/38941#issuecomment-626754044 (somehow related to git-lfs smudging).

campbellr

comment created time in 10 days

issue commentgolang/go

cmd/go: unable to "go get" repository with external LFS server (go modules)

See also #29987 (also related to LFS).

campbellr

comment created time in 10 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 50130c56cd41fd79b167873b55dd60df4399c569

typelist: fix broken links

view details

push time in 10 days

push eventbcmills/go2go

Bryan C. Mills

commit sha d6e617ec5d0a41389edc72561e0dfe5eb66dbeab

ordered: sketch a workaround for type specialization

view details

Bryan C. Mills

commit sha 3e3bcd4fb6a4f2675c034ba08c890dc71fd991c9

typelist: describe problems with type lists and a more orthogonal alternative

view details

push time in 10 days

issue commentgolang/go

cmd/go: offer a consistent "global install" command

@mvdan, also recall that the module cache strips the contents of vendor directories (and perhaps the directories themselves?).

So “built exactly as if you had fetched it from a proxy, extracted it to a temporary directory, changed to the directory, and typed go install” is still not quite the same as “built exactly as if you had cloned it from upstream, changed to the directory, and typed go install”, and I suspect the similarity between those two definitions would be confusing.

mvdan

comment created time in 10 days

push eventbcmills/go2go

Bryan C. Mills

commit sha f22beb4b8d353d62d7759751209ae47697c986bc

append3: re-enable a case that is fixed

view details

Bryan C. Mills

commit sha dae7a4ad675925fec8892c4149846c0a44149ca8

atomic: add examples illustrating a niche need for a "non-interface" constraint

view details

push time in 11 days

issue openedgolang/go

cmd/go2go: misleading error for embedded struct field of type parameter

https://go2goplay.golang.org/p/596K-mmE-Jm was an attempt to define a generic test case equivalent to https://play.golang.org/p/f8yMpNN3aDn:

package main

type I interface{}

type S(type T) struct {
	*T
}

func main() {
	_ = S(I){}
}

I did not expect https://go2goplay.golang.org/p/596K-mmE-Jm to compile, but the error message that it gives seems wrong:

# play
./prog.go2:6: undefined: T

compared with

./prog.go:6:3: embedded type cannot be a pointer to interface

for the non-generic version.

I expected the go2go version to instead produce some sort of error message referring to the fact that T could be an interface type.

created time in 11 days

issue commentgolang/go

cmd/go2go: type inference failing for nested type parameters

This crops up in a number of other places too, such as append and analogous libraries for transforming and/or aggregating slices and maps.

DeedleFake

comment created time in 11 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 56a2c454f0fe16c4faf5ba7df34ed0cd13192ce3

subtypes: add lines to break up rules; avoid dfn tags because GitHub strips them in rendering

view details

push time in 11 days

issue commentgolang/go

cmd/go2go: constraints that are type parameters

Also, note that we cannot deduce anything about permitted operations from this kind of constraint.

We should be able to deduce that B is assignable to A, but I agree that the need for a type-list to make this work at all implies that it would not be very useful as a pointwise addition to the design.

griesemer

comment created time in 11 days

push eventbcmills/go2go

Bryan C. Mills

commit sha f62875c332148cb507fade853926e0b225a2dff0

subtypes: remove stray newlines in channel rules

view details

push time in 11 days

push eventbcmills/go2go

Bryan C. Mills

commit sha e0585e1158bae49ad282deaa8080b063f6738e0e

subtypes: add A Theory of Subtyping for Go

view details

push time in 11 days

issue commentgolang/go

proposal: spec: generic programming facilities

@martisch, note that ordered — unlike comparable — is not coherent as an interface type unless we also define a (global) total order among concrete types, or prohibit non-generic code from using < on variables of type ordered, or prohibit the use of comparable as a general, run-time interface type.

Otherwise, transitivity of “implements” breaks down. Consider this program fragment:

	var x constraints.Ordered = int(0)
	var y constraints.Ordered = string("0")
	fmt.Println(x < y)

What should it output? (Is the answer intuitive, or arbitrary?)

adg

comment created time in 11 days

issue commentgolang/go

cmd/dist: No way to run verbose / for tests

Are you using a go binary built from a different GOROOT? (What does go list . report for the package path?)

stevenh

comment created time in 14 days

issue commentgolang/go

cmd/dist: No way to run verbose / for tests

Um... Why use run.bash in that case instead of go test directly?

stevenh

comment created time in 14 days

issue openedgolang/go

cmd/go2go: poor diagnostics for type-lists of interface types used as type constraints

I was experimenting a bit with type-lists as type constraints, since a type-list containing only interface types is conceptually itself an interface.

The program in https://go2goplay.golang.org/p/nBXRVl8RKX4 does not produce an error today. It probably should.

The program in https://go2goplay.golang.org/p/Y2yzWbOOS9t produces a misleading T is not an interface error (even though T is necessarily an interface).

The program in https://go2goplay.golang.org/p/82ff4-1eW5- produces a spurious duplicate type … in type list error.

(CC @ianlancetaylor @griesemer)

created time in 14 days

issue commentgolang/go

cmd/go2go: recursive constraints doesn't work correctly

@beoran

I think that such a constraint is meaningless since, if I understand correctly, it simply reduces to the type T itstelf.

As currently implemented, if T is an interface, then type T itself matches all subtypes of T (that is, all interface and concrete types that implement T), whereas interface { type T } matches only (literal and defined) types whose underlying type is exactly the same interface type (with no additional methods).

tdakkota

comment created time in 15 days

issue commentgolang/go

cmd/go2go: compiler error after translation

Looks like the translator somehow substituted the underlying type for the defined type.

zeebo

comment created time in 15 days

issue commentklauspost/compress

zstd: add no-goroutine option to encoding

Under what conditions do the goroutines leak? (Would it make sense to, for example, set a finalizer in NewEncoder that panics if Close is not called on the returned *Encoder before it becomes unreachable?)

twmb

comment created time in 15 days

issue commentgolang/go

sync: clarify WaitGroup.Done() behaviour when the counter is zero

@leventov, if the counter goes negative, an overflow occurs in the WaitGroup (#20687), which can corrupt the waiter count: https://github.com/golang/go/blob/go1.14.4/src/sync/waitgroup.go#L64

That is not formally a data race, but it's also not a recoverable condition. You really don't want to call Done mindlessly in a loop.

leventov

comment created time in 15 days

issue commentgolang/go

proposal: os: make errFinished satisfy errors.Is(..., ErrNotExist)

Thinking about method calls in grammatical terms, I expect os.ErrNotExist to indicate “the direct object (of the verb) does not exist”:

  • os.ErrNotExist from Stat(f) indicates “could not Stat [verb] f [direct object] because f does not exist.”
  • os.ErrNotExist from Open(f) indicates “could not Open [verb] f [direct object] because f does not exist.”

The proposed usage would be consistent with that, but requires the reader to treat the name of the method as the verb (as they should, but may not always do).

  • “Could not Signal [verb] p [direct object] with sig [object of preposition] because p does not exist.”
  • “Could not send [verb] Signal sig [direct object] to p [indirect object] because sig does not exist.”

On the other hand, the error text of os.ErrNotExist is specifically documented as file does not exist, and as @networkimprov notes, there is no file involved in Signal unless you consider the PID itself to be a file. I would not expect most users to make that association.

I think a more general standardized error for “[direct object] does not exist” could be useful, but I agree that, because of its specific text, os.ErrNotExist is not quite that error.

inyutin

comment created time in 15 days

issue commentgolang/go

proposal: x/exp/mmap: expose a File-like type

Is there a reason you can't (or shouldn't) wrap it in an io.SectionReader?

sbinet

comment created time in 15 days

issue commentgolang/go

sync: clarify WaitGroup.Done() behaviour when the counter is zero

A panic in Go is a recoverable operation, but a surplus call to Done is often accompanied by a data race (which is undefined behavior, not a recoverable error). So I think it would be a mistake to define a surplus call to Done as a panic, since the panic is only defined behavior for a narrow subset of surplus-Done calls.

On the other hand, we have already made that mistake for the Add method, and Done() is equivalent to Add(-1).

leventov

comment created time in 15 days

issue commentgolang/go

proposal: context: add Merge

For values, Merge would presumably bias toward one parent context or the other. I don't see that as a big problem.

I don't think runtime magic is needed to avoid goroutines, but we would at least need some (subtle) global lock-ordering for the cancellation locks, since we could no longer rely on the cancellation graph being tree-structured. It would at least be subtle to implement and test, and might carry some run-time overhead.

navytux

comment created time in 16 days

issue commentgolang/go

cmd/go: do not allow the main module to replace (to or from) itself

But that wouldn't solve the problem of replacing to the main module's directory, which we still can't allow (and which I can't justify silently ignoring).

rselph-tibco

comment created time in 16 days

issue commentgolang/go

cmd/go: do not allow the main module to replace (to or from) itself

We could perhaps also just ignore the selected version of the main module when matching replace directives. (We never did precisely nail down the semantics of those — see #26344.)

rselph-tibco

comment created time in 16 days

issue commentgolang/go

cmd/go: go.mod inconsistency between "go mod tidy" and "go build"

@ceejatec, replacing the selected version of the main module itself is not a “feature” — it is a bug.

You can replace specific older versions of the main module regardless of #34417.

ceejatec

comment created time in 16 days

push eventbcmills/go2go

Bryan C. Mills

commit sha 1f7493d7701683a7b617e6fa712cdd25b4bbd90b

append4: delete useless variant

view details

push time in 16 days

pull request commentgomodule/redigo

gomod

@domino14, you need to be using Go 1.14 or higher for go get to ignore the +incompatible version.

dcormier

comment created time in 16 days

issue openedgoogle/gitiles

gitiles Markdown rendering fails to preserve <dfn> tags

Via https://crbug.com/gerrit/12377:

Full URL exhibiting the problem: https://go.googlesource.com/proposal/+/refs/changes/80/220080/3/design/36460-lazy-module-loading.md

Expected behavior: <dfn> element present in the original Markdown source should be preserved, per https://spec.commonmark.org/0.29/#raw-html.

Observed behavior: <dfn> elements are stripped out of the Markdown text rendered by Gitiles.

created time in 16 days

issue commentgolang/go

cmd/go: clarify "does not contain package" error?

CC @jayconrod @matloob

I'm not sure how we could make this clearer without also making it too verbose, but if you have a specific suggestion we could consider it.

kstenerud

comment created time in 16 days

issue commentgolang/go

cmd/go: clarify "does not contain package" error?

CC @jayconrod @matloob

I'm not sure how we could make this clearer without also making it too verbose, but if you have a specific suggestion we could consider it.

kstenerud

comment created time in 16 days

issue commentgolang/go

Can't seem to import modules from other directory trees

(Note that, by design, only replace directives from the main module's go.mod file are applied.)

cleblanc189

comment created time in 16 days

issue commentgolang/go

Can't seem to import modules from other directory trees

You have added a replace directive for <code>test.go/src/<b>server</b>/v1beta1</code>. The error occurs when resolving an import of <code>test.go/src/<b>service</b>/v1beta1</code>.

(However, note that for the vast majority of uses, we recommend a single module at the repo root rather than nested modules for subdirectories. This would be a lot simpler with a single module for test.go/src as a whole.)

cleblanc189

comment created time in 16 days

issue commentgolang/go

os.Chmod file.Chmod different behavior on Windows

CC @alexbrainman @mattn

Could this be due to other stray bits in m? (What happens if you use (m&os.ModePerm)|0222 instead?

TACIXAT

comment created time in 16 days

issue commentgolang/go

cmd/go2go: anonymous func with generics

In this example, since x is a variable in local scope, it should be valid to use as a value.

What would it mean to pass x to some other function as a value of type interface{}? (For example, what would reflect.TypeOf(x) report?)

mattn

comment created time in 16 days

create barnchbcmills/go2go

branch : master

created branch time in 17 days

created repositorybcmills/go2go

sketches for the Go 2 Type Parameters proposal

created time in 17 days

issue closedgolang/go

cmd/go: no way to vendor symlink files with Go modules

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> $ go version go version go1.14.3 darwin/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="auto" GOARCH="amd64" GOBIN="" GOCACHE="/Users/chizhg/Library/Caches/go-build" GOENV="/Users/chizhg/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/chizhg/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/chizhg/go/src/k8s.io/test-infra/go.mod" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/n1/3yzf5ppx0_9c0vnsmf8k6k2c00lvhy/T/go-build213053347=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

  1. In https://github.com/knative/serving/tree/master/config, we have added a few symlinks to aggregate files from different folders to one place.
  2. One of our downstream projects needs to vendor the knative.dev/serving project using Go modules, and needs these symlinks in config/ as well.

What did you expect to see?

The symlinks can be vendored by the downstream project by either

  • adding a dummy.go file under the config/ package, and adding import _ "knative.dev/serving/config in one of the Go files

or

  • implementing a tool to copy these files in, as suggested in https://github.com/golang/go/issues/26366

What did you see instead?

The symlinks cannot be vendored by using the first approach (adding a dummy.go file), and it cannot be vendored by force copying either, as when we run go list -f '{{.Dir}}' -mod=readonly -m knative.dev/serving, the local mod directory does not contain the symlinks in the first place.

closed time in 17 days

chizhg

issue commentgolang/go

cmd/go: no way to vendor symlink files with Go modules

Closing as not providing a large enough benefit to outweigh the churn of invalidating checksums.

chizhg

comment created time in 17 days

issue commentgolang/go

cmd/go: no way to vendor symlink files with Go modules

You should be able to find the actual files underlying the links using go list, but the symlinks themselves will not be present: as mentioned above, they are intentionally omitted from the module zip file, and the zip files are checksummed, so their contents cannot change without a really compelling reason.

Your git clone alternative seems like the right approach here. These symlinks are not needed for the go tool itself, and the go tool's requirements are what drive the module file formats.

chizhg

comment created time in 17 days

issue commentgolang/go

x/pkgsite: tests don't pass on a clean clone

In general I would expect go test ./... to pass at head within any golang.org/x module without needing to install or start any services that aren't already standard in the development environment.

(I agree with @mvdan: some sort of opt-in to the non-hermetic tests would probably be a good idea. Would it be reasonable for the test to start and stop its own database, perhaps as a subprocess, if one isn't already running and exec.LookPath finds a suitable version?)

mvdan

comment created time in 18 days

issue commentgolang/go

cmg/go: TestScript/mod_gomodcache and TestScript/generate_env are failing on Plan 9

Milestoning to 1.15, since this fixes a broken test and has an open CL.

fhs

comment created time in 18 days

issue commentgolang/go

spec: struct can implement an interface with an inherited method but attempting to call that method can cause an unexpected panic

I believe this is exactly the case described in #18617. (Note that that issue is a proposal for a backward-incompatible change to the language.)

finnbear

comment created time in 18 days

issue commentgolang/go

cmd/go: go list -e does not assign missing import errors to correct package

Michael tagged the CL as wait-release shortly after it was mailed, so looks like 1.16.

rsc

comment created time in 18 days

issue commentgolang/go

cmd/go: no way to vendor symlink files with Go modules

when we run go list -f '{{.Dir}}' -mod=readonly -m knative.dev/serving, the local mod directory does not contain the symlinks in the first place.

What did you do to try to populate it?

chizhg

comment created time in 18 days

issue commentgolang/go

cmd/go: no way to vendor symlink files with Go modules

Not all filesystems in current use support symlinks. The module file formats are intended to be portable, so symlinks are intentionally skipped (see #27093 and https://github.com/golang/go/issues/24057#issuecomment-377430635).

chizhg

comment created time in 18 days

issue commentgolang/go

runtime: macOS-only segfault on 1.14+ with "split stack overflow"

That said, this example in https://github.com/golang/go/issues/39079#issuecomment-643500979 does not look safe in general to me. If there is already an alternate signal stack in place, then something somewhere (in this case, presumably the Go runtime) allocated that signal stack, and may expect to use sigaltstack to subsequently locate it for deallocation.

So I would expect that a program that does this sort of sigaltstack reallocation in Go should use the pattern:

	runtime.LockOSThread()
	s := C.replaceAltStack()
	defer func() {
		C.restoreAltStack(s)
		runtime.UnlockOSThread()
	}()
	…

So, another question: does the bug still reproduce if you execute runtime.LockOSThread() prior to registering the alternate stack? (My guess would be that it does, but it never hurts to verify.)

alexcrichton

comment created time in 18 days

issue commentgolang/go

runtime: macOS-only segfault on 1.14+ with "split stack overflow"

What version of macOS was this observed on? (#37605 describes another situation in which the macOS signal handler seems to race with what ought to be atomic updates to thread state.)

alexcrichton

comment created time in 18 days

issue commentgolang/go

Go ignores required version

What did you do?

Please post the actual program that reproduces the problem. This one does not — the main.go file seems to have been oversimplified.

mymod$ txtar * </dev/null
-- go.mod --
module mymod

go 1.13

require golang.org/x/sys v0.0.0-20190204203706-41f3e6584952
-- main.go --
package main

func main() {

}

mymod$ go build

mymod$ cat go.mod
module mymod

go 1.13

require golang.org/x/sys v0.0.0-20190204203706-41f3e6584952

From the error message you are reporting, I suspect that your actual program includes the line

import (
	"golang.org/x/sys"
)

which provokes go build to attempt to find some version of a module containing the package golang.org/x/sys. The module golang.org/x/sys does not have any .go source files at its root, so there is no such package (as the error message states).

kstenerud

comment created time in 18 days

issue commentgolang/go

runtime: "unexpected return pc for runtime.pthread_kill_trampoline" on darwin builders

The darwin-amd64-race builder was upgraded to macOS 10.15 (CL 222238) in early March, and the only failure since then was on a 10_14 builder. So that's consistent with the theory of a pthread_kill platform bug in macOS 10.14.

bcmills

comment created time in 18 days

issue openedgolang/go

runtime: SIGSEGV during sigpanic in TestCgoCallbackGC on netbsd-386-9_0 builder

2020-06-12T17:25:26-7d975ae/netbsd-386-9_0

--- FAIL: TestCgoCallbackGC (0.71s)
    crash_test.go:105: /tmp/go-build517568832/testprogcgo.exe CgoCallbackGC exit status: exit status 2
    crash_cgo_test.go:70: expected "OK\n", but got:
        fatal error: unexpected signal during runtime execution
        [signal SIGSEGV: segmentation violation code=0x1 addr=0xcd42f9e0 pc=0xada54001]
        
        runtime stack:
        runtime.throw(0x81765a7, 0x2a)
        	/tmp/workdir/go/src/runtime/panic.go:1116 +0x64
        runtime.sigpanic()
        	/tmp/workdir/go/src/runtime/signal_unix.go:704 +0x38e
        
        goroutine 14 [syscall]:
        runtime.cgocall(0x8138c38, 0x85677dc, 0x85677dc)
        	/tmp/workdir/go/src/runtime/cgocall.go:133 +0x61 fp=0x85677c8 sp=0x85677b0 pc=0x804c971
        main._Cfunc_foo()
        	_cgo_gotypes.go:228 +0x2d fp=0x85677dc sp=0x85677c8 pc=0x81317fd
        main.CgoCallbackGC.func2(0x8502080)
        	/tmp/workdir/go/src/runtime/testdata/testprogcgo/callback.go:85 +0x14 fp=0x85677e8 sp=0x85677dc pc=0x8136984
        runtime.goexit()
        	/tmp/workdir/go/src/runtime/asm_386.s:1333 +0x1 fp=0x85677ec sp=0x85677e8 pc=0x80a35f1
        created by main.CgoCallbackGC
        	/tmp/workdir/go/src/runtime/testdata/testprogcgo/callback.go:84 +0xde

Possibly related to #37605.

CC @ianlancetaylor @cherrymui @bsiegert

created time in 18 days

issue commentmattn/go-sqlite3

Can't upgrade to version 2.0.5

@mattn, you can satisfy most of your requirements by tagging the next release as v1.14.0 and including a go.mod file in it.

However, in order for users who already depend on v2.0.0 through v2.0.3 to upgrade to that version, they will have to prune out any existing dependencies on those versions, then run go get github.com/mattn/go-sqlite3@v1.14. (After that point, go get -u should keep them on the v1 line.)

kolaente

comment created time in 18 days

issue commentgolang/go

cmd/go: go.mod inconsistency between "go mod tidy" and "go build"

(See specifically https://github.com/golang/go/issues/34417#issuecomment-533653497.)

ceejatec

comment created time in 18 days

issue closedgolang/go

cmd/go: go.mod inconsistency between "go mod tidy" and "go build"

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

<pre> $ go version go version go1.14.4 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes (confirmed with gotip).

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/ceej/.cache/go-build" GOENV="/home/ceej/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/ceej/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/ceej/.cbdepscache/exploded/x86_64/go-1.14.4/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/ceej/.cbdepscache/exploded/x86_64/go-1.14.4/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/tmp/foo/go.mod" 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-build286401846=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

I have a project with two inter-dependent modules. Our overall build checks out both modules into sibling directories, and we use "replace" directives so that the code can find each other. This is necessary because both projects are actively developed and we don't want to have to release/tag each of them every time there's a change to get into a build.

One of those projects also depends on a separate package "go-jsonpointer" which is not yet converted to Go modules, and that package in turn depends on another package "gojson" which is also not yet converted to Go modules.

What did you expect to see?

We expect that "go mod tidy" immediately followed by "go build -mod=read" should succeed. This was confirmed by @jayconrod to be expected behaviour on #31248 .

What did you see instead?

What we see is that "go build" updates go.mod to add "gojson" as an //indirect dependency - this is correct. However, "go mod tidy" removes that entry from go.mod. What this means is that if we run "go mod tidy" (which is normal good practice), then "go build -mod=readonly" will fail with

/home/ceej/go/pkg/mod/github.com/dustin/go-jsonpointer@v0.0.0-20160814072949-ba0abeacc3dc/bytes.go:9:2: cannot find module providing package github.com/dustin/gojson: import lookup disabled by -mod=readonly

Minimal reproducer

I've created a minimal test case which demonstrates this issue, including a script that shows the error when using "go build -mod=readonly": https://github.com/ceejatec/go-mod-bug

You can see the bug by just:

git clone git://github.com/ceejatec/go-mod-bug
cd go-mod-bug
./repro.sh

closed time in 18 days

ceejatec

issue commentgolang/go

cmd/go: go.mod inconsistency between "go mod tidy" and "go build"

Duplicate of #34417

ceejatec

comment created time in 18 days

issue commentgolang/go

cmd/go: don't follow an infinite number of redirects

I'm ambivalent on backporting. On the one hand, a hung go command can be very difficult to diagnose. On the other hand, it's easy to terminate such a command to un-stick it.

oiooj

comment created time in 21 days

issue commentgolang/go

cmd/go: go build ./... may or may not write executable to disk depending how many packages the import path pattern matches

As of Go 1.13, you can pass -o . to explicitly request output of multiple binaries (see https://golang.org/doc/go1.13#go-command, and design discussion on #14295).

For the sake of consistency, it is unfortunate that we do write the binary when the pattern happens to match only one package, but I'm not sure how feasible that would be to change.

xyzst

comment created time in 22 days

issue commentgolang/go

Go mod error loading requirements and unknown revisions

I have no idea about gvm or how it works. Generally extensions like vscode should use whichever go command is first in $PATH, so you might check what PATH you're running vscode with. (If you're starting vscode using a GUI, typically that environment is set in your .profile script rather than .zshrc, and you'll need to log out and back in to pick up changes.)

leguminosa

comment created time in 22 days

issue commentgolang/go

cmd/go: test -c should error on unknown flags

That is: the cost of rejecting flags is the same for both known and unknown flags, but the benefit is higher.

(The cost is the need to remove the flag before attaching -c. The benefit is the likelihood of catching an accidental typo of some other flag.)

mvdan

comment created time in 22 days

issue commentgolang/go

cmd/go: test -c should error on unknown flags

If the flag is known to go test, then it's less likely to be a typo of some other known flag. So I would continue to accept those, on the theory that continuing to accept them does make it easier to just tack a -c on the end of a command to get a binary.

mvdan

comment created time in 22 days

issue commentdominikh/go-tools

stylecheck: decide fate of CheckUnexportedReturn

Another problem with unexported return-types is that they impede refactoring.

In general, one can refactor code like:

	x := somepkg.Something()

to

	var x somepkg.SomeType
	if y {
		x = somepkg.Something()
	}
	…
	if y {
		use(x)
	}

If the caller cannot name the type of x (because that type is unexported), then that refactoring is impossible.

dominikh

comment created time in 23 days

issue commentgolang/go

Go mod error loading requirements and unknown revisions

Per the Go project's release policy, go 1.12.7 has been unsupported since 2020-02-25, and in the interim we have added workarounds for a number of git client bugs.

Please try go1.14.4 (the current release) and let us know if this issue is still reproducible.

leguminosa

comment created time in 23 days

issue commentgolang/go

proposal: context: Add Merge

@seebs, if the background work is continuing after the network handler returns, it's generally not appropriate to hold on to arbitrary values from the handler's Context anyway. (It may include stale values, such as tracing or logging keys, and could end up preventing a lot of other data reachable via ctx.Value() from being garbage-collected.)

navytux

comment created time in 23 days

more