Unnamed: 0,id,type,created_at,repo,repo_url,action,title,labels,body,index,text_combine,label,text,binary_label 41279,5346072400.0,IssuesEvent,2017-02-17 18:40:55,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/go/loader: tests are too brittle,Testing,"The x/tools/go/loader tests have a history of breaking whenever something in the standard library changes. Or breaking when testing Go 1.6 vs Go 1.7 vs Go 1.8 vs Go tip, etc. I think it's time to rethink those tests to not be a maintenance burden. (Latest example: https://go-review.googlesource.com/c/37148/) /cc @ianlancetaylor ",1.0,"x/tools/go/loader: tests are too brittle - The x/tools/go/loader tests have a history of breaking whenever something in the standard library changes. Or breaking when testing Go 1.6 vs Go 1.7 vs Go 1.8 vs Go tip, etc. I think it's time to rethink those tests to not be a maintenance burden. (Latest example: https://go-review.googlesource.com/c/37148/) /cc @ianlancetaylor ",0,x tools go loader tests are too brittle the x tools go loader tests have a history of breaking whenever something in the standard library changes or breaking when testing go vs go vs go vs go tip etc i think it s time to rethink those tests to not be a maintenance burden latest example cc ianlancetaylor ,0 24974,5115265922.0,IssuesEvent,2017-01-06 21:14:43,golang/go,https://api.github.com/repos/golang/go,closed,doc: define the first class ports,Documentation NeedsFix,"build.golang.org links to ""First Class Ports"": https://github.com/golang/go/wiki/PortingPolicy But that doesn't say which ports are the first class ones. Further, the checkbox on https://build.golang.org to show only first class ports seems to only filter by GOOS, not (GOOS,GOARCH), so it shows things like linux-mips64le and linux-ppc64 as being first class, which I don't think is true. We don't even have linux-ppc64 big-endian builders at the moment. Let's clarify. ",1.0,"doc: define the first class ports - build.golang.org links to ""First Class Ports"": https://github.com/golang/go/wiki/PortingPolicy But that doesn't say which ports are the first class ones. Further, the checkbox on https://build.golang.org to show only first class ports seems to only filter by GOOS, not (GOOS,GOARCH), so it shows things like linux-mips64le and linux-ppc64 as being first class, which I don't think is true. We don't even have linux-ppc64 big-endian builders at the moment. Let's clarify. ",1,doc define the first class ports build golang org links to first class ports but that doesn t say which ports are the first class ones further the checkbox on to show only first class ports seems to only filter by goos not goos goarch so it shows things like linux and linux as being first class which i don t think is true we don t even have linux big endian builders at the moment let s clarify ,1 370260,25895992671.0,IssuesEvent,2022-12-14 22:31:04,golang/go,https://api.github.com/repos/golang/go,closed,spec: Document rules for recursive type and other self-referential decls,Documentation,"
The spec says "An interface type T may not embed itself or any interface type that
embeds T, recursively.", but nothing like this is mentioned for structs.

(A struct containing itself would obviously need infty memory, but the spec should
probably still explicitly mention that these are illegal while a struct containing a
pointer to itself is fine
",1.0,"spec: Document rules for recursive type and other self-referential decls - 
The spec says "An interface type T may not embed itself or any interface type that
embeds T, recursively.", but nothing like this is mentioned for structs.

(A struct containing itself would obviously need infty memory, but the spec should
probably still explicitly mention that these are illegal while a struct containing a
pointer to itself is fine
",1,spec document rules for recursive type and other self referential decls the spec says quot an interface type t may not embed itself or any interface type that embeds t recursively quot but nothing like this is mentioned for structs a struct containing itself would obviously need infty memory but the spec should probably still explicitly mention that these are illegal while a struct containing a pointer to itself is fine ,1 145587,11699464127.0,IssuesEvent,2020-03-06 15:41:12,golang/go,https://api.github.com/repos/golang/go,closed,x/text/unicode/norm: TestLinking consistently failing on multiple builders,NeedsInvestigation Testing,"See previously #32843. `TestLinking` appears to be failing consistently on the following builders: * `linux-arm` (https://build.golang.org/log/367d5667c1ab0411c469fb3ff70496dec84e41e0) ``` normalize_test.go:937: tables appear not to be dropped: 1945437 - 1941429 = 4008 ``` * `linux-arm64-packet` (https://build.golang.org/log/a52ea14003e838e42ca1cd2b4082435838e79631) ``` normalize_test.go:937: tables appear not to be dropped: 2095708 - 2091220 = 4488 ``` * `linux-ppc64le-buildlet` (https://build.golang.org/log/6c896381e8a1c82f113eb45978ff309dd893513e) ``` normalize_test.go:937: tables appear not to be dropped: 2098114 - 2093534 = 4580 ``` * `linux-ppc64le-power9osu` (https://build.golang.org/log/8b01ed9d81fbc80df42ad31a20de438c946f9ec0) ``` normalize_test.go:937: tables appear not to be dropped: 2098114 - 2093534 = 4580 ``` The failures are all similar, but the reported numbers vary by platform. If a test failure on these platforms is expected, the test should be skipped.",1.0,"x/text/unicode/norm: TestLinking consistently failing on multiple builders - See previously #32843. `TestLinking` appears to be failing consistently on the following builders: * `linux-arm` (https://build.golang.org/log/367d5667c1ab0411c469fb3ff70496dec84e41e0) ``` normalize_test.go:937: tables appear not to be dropped: 1945437 - 1941429 = 4008 ``` * `linux-arm64-packet` (https://build.golang.org/log/a52ea14003e838e42ca1cd2b4082435838e79631) ``` normalize_test.go:937: tables appear not to be dropped: 2095708 - 2091220 = 4488 ``` * `linux-ppc64le-buildlet` (https://build.golang.org/log/6c896381e8a1c82f113eb45978ff309dd893513e) ``` normalize_test.go:937: tables appear not to be dropped: 2098114 - 2093534 = 4580 ``` * `linux-ppc64le-power9osu` (https://build.golang.org/log/8b01ed9d81fbc80df42ad31a20de438c946f9ec0) ``` normalize_test.go:937: tables appear not to be dropped: 2098114 - 2093534 = 4580 ``` The failures are all similar, but the reported numbers vary by platform. If a test failure on these platforms is expected, the test should be skipped.",0,x text unicode norm testlinking consistently failing on multiple builders see previously testlinking appears to be failing consistently on the following builders linux arm normalize test go tables appear not to be dropped linux packet normalize test go tables appear not to be dropped linux buildlet normalize test go tables appear not to be dropped linux normalize test go tables appear not to be dropped the failures are all similar but the reported numbers vary by platform if a test failure on these platforms is expected the test should be skipped ,0 276135,20970537493.0,IssuesEvent,2022-03-28 10:56:25,golang/go,https://api.github.com/repos/golang/go,closed,net/netip: inconsistent terminology for IPv4-mapped IPv6 addresses in documentation,Documentation help wanted NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read https://pkg.go.dev/net/netip@go1.18 ### What did you expect to see? A consistent name for IPv4 addresses wrapped in IPv6 addresses. ### What did you see instead? Many different names or phrases have appeared in the documentation, and they seem to refer to the same thing: - IPv4-mapped IPv6 address - IP4-mapped IPv6 address - IPv6-mapped IPv4 address - v6-mapped form - v6-mapped IPv6 address - v6-mapped IPv4 IP ",1.0,"net/netip: inconsistent terminology for IPv4-mapped IPv6 addresses in documentation - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read https://pkg.go.dev/net/netip@go1.18 ### What did you expect to see? A consistent name for IPv4 addresses wrapped in IPv6 addresses. ### What did you see instead? Many different names or phrases have appeared in the documentation, and they seem to refer to the same thing: - IPv4-mapped IPv6 address - IP4-mapped IPv6 address - IPv6-mapped IPv4 address - v6-mapped form - v6-mapped IPv6 address - v6-mapped IPv4 IP ",1,net netip inconsistent terminology for mapped addresses in documentation please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what did you do read what did you expect to see a consistent name for addresses wrapped in addresses what did you see instead many different names or phrases have appeared in the documentation and they seem to refer to the same thing mapped address mapped address mapped address mapped form mapped address mapped ip ,1 141113,12957747957.0,IssuesEvent,2020-07-20 10:12:20,golang/go,https://api.github.com/repos/golang/go,closed,x/xerrors: clarify documentation around stack frames ,Documentation NeedsInvestigation,"The docs for the `x/xerrors` package currently state ``` Most of the functions and types in this package will be incorporated into the standard library's errors package in Go 1.13; the behavior of this package's Errorf function will be incorporated into the standard library's fmt.Errorf. ``` This is not accurate. `fmt.Errorf` does _not_ provide the stack-trace functionality of `xerrors.Errorf`. Accordingly, I would suggest changing this docstring to ``` Most of the functions and types in this package have been incorporated into the standard library's errors package in Go 1.13. However, if you wish to retain the stack trace functionality of `xerrors.Errorf`, you will need to keep using this package. ```",1.0,"x/xerrors: clarify documentation around stack frames - The docs for the `x/xerrors` package currently state ``` Most of the functions and types in this package will be incorporated into the standard library's errors package in Go 1.13; the behavior of this package's Errorf function will be incorporated into the standard library's fmt.Errorf. ``` This is not accurate. `fmt.Errorf` does _not_ provide the stack-trace functionality of `xerrors.Errorf`. Accordingly, I would suggest changing this docstring to ``` Most of the functions and types in this package have been incorporated into the standard library's errors package in Go 1.13. However, if you wish to retain the stack trace functionality of `xerrors.Errorf`, you will need to keep using this package. ```",1,x xerrors clarify documentation around stack frames the docs for the x xerrors package currently state most of the functions and types in this package will be incorporated into the standard library s errors package in go the behavior of this package s errorf function will be incorporated into the standard library s fmt errorf this is not accurate fmt errorf does not provide the stack trace functionality of xerrors errorf accordingly i would suggest changing this docstring to most of the functions and types in this package have been incorporated into the standard library s errors package in go however if you wish to retain the stack trace functionality of xerrors errorf you will need to keep using this package ,1 11043,3454719393.0,IssuesEvent,2015-12-17 17:00:15,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document 'go generate' flags -n -v -x,Documentation,"Looking at https://tip.golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source right now: > Usage: > > ``` > go generate [-run regexp] [file.go... | packages] > ``` However, at the bottom it mentions: > It also accepts the standard build flags -v, -n, and -x. The -v flag prints the names of packages and files as they are processed. The -n flag prints commands that would be executed. The -x flag prints commands as they are executed. The usage line should be updated to mention those additional flags: ```diff -go generate [-run regexp] [file.go... | packages] +go generate [-v] [-n] [-x] [-run regexp] [file.go... | packages] ``` Other commands have their usage complete and do not skip -n and -x flags that are available, for example: ``` go clean [-i] [-r] [-n] [-x] [build flags] [packages] go fmt [-n] [-x] [packages] go tool [-n] command [args...] go vet [-n] [-x] [build flags] [packages] go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages] ``` It seems -v is never included even if available, so maybe it's most consistent to do: ``` go generate [-n] [-x] [-run regexp] [file.go... | packages] ```",1.0,"cmd/go: document 'go generate' flags -n -v -x - Looking at https://tip.golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source right now: > Usage: > > ``` > go generate [-run regexp] [file.go... | packages] > ``` However, at the bottom it mentions: > It also accepts the standard build flags -v, -n, and -x. The -v flag prints the names of packages and files as they are processed. The -n flag prints commands that would be executed. The -x flag prints commands as they are executed. The usage line should be updated to mention those additional flags: ```diff -go generate [-run regexp] [file.go... | packages] +go generate [-v] [-n] [-x] [-run regexp] [file.go... | packages] ``` Other commands have their usage complete and do not skip -n and -x flags that are available, for example: ``` go clean [-i] [-r] [-n] [-x] [build flags] [packages] go fmt [-n] [-x] [packages] go tool [-n] command [args...] go vet [-n] [-x] [build flags] [packages] go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages] ``` It seems -v is never included even if available, so maybe it's most consistent to do: ``` go generate [-n] [-x] [-run regexp] [file.go... | packages] ```",1,cmd go document go generate flags n v x looking at right now usage go generate however at the bottom it mentions it also accepts the standard build flags v n and x the v flag prints the names of packages and files as they are processed the n flag prints commands that would be executed the x flag prints commands as they are executed the usage line should be updated to mention those additional flags diff go generate go generate other commands have their usage complete and do not skip n and x flags that are available for example go clean go fmt go tool command go vet go get it seems v is never included even if available so maybe it s most consistent to do go generate ,1 14384,3833096687.0,IssuesEvent,2016-04-01 00:49:00,golang/go,https://api.github.com/repos/golang/go,closed,"net/http: documentation of ""func (*Client) Do"" doesn't state clearly when to close response.Body",Documentation,"by **fish@freigeist.org**: 
The documentation for Do()[1] says:

"When err is nil, resp always contains a non-nil resp.Body."

But it doesn't specify the behaviour if error is non-nil:
Do I need to close the Body if err is NOT nil?






---
[1] https://godoc.org/net/http#Client.Do
",1.0,"net/http: documentation of ""func (*Client) Do"" doesn't state clearly when to close response.Body - by **fish@freigeist.org**: 
The documentation for Do()[1] says:

"When err is nil, resp always contains a non-nil resp.Body."

But it doesn't specify the behaviour if error is non-nil:
Do I need to close the Body if err is NOT nil?






---
[1] https://godoc.org/net/http#Client.Do
",1,net http documentation of func client do doesn t state clearly when to close response body by fish freigeist org the documentation for do says quot when err is nil resp always contains a non nil resp body quot but it doesn t specify the behaviour if error is non nil do i need to close the body if err is not nil a href ,1 193106,15367368212.0,IssuesEvent,2021-03-02 03:08:44,golang/go,https://api.github.com/repos/golang/go,closed,x/website:https://golang.org/doc/code,Documentation NeedsFix help wanted,"Using https://golang.org/doc/code and Go 1.16. The part where you use `go install` does not automatically download the remote package. What you see is in the document is: ``` $ go install example.com/user/hello go: finding module for package github.com/google/go-cmp/cmp go: downloading github.com/google/go-cmp v0.4.0 go: found github.com/google/go-cmp/cmp in github.com/google/go-cmp v0.4.0 ``` What I got was: ``` $ go install example.com/user/hello hello.go:7:2: no required module provides package github.com/google/go-cmp/cmp; to add it: go get github.com/google/go-cmp/cmp ``` After running `go get github.com/google/go-cmp/cmp`, rerunning produces: ``` $ go install example.com/user/hello $ ``` If I am correct, I am happy to update the document. If I am wrong, happy to learn why! ",1.0,"x/website:https://golang.org/doc/code - Using https://golang.org/doc/code and Go 1.16. The part where you use `go install` does not automatically download the remote package. What you see is in the document is: ``` $ go install example.com/user/hello go: finding module for package github.com/google/go-cmp/cmp go: downloading github.com/google/go-cmp v0.4.0 go: found github.com/google/go-cmp/cmp in github.com/google/go-cmp v0.4.0 ``` What I got was: ``` $ go install example.com/user/hello hello.go:7:2: no required module provides package github.com/google/go-cmp/cmp; to add it: go get github.com/google/go-cmp/cmp ``` After running `go get github.com/google/go-cmp/cmp`, rerunning produces: ``` $ go install example.com/user/hello $ ``` If I am correct, I am happy to update the document. If I am wrong, happy to learn why! ",1,x website using and go the part where you use go install does not automatically download the remote package what you see is in the document is go install example com user hello go finding module for package github com google go cmp cmp go downloading github com google go cmp go found github com google go cmp cmp in github com google go cmp what i got was go install example com user hello hello go no required module provides package github com google go cmp cmp to add it go get github com google go cmp cmp after running go get github com google go cmp cmp rerunning produces go install example com user hello if i am correct i am happy to update the document if i am wrong happy to learn why ,1 94525,10826081538.0,IssuesEvent,2019-11-09 20:08:48,golang/go,https://api.github.com/repos/golang/go,closed,crypto/tls: add an example for using VerifyPeerCertificate to customize verification logic,Documentation NeedsFix,"A number of proposals to add knobs to tls.Config were closed by providing a way to achieve the same result with InsecureSkipVerify and VerifyPeerCertificate. There should be a basic example that replicates the standard verification logic, so users can edit if needed.",1.0,"crypto/tls: add an example for using VerifyPeerCertificate to customize verification logic - A number of proposals to add knobs to tls.Config were closed by providing a way to achieve the same result with InsecureSkipVerify and VerifyPeerCertificate. There should be a basic example that replicates the standard verification logic, so users can edit if needed.",1,crypto tls add an example for using verifypeercertificate to customize verification logic a number of proposals to add knobs to tls config were closed by providing a way to achieve the same result with insecureskipverify and verifypeercertificate there should be a basic example that replicates the standard verification logic so users can edit if needed ,1 28503,13726351203.0,IssuesEvent,2020-10-03 23:13:32,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: introduce masked memeq,Performance,"This is an idea to experiment with. I don't know whether it'll yield enough fruit to be worth the added code. Consider this type: ``` type T struct { x uint64 b bool } ``` Arrays of `T` require generated alg routines. This is because x has a required alignment of 8, so there's a 7 byte gap between Ts in the array, so we can't use one big memeq call. We could, however, introduce a masked memeq, to which the compiler passes not only the length of the memory to compare but also a repeating mask, probably of a fixed size. For T, the mask would be something like `1111111110000000` (nine 1s, seven 0s). When comparing memory the routine would load bytes from memory, mask out some of the bytes, and then do the comparison. This is the kind of thing that SIMD instructions excel at on many platforms. This would also work for structs containing blank fields (fields named _). This could also work for hash routines: Mask out bytes before feeding them to the regular hash routine. We could also use this as the first step in other alg routines. For example, `[8]string`'s equality function could start by calling memeqmask with a size of 8*8*2 (on 64 bit systems) and a mask of `1111111100000000` (eight 1s, eight 0s), to compare all the lengths. Then it could do its second loop to compare all the contents. cc @martisch @randall77 ",True,"cmd/compile: introduce masked memeq - This is an idea to experiment with. I don't know whether it'll yield enough fruit to be worth the added code. Consider this type: ``` type T struct { x uint64 b bool } ``` Arrays of `T` require generated alg routines. This is because x has a required alignment of 8, so there's a 7 byte gap between Ts in the array, so we can't use one big memeq call. We could, however, introduce a masked memeq, to which the compiler passes not only the length of the memory to compare but also a repeating mask, probably of a fixed size. For T, the mask would be something like `1111111110000000` (nine 1s, seven 0s). When comparing memory the routine would load bytes from memory, mask out some of the bytes, and then do the comparison. This is the kind of thing that SIMD instructions excel at on many platforms. This would also work for structs containing blank fields (fields named _). This could also work for hash routines: Mask out bytes before feeding them to the regular hash routine. We could also use this as the first step in other alg routines. For example, `[8]string`'s equality function could start by calling memeqmask with a size of 8*8*2 (on 64 bit systems) and a mask of `1111111100000000` (eight 1s, eight 0s), to compare all the lengths. Then it could do its second loop to compare all the contents. cc @martisch @randall77 ",0,cmd compile introduce masked memeq this is an idea to experiment with i don t know whether it ll yield enough fruit to be worth the added code consider this type type t struct x b bool arrays of t require generated alg routines this is because x has a required alignment of so there s a byte gap between ts in the array so we can t use one big memeq call we could however introduce a masked memeq to which the compiler passes not only the length of the memory to compare but also a repeating mask probably of a fixed size for t the mask would be something like nine seven when comparing memory the routine would load bytes from memory mask out some of the bytes and then do the comparison this is the kind of thing that simd instructions excel at on many platforms this would also work for structs containing blank fields fields named this could also work for hash routines mask out bytes before feeding them to the regular hash routine we could also use this as the first step in other alg routines for example string s equality function could start by calling memeqmask with a size of on bit systems and a mask of eight eight to compare all the lengths then it could do its second loop to compare all the contents cc martisch ,0 211419,16444338085.0,IssuesEvent,2021-05-20 17:41:36,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document os changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
os

TODO: https://golang.org/cl/268020: avoid allocation in File.WriteString

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46018."" in the body.",1.0,"doc/go1.17: document os changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
os

TODO: https://golang.org/cl/268020: avoid allocation in File.WriteString

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46018."" in the body.",1,doc document os changes for go as of filing this issue the contained the following html os todo a href avoid allocation in file writestring this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 314625,27014291962.0,IssuesEvent,2023-02-10 17:53:33,golang/go,https://api.github.com/repos/golang/go,closed,all: test failures with `ETXTBSY` [1.20 backport],Testing GoCommand CherryPickApproved,"@bcmills requested issue #58019 to be considered for backport to the next 1.20 minor release. > @gopherbot, please backport to Go 1.20. The `list_goroot_symlink` test sometimes fails with this symptom on the release branch, and the fix is test-only. ",1.0,"all: test failures with `ETXTBSY` [1.20 backport] - @bcmills requested issue #58019 to be considered for backport to the next 1.20 minor release. > @gopherbot, please backport to Go 1.20. The `list_goroot_symlink` test sometimes fails with this symptom on the release branch, and the fix is test-only. ",0,all test failures with etxtbsy bcmills requested issue to be considered for backport to the next minor release gopherbot please backport to go the list goroot symlink test sometimes fails with this symptom on the release branch and the fix is test only ,0 43766,7064816639.0,IssuesEvent,2018-01-06 12:18:38,golang/go,https://api.github.com/repos/golang/go,closed,proposal: Documentation for Go package types and functions should have 'since GOVERSION' at the end,Documentation Proposal,"When browsing Go packages, it is impossible to know since when a type or a function is part of the language. In fact, off the top of my head, I don't know any feasible way to get this information, apart from: - `git blame`ing the specified source (which won't work if there were styling adjustments / documentation updates) - using that function/type and running a build across all Go versions and check when the build starts failing. - browsing all Go release patch notes looking for the function/type in question. All of these steps are very cumbersome. A way to identify the version since when a package feature is available would be very handy, especially for projects that try to support multiple Go versions. In general, it would be very informative to browse a package and see when a feature was introduced, and enable the reader to load up the release notes of that version and see if they can find some motivation behind the feature. It could also be the last straw to make the reader finally upgrade to the latest version. For example, Java does this and it truly has its benefits. While the PROs are very strong, the CON obviously is that it is a lot of work to update the docs to include this information. ",1.0,"proposal: Documentation for Go package types and functions should have 'since GOVERSION' at the end - When browsing Go packages, it is impossible to know since when a type or a function is part of the language. In fact, off the top of my head, I don't know any feasible way to get this information, apart from: - `git blame`ing the specified source (which won't work if there were styling adjustments / documentation updates) - using that function/type and running a build across all Go versions and check when the build starts failing. - browsing all Go release patch notes looking for the function/type in question. All of these steps are very cumbersome. A way to identify the version since when a package feature is available would be very handy, especially for projects that try to support multiple Go versions. In general, it would be very informative to browse a package and see when a feature was introduced, and enable the reader to load up the release notes of that version and see if they can find some motivation behind the feature. It could also be the last straw to make the reader finally upgrade to the latest version. For example, Java does this and it truly has its benefits. While the PROs are very strong, the CON obviously is that it is a lot of work to update the docs to include this information. ",1,proposal documentation for go package types and functions should have since goversion at the end when browsing go packages it is impossible to know since when a type or a function is part of the language in fact off the top of my head i don t know any feasible way to get this information apart from git blame ing the specified source which won t work if there were styling adjustments documentation updates using that function type and running a build across all go versions and check when the build starts failing browsing all go release patch notes looking for the function type in question all of these steps are very cumbersome a way to identify the version since when a package feature is available would be very handy especially for projects that try to support multiple go versions in general it would be very informative to browse a package and see when a feature was introduced and enable the reader to load up the release notes of that version and see if they can find some motivation behind the feature it could also be the last straw to make the reader finally upgrade to the latest version for example java does this and it truly has its benefits while the pros are very strong the con obviously is that it is a lot of work to update the docs to include this information ,1 211048,16416280521.0,IssuesEvent,2021-05-19 07:11:43,golang/go,https://api.github.com/repos/golang/go,closed,Can we document net.Conn Write as being atomic?,Documentation,"I answered this [stackoverflow question](https://stackoverflow.com/a/67595487/152580) about the atomicity of net.Conn Write. It seems the implementation on both Unix and Windows is atomic in practice by acquiring a mutex around the OS write/send call(s). One could possibly remove the mutex and thus allow writes to interleave - but that seems senseless and very likely will break real-world code at this point. Not documenting that guarantee requires callers to maintain their own mutex around calls to write, and it is redundant and expensive to nest mutexes like that. Is it possible to document that interleaved writes are not permitted (i.e. that Write is atomic)? One might argue the threadsafe guarantee for net.Conn already promises that - but it's ambiguous - it might just mean it doesn't crash. ",1.0,"Can we document net.Conn Write as being atomic? - I answered this [stackoverflow question](https://stackoverflow.com/a/67595487/152580) about the atomicity of net.Conn Write. It seems the implementation on both Unix and Windows is atomic in practice by acquiring a mutex around the OS write/send call(s). One could possibly remove the mutex and thus allow writes to interleave - but that seems senseless and very likely will break real-world code at this point. Not documenting that guarantee requires callers to maintain their own mutex around calls to write, and it is redundant and expensive to nest mutexes like that. Is it possible to document that interleaved writes are not permitted (i.e. that Write is atomic)? One might argue the threadsafe guarantee for net.Conn already promises that - but it's ambiguous - it might just mean it doesn't crash. ",1,can we document net conn write as being atomic i answered this about the atomicity of net conn write it seems the implementation on both unix and windows is atomic in practice by acquiring a mutex around the os write send call s one could possibly remove the mutex and thus allow writes to interleave but that seems senseless and very likely will break real world code at this point not documenting that guarantee requires callers to maintain their own mutex around calls to write and it is redundant and expensive to nest mutexes like that is it possible to document that interleaved writes are not permitted i e that write is atomic one might argue the threadsafe guarantee for net conn already promises that but it s ambiguous it might just mean it doesn t crash ,1 66378,8920200871.0,IssuesEvent,2019-01-21 05:31:22,golang/go,https://api.github.com/repos/golang/go,closed,"flag: PrintDefaults claims configurability, but doesn't say how",Documentation NeedsFix,"https://golang.org/pkg/flag/#PrintDefaults says > PrintDefaults prints, to standard error unless configured otherwise, ... I couldn't see anywhere how to send its output anywhere else. I dug through the source code and eventually made my way to `(*FlagSet).SetOutput`, but that was not at all obvious. ",1.0,"flag: PrintDefaults claims configurability, but doesn't say how - https://golang.org/pkg/flag/#PrintDefaults says > PrintDefaults prints, to standard error unless configured otherwise, ... I couldn't see anywhere how to send its output anywhere else. I dug through the source code and eventually made my way to `(*FlagSet).SetOutput`, but that was not at all obvious. ",1,flag printdefaults claims configurability but doesn t say how says printdefaults prints to standard error unless configured otherwise i couldn t see anywhere how to send its output anywhere else i dug through the source code and eventually made my way to flagset setoutput but that was not at all obvious ,1 211619,16451187557.0,IssuesEvent,2021-05-21 06:06:18,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document restrictions on module zip extraction,Documentation GoCommand NeedsInvestigation modules," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13rc1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/home/leighmcculloch/local/bin""
GOCACHE=""/home/leighmcculloch/.cache/go-build""
GOENV=""/home/leighmcculloch/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/leighmcculloch/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/leighmcculloch/local/bin/go/1.13rc1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/leighmcculloch/local/bin/go/1.13rc1/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/leighmcculloch/devel/test/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-build749101513=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Attempted to `go get` a package at a version. ``` go get github.com/gobuffalo/packr@v1.21.4 ``` ### What did you expect to see? The packages to be `go get`d without any issue. ### What did you see instead? `go get` error'd saying that the package in the sum db is `410 Gone`. ``` $ go get github.com/gobuffalo/packr@v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: finding github.com v1.21.4 go: finding github.com/gobuffalo v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: downloading github.com/gobuffalo/packr v1.21.4 verifying github.com/gobuffalo/packr@v1.21.4: github.com/gobuffalo/packr@v1.21.4: reading https://sum.golang.org/lookup/github.com/gobuffalo/packr@v1.21.4: 410 Gone ``` If I visit the `sum.golang.org` URL manually in a browser, I see this error: ``` not found: unzip /tmp/gopath/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" ``` The `packr` project did indeed have two files named `SHOULDERS.md` and `shoulders.md` in `v1.21.4`. Setting `GONOSUMDB` and turning off `GOPROXY` moves past the limitation in sum.golang.org, but then a similar error appears locally: ``` $ GONOSUMDB=github.com/gobuffalo/packr GOPROXY=direct go1.13rc1 get github.com/gobuffalo/packr@v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: downloading github.com/gobuffalo/packr v1.21.4 go: extracting github.com/gobuffalo/packr v1.21.4 -> unzip /home/leighmcculloch/go/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" go get: unzip /home/leighmcculloch/go/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" ``` It appears that versions of projects that contain case insensitive collisions are currently not supported in Go Modules. Checking out the package into a GOPATH manually as `go get` used to still works, and `dep` successfully works with it too. I think for portability there's some value in not allowing files that collide on case insensitive file systems, but existing packages that were published are now inaccessible. _This issue was encountered while attempting to upgrade a repo from dep to modules stellar/go#1634._",1.0,"cmd/go: document restrictions on module zip extraction - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13rc1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/home/leighmcculloch/local/bin""
GOCACHE=""/home/leighmcculloch/.cache/go-build""
GOENV=""/home/leighmcculloch/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/leighmcculloch/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/leighmcculloch/local/bin/go/1.13rc1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/leighmcculloch/local/bin/go/1.13rc1/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/leighmcculloch/devel/test/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-build749101513=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Attempted to `go get` a package at a version. ``` go get github.com/gobuffalo/packr@v1.21.4 ``` ### What did you expect to see? The packages to be `go get`d without any issue. ### What did you see instead? `go get` error'd saying that the package in the sum db is `410 Gone`. ``` $ go get github.com/gobuffalo/packr@v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: finding github.com v1.21.4 go: finding github.com/gobuffalo v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: downloading github.com/gobuffalo/packr v1.21.4 verifying github.com/gobuffalo/packr@v1.21.4: github.com/gobuffalo/packr@v1.21.4: reading https://sum.golang.org/lookup/github.com/gobuffalo/packr@v1.21.4: 410 Gone ``` If I visit the `sum.golang.org` URL manually in a browser, I see this error: ``` not found: unzip /tmp/gopath/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" ``` The `packr` project did indeed have two files named `SHOULDERS.md` and `shoulders.md` in `v1.21.4`. Setting `GONOSUMDB` and turning off `GOPROXY` moves past the limitation in sum.golang.org, but then a similar error appears locally: ``` $ GONOSUMDB=github.com/gobuffalo/packr GOPROXY=direct go1.13rc1 get github.com/gobuffalo/packr@v1.21.4 go: finding github.com/gobuffalo/packr v1.21.4 go: downloading github.com/gobuffalo/packr v1.21.4 go: extracting github.com/gobuffalo/packr v1.21.4 -> unzip /home/leighmcculloch/go/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" go get: unzip /home/leighmcculloch/go/pkg/mod/cache/download/github.com/gobuffalo/packr/@v/v1.21.4.zip: case-insensitive file name collision: ""SHOULDERS.md"" and ""shoulders.md"" ``` It appears that versions of projects that contain case insensitive collisions are currently not supported in Go Modules. Checking out the package into a GOPATH manually as `go get` used to still works, and `dep` successfully works with it too. I think for portability there's some value in not allowing files that collide on case insensitive file systems, but existing packages that were published are now inaccessible. _This issue was encountered while attempting to upgrade a repo from dep to modules stellar/go#1634._",1,cmd go document restrictions on module zip extraction what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin home leighmcculloch local bin gocache home leighmcculloch cache go build goenv home leighmcculloch config go env goexe goflags gohostarch gohostos linux gonoproxy gonosumdb goos linux gopath home leighmcculloch go goprivate goproxy goroot home leighmcculloch local bin go gosumdb sum golang org gotmpdir gotooldir home leighmcculloch local bin go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home leighmcculloch devel test go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do attempted to go get a package at a version go get github com gobuffalo packr what did you expect to see the packages to be go get d without any issue what did you see instead go get error d saying that the package in the sum db is gone go get github com gobuffalo packr go finding github com gobuffalo packr go finding github com go finding github com gobuffalo go finding github com gobuffalo packr go downloading github com gobuffalo packr verifying github com gobuffalo packr github com gobuffalo packr reading gone if i visit the sum golang org url manually in a browser i see this error not found unzip tmp gopath pkg mod cache download github com gobuffalo packr v zip case insensitive file name collision shoulders md and shoulders md the packr project did indeed have two files named shoulders md and shoulders md in setting gonosumdb and turning off goproxy moves past the limitation in sum golang org but then a similar error appears locally gonosumdb github com gobuffalo packr goproxy direct get github com gobuffalo packr go finding github com gobuffalo packr go downloading github com gobuffalo packr go extracting github com gobuffalo packr unzip home leighmcculloch go pkg mod cache download github com gobuffalo packr v zip case insensitive file name collision shoulders md and shoulders md go get unzip home leighmcculloch go pkg mod cache download github com gobuffalo packr v zip case insensitive file name collision shoulders md and shoulders md it appears that versions of projects that contain case insensitive collisions are currently not supported in go modules checking out the package into a gopath manually as go get used to still works and dep successfully works with it too i think for portability there s some value in not allowing files that collide on case insensitive file systems but existing packages that were published are now inaccessible this issue was encountered while attempting to upgrade a repo from dep to modules stellar go ,1 379400,26369965461.0,IssuesEvent,2023-01-11 19:47:06,golang/go,https://api.github.com/repos/golang/go,closed,x/net/html: add StripTags example,Documentation NeedsFix,"Stripping HTML tags is absolutely required for every web related development task. This was previously raised in: https://github.com/golang/go/issues/5884 ",1.0,"x/net/html: add StripTags example - Stripping HTML tags is absolutely required for every web related development task. This was previously raised in: https://github.com/golang/go/issues/5884 ",1,x net html add striptags example stripping html tags is absolutely required for every web related development task this was previously raised in ,1 14264,8529225903.0,IssuesEvent,2018-11-03 09:34:42,golang/go,https://api.github.com/repos/golang/go,closed,net: SetDeadline performance is poor,NeedsInvestigation Performance,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.2 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/svn/jessemjchen/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/svn/jessemjchen"" GORACE="""" GOROOT=""/home/svn/go"" GOTMPDIR="""" GOTOOLDIR=""/home/svn/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build019705885=/tmp/go-build"" ### What did you do? I write a server in golang，and I use SetReadDeadline/SetWriteDeadline to set a timeout . But when I benchmark ,and use pprof to get cpu pprof ，I get a bad performance because of this two function. ![image](https://user-images.githubusercontent.com/960434/40954233-3dc27568-68b6-11e8-8dd5-f1530fb8a6e1.png) ### What did you expect to see? SetReadDeadline/SetWriteDeadline occupy less cpu time. ### What did you see instead? SetReadDeadline/SetWriteDeadline occupy lots of cpu time. ",True,"net: SetDeadline performance is poor - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.2 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/svn/jessemjchen/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/svn/jessemjchen"" GORACE="""" GOROOT=""/home/svn/go"" GOTMPDIR="""" GOTOOLDIR=""/home/svn/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build019705885=/tmp/go-build"" ### What did you do? I write a server in golang，and I use SetReadDeadline/SetWriteDeadline to set a timeout . But when I benchmark ,and use pprof to get cpu pprof ，I get a bad performance because of this two function. ![image](https://user-images.githubusercontent.com/960434/40954233-3dc27568-68b6-11e8-8dd5-f1530fb8a6e1.png) ### What did you expect to see? SetReadDeadline/SetWriteDeadline occupy less cpu time. ### What did you see instead? SetReadDeadline/SetWriteDeadline occupy lots of cpu time. ",0,net setdeadline performance is poor please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache home svn jessemjchen cache go build goexe gohostarch gohostos linux goos linux gopath home svn jessemjchen gorace goroot home svn go gotmpdir gotooldir home svn go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build what did you do i write a server in golang，and i use setreaddeadline setwritedeadline to set a timeout but when i benchmark and use pprof to get cpu pprof ，i get a bad performance because of this two function what did you expect to see setreaddeadline setwritedeadline occupy less cpu time what did you see instead setreaddeadline setwritedeadline occupy lots of cpu time ,0 11454,7550621525.0,IssuesEvent,2018-04-18 17:29:34,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: sometimes issue rematerializable values early,Performance,"```go package p var ( s *int b bool ) func f() { var q *int if b { q = new(int) } else { q = new(int) } s = q } ``` This code is a bit silly, but it's the smallest reproduction I have handy. :) When compiled, this code tests b, and on each branch it contains an LEAQ of `type.int`. The LEAQ should be hoisted above the branch, since it is needed immediately in each case, and there are registers to spare. The CSE pass does its work, and there is a single LEAQ instruction going into regalloc. However, early in regalloc, we decide to issue it every place we need it: ```go if s.values[v.ID].rematerializeable { // Value is rematerializeable, don't issue it here. // It will get issued just before each use (see // allocValueToReg). for _, a := range v.Args { a.Uses-- } s.advanceUses(v) continue } ``` This is usually the right decision--disabling this bit of code causes an overall regression. But as the initial code shows, there are instances in which it'd be better to issue the rematerializable value right away. I'm not sure exactly what the right set of conditions is, though. cc @cherrymui @randall77 ",True,"cmd/compile: sometimes issue rematerializable values early - ```go package p var ( s *int b bool ) func f() { var q *int if b { q = new(int) } else { q = new(int) } s = q } ``` This code is a bit silly, but it's the smallest reproduction I have handy. :) When compiled, this code tests b, and on each branch it contains an LEAQ of `type.int`. The LEAQ should be hoisted above the branch, since it is needed immediately in each case, and there are registers to spare. The CSE pass does its work, and there is a single LEAQ instruction going into regalloc. However, early in regalloc, we decide to issue it every place we need it: ```go if s.values[v.ID].rematerializeable { // Value is rematerializeable, don't issue it here. // It will get issued just before each use (see // allocValueToReg). for _, a := range v.Args { a.Uses-- } s.advanceUses(v) continue } ``` This is usually the right decision--disabling this bit of code causes an overall regression. But as the initial code shows, there are instances in which it'd be better to issue the rematerializable value right away. I'm not sure exactly what the right set of conditions is, though. cc @cherrymui @randall77 ",0,cmd compile sometimes issue rematerializable values early go package p var s int b bool func f var q int if b q new int else q new int s q this code is a bit silly but it s the smallest reproduction i have handy when compiled this code tests b and on each branch it contains an leaq of type int the leaq should be hoisted above the branch since it is needed immediately in each case and there are registers to spare the cse pass does its work and there is a single leaq instruction going into regalloc however early in regalloc we decide to issue it every place we need it go if s values rematerializeable value is rematerializeable don t issue it here it will get issued just before each use see allocvaluetoreg for a range v args a uses s advanceuses v continue this is usually the right decision disabling this bit of code causes an overall regression but as the initial code shows there are instances in which it d be better to issue the rematerializable value right away i m not sure exactly what the right set of conditions is though cc cherrymui ,0 112830,9602942263.0,IssuesEvent,2019-05-10 15:44:04,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile/internal/ssa: TestNexting broken on longtest builder,NeedsInvestigation Soon Testing release-blocker,"https://build.golang.org/log/accd72f95cd2dcfb4da4bee9029543f35d626fd1: ``` --- FAIL: TestNexting (14.26s) --- FAIL: TestNexting/gdb-dbg-i22558 (0.97s) debug_test.go:242: step/next histories differ, diff= --- testdata/i22558.gdb-dbg.nexts 2019-04-03 21:27:05.000000000 +0000 +++ /workdir/tmp/debug_test870531445/test-i22558.gdb-dbg.nexts 2019-04-03 21:53:20.820874734 +0000 @@ -2,10 +2,3 @@ 19: func test(t *thing, u *thing) { 20: if t.next != nil { 23: fmt.Fprintf(os.Stderr, ""%s\n"", t.name) -24: u.self = u -25: t.self = t -26: t.next = u -27: for _, p := range t.stuff { -28: if isFoo(t, p) { -29: return -44: } ``` The first failure is at https://golang.org/cl/168479, but https://golang.org/cl/170639 seems like a more likely culprit. (CC @randall77 for both.)",1.0,"cmd/compile/internal/ssa: TestNexting broken on longtest builder - https://build.golang.org/log/accd72f95cd2dcfb4da4bee9029543f35d626fd1: ``` --- FAIL: TestNexting (14.26s) --- FAIL: TestNexting/gdb-dbg-i22558 (0.97s) debug_test.go:242: step/next histories differ, diff= --- testdata/i22558.gdb-dbg.nexts 2019-04-03 21:27:05.000000000 +0000 +++ /workdir/tmp/debug_test870531445/test-i22558.gdb-dbg.nexts 2019-04-03 21:53:20.820874734 +0000 @@ -2,10 +2,3 @@ 19: func test(t *thing, u *thing) { 20: if t.next != nil { 23: fmt.Fprintf(os.Stderr, ""%s\n"", t.name) -24: u.self = u -25: t.self = t -26: t.next = u -27: for _, p := range t.stuff { -28: if isFoo(t, p) { -29: return -44: } ``` The first failure is at https://golang.org/cl/168479, but https://golang.org/cl/170639 seems like a more likely culprit. (CC @randall77 for both.)",0,cmd compile internal ssa testnexting broken on longtest builder fail testnexting fail testnexting gdb dbg debug test go step next histories differ diff testdata gdb dbg nexts workdir tmp debug test gdb dbg nexts func test t thing u thing if t next nil fmt fprintf os stderr s n t name u self u t self t t next u for p range t stuff if isfoo t p return the first failure is at but seems like a more likely culprit cc for both ,0 319673,23785006807.0,IssuesEvent,2022-09-02 09:15:52,golang/go,https://api.github.com/repos/golang/go,closed,encoding/asn1: BitString.At wrong doc return type ,Documentation help wanted NeedsFix,"https://github.com/golang/go/blob/2882786bf4cd779f166e9ced82a4da2ea0f8b1f9/src/encoding/asn1/asn1.go#L164-L173 The doc comment says it returns false when it returns zero. (I'd submit a PR but the contributor process is too onerous for a one-liner like this.)",1.0,"encoding/asn1: BitString.At wrong doc return type - https://github.com/golang/go/blob/2882786bf4cd779f166e9ced82a4da2ea0f8b1f9/src/encoding/asn1/asn1.go#L164-L173 The doc comment says it returns false when it returns zero. (I'd submit a PR but the contributor process is too onerous for a one-liner like this.)",1,encoding bitstring at wrong doc return type the doc comment says it returns false when it returns zero i d submit a pr but the contributor process is too onerous for a one liner like this ,1 257542,22192774358.0,IssuesEvent,2022-06-07 02:03:00,golang/go,https://api.github.com/repos/golang/go,closed,x/net/http2: TestUnreadFlowControlReturned_Server failures due to INTERNAL_ERROR since 2022-03-15,Testing NeedsFix okay-after-beta1,"``` --- FAIL: TestUnreadFlowControlReturned_Server (16.39s) --- FAIL: TestUnreadFlowControlReturned_Server/body-closed (14.15s) server_test.go:3844: body-closed timedout server_test.go:3868: body-closed stream error: stream ID 5; INTERNAL_ERROR; received from peer FAIL FAIL golang.org/x/net/http2 184.809s ``` `greplogs --dashboard -md -l -e 'FAIL: TestUnreadFlowControlReturned_.*' --since=2022-01-01` [2022-03-30T02:16:17-de3da57-d1060d8/plan9-386-0intro](https://build.golang.org/log/64cdec817674cce288c0c5b13d5309baaefdcd74) [2022-03-25T01:24:44-27dd868-8ab42a9/plan9-386-0intro](https://build.golang.org/log/3671c250dd0cea8dd8de197f26641af86282accf) [2022-03-18T19:32:40-27dd868-a682a5c/plan9-386-0intro](https://build.golang.org/log/666994403b88c738695dac36b55ce967a12f5b18) [2022-03-18T16:57:07-27dd868-0a49f70/plan9-386-0intro](https://build.golang.org/log/1a81ef4d76665a89bdc5eddd5a444c002d8ba1a7) [2022-03-15T01:00:36-27dd868-44a0da4/plan9-386-0intro](https://build.golang.org/log/592c54d66100b2245e46fa21101c4deefc316443) (attn @0intro; CC @neild) See previously #49645.",1.0,"x/net/http2: TestUnreadFlowControlReturned_Server failures due to INTERNAL_ERROR since 2022-03-15 - ``` --- FAIL: TestUnreadFlowControlReturned_Server (16.39s) --- FAIL: TestUnreadFlowControlReturned_Server/body-closed (14.15s) server_test.go:3844: body-closed timedout server_test.go:3868: body-closed stream error: stream ID 5; INTERNAL_ERROR; received from peer FAIL FAIL golang.org/x/net/http2 184.809s ``` `greplogs --dashboard -md -l -e 'FAIL: TestUnreadFlowControlReturned_.*' --since=2022-01-01` [2022-03-30T02:16:17-de3da57-d1060d8/plan9-386-0intro](https://build.golang.org/log/64cdec817674cce288c0c5b13d5309baaefdcd74) [2022-03-25T01:24:44-27dd868-8ab42a9/plan9-386-0intro](https://build.golang.org/log/3671c250dd0cea8dd8de197f26641af86282accf) [2022-03-18T19:32:40-27dd868-a682a5c/plan9-386-0intro](https://build.golang.org/log/666994403b88c738695dac36b55ce967a12f5b18) [2022-03-18T16:57:07-27dd868-0a49f70/plan9-386-0intro](https://build.golang.org/log/1a81ef4d76665a89bdc5eddd5a444c002d8ba1a7) [2022-03-15T01:00:36-27dd868-44a0da4/plan9-386-0intro](https://build.golang.org/log/592c54d66100b2245e46fa21101c4deefc316443) (attn @0intro; CC @neild) See previously #49645.",0,x net testunreadflowcontrolreturned server failures due to internal error since fail testunreadflowcontrolreturned server fail testunreadflowcontrolreturned server body closed server test go body closed timedout server test go body closed stream error stream id internal error received from peer fail fail golang org x net greplogs dashboard md l e fail testunreadflowcontrolreturned since attn cc neild see previously ,0 14787,3886324190.0,IssuesEvent,2016-04-14 00:13:36,golang/go,https://api.github.com/repos/golang/go,closed,fmt: documentation unclear regarding %g precision formatting,Documentation,"Current go 1.5 documentation is not clear regarding the %g formatting. In particular, it states > For floating-point values, width sets the minimum width of the field and precision sets the number of places after the decimal, if appropriate, except that for %g/%G it sets the total number of digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5. The default precision for %e and %f is 6; for %g it is the smallest number of digits necessary to identify the value uniquely. This seems to imply that width for %g/%G is the total number of digits that will be outputted, while it is the number of significant digits, therefore leading zeroes does not contribute to the count. For example, formatting 0.001234 with %.3g will be printed without changes, 0.001234, while from the docs it seems that only 0.001 should be printed. I propose to change the documentation and change the following: > except that for %g/%G it sets the total number of digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5. with the following (bold used to mark the changes) > except that for %g/%G it sets the total number of **significant** digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5**, and 0.00123 is printed as 0.001 by %.3f, but printed as 0.00123 by %.3g**. Or with a better statement and/or example if the one I provided are not accurate enough.",1.0,"fmt: documentation unclear regarding %g precision formatting - Current go 1.5 documentation is not clear regarding the %g formatting. In particular, it states > For floating-point values, width sets the minimum width of the field and precision sets the number of places after the decimal, if appropriate, except that for %g/%G it sets the total number of digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5. The default precision for %e and %f is 6; for %g it is the smallest number of digits necessary to identify the value uniquely. This seems to imply that width for %g/%G is the total number of digits that will be outputted, while it is the number of significant digits, therefore leading zeroes does not contribute to the count. For example, formatting 0.001234 with %.3g will be printed without changes, 0.001234, while from the docs it seems that only 0.001 should be printed. I propose to change the documentation and change the following: > except that for %g/%G it sets the total number of digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5. with the following (bold used to mark the changes) > except that for %g/%G it sets the total number of **significant** digits. For example, given 123.45 the format %6.2f prints 123.45 while %.4g prints 123.5**, and 0.00123 is printed as 0.001 by %.3f, but printed as 0.00123 by %.3g**. Or with a better statement and/or example if the one I provided are not accurate enough.",1,fmt documentation unclear regarding g precision formatting current go documentation is not clear regarding the g formatting in particular it states for floating point values width sets the minimum width of the field and precision sets the number of places after the decimal if appropriate except that for g g it sets the total number of digits for example given the format prints while prints the default precision for e and f is for g it is the smallest number of digits necessary to identify the value uniquely this seems to imply that width for g g is the total number of digits that will be outputted while it is the number of significant digits therefore leading zeroes does not contribute to the count for example formatting with will be printed without changes while from the docs it seems that only should be printed i propose to change the documentation and change the following except that for g g it sets the total number of digits for example given the format prints while prints with the following bold used to mark the changes except that for g g it sets the total number of significant digits for example given the format prints while prints and is printed as by but printed as by or with a better statement and or example if the one i provided are not accurate enough ,1 208980,16167071285.0,IssuesEvent,2021-05-01 18:12:23,golang/go,https://api.github.com/repos/golang/go,opened,"go/types, go/constant: improve documentation on constant.Kind and relationship to concrete types",Documentation,"ISTM that go/types and go/constant don't currently do a good job at explaining which constant.Kind can be encountered in which contexts. For example, before seeing #43891 I wasn't aware that a floating point constant may have Kind() == Int. And while that issue explains that go/constant may use a more efficient representation, it doesn't mention if it may use a _less efficient_ representation, especially in relationship with the type checker. For example, in the following example ``` var foo func(int) const k = 4.0 _ = 1 << k foo(k) ``` it is not clear to me whether the types.TypeAndValue for the ast.Ident `k` as used in the bit shift and function call are guaranteed to be a constant.Int or not. It currently seems to be, and existing code in `vet` doesn't defensively use ToInt before using Uint64Val Summarizing, I'd like to see documentation that at least - mentions that constant kinds aren't directly related to concrete types - explains which simplifying guarantees go/types makes, if any - states how defensively code has to be written in practice /cc @griesemer ",1.0,"go/types, go/constant: improve documentation on constant.Kind and relationship to concrete types - ISTM that go/types and go/constant don't currently do a good job at explaining which constant.Kind can be encountered in which contexts. For example, before seeing #43891 I wasn't aware that a floating point constant may have Kind() == Int. And while that issue explains that go/constant may use a more efficient representation, it doesn't mention if it may use a _less efficient_ representation, especially in relationship with the type checker. For example, in the following example ``` var foo func(int) const k = 4.0 _ = 1 << k foo(k) ``` it is not clear to me whether the types.TypeAndValue for the ast.Ident `k` as used in the bit shift and function call are guaranteed to be a constant.Int or not. It currently seems to be, and existing code in `vet` doesn't defensively use ToInt before using Uint64Val Summarizing, I'd like to see documentation that at least - mentions that constant kinds aren't directly related to concrete types - explains which simplifying guarantees go/types makes, if any - states how defensively code has to be written in practice /cc @griesemer ",1,go types go constant improve documentation on constant kind and relationship to concrete types istm that go types and go constant don t currently do a good job at explaining which constant kind can be encountered in which contexts for example before seeing i wasn t aware that a floating point constant may have kind int and while that issue explains that go constant may use a more efficient representation it doesn t mention if it may use a less efficient representation especially in relationship with the type checker for example in the following example var foo func int const k k foo k it is not clear to me whether the types typeandvalue for the ast ident k as used in the bit shift and function call are guaranteed to be a constant int or not it currently seems to be and existing code in vet doesn t defensively use toint before using summarizing i d like to see documentation that at least mentions that constant kinds aren t directly related to concrete types explains which simplifying guarantees go types makes if any states how defensively code has to be written in practice cc griesemer ,1 109752,11648500779.0,IssuesEvent,2020-03-01 21:04:53,golang/go,https://api.github.com/repos/golang/go,closed,syscall/js: unclear behavior of js-triggered and wrapped functions,Arch-Wasm Documentation NeedsFix help wanted," ### What version of Go are you using (`go version`)? 
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/tschinke/Library/Caches/go-build""
GOENV=""/Users/tschinke/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/tschinke/go""
GOPRIVATE=""""
GOPROXY=""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/tschinke/repos/wdy_ausbildung/trainiety/app/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/bv/6rt5ck194ls704dz9p4c0hlh0000gn/T/go-build951955169=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? ```
var outerDiv js.Value = ... var innerDiv js.Value = ... outerDiv.Call(""addEventListener"", ""click"", js.FuncOf(func(this js.Value, args []js.Value) interface{} { log.Println(""listener called: "", this, this.Get(""id"")) return nil }), once) [...] innerDiv.Call(""addEventListener"", ""click"", js.FuncOf(func(this js.Value, args []js.Value) interface{} { args[0].Call(""stopPropagation"") log.Println(""listener called: "", this, this.Get(""id"")) return nil }), once) ``` ### What did you expect to see? Naturally I expected that the listener to the inner div should always be called first. However looking at the documentation of js.FuncOf, I don't know what to expect: > Invoking the JavaScript function will synchronously call the Go function fn with the value of JavaScript's ""this"" keyword and the arguments of the invocation. > [...] > A wrapped function triggered by JavaScript's event loop gets executed on an extra goroutine. > Blocking operations in the wrapped function will block the event loop. >[...] >A blocking function should therefore explicitly start a new goroutine. The logic of these statements is contradictory: * What exactly is meant by a ""synchronous call"" in the first statement? * If a wrapped and triggered function is always executed in a goroutine, why should it block the event loop? ### What did you see instead? I tried to use `stopPropagation` but the calling order is always wrong (outer-div first), independent of registration order. Also if a callback is always executed within a new goroutine, it sounds like `stopPropagation` et. al cannot be used properly. The documentation of js.FuncOf does not help me much to understand the actual calling behavior or at least if this works as ""expected"". ",1.0,"syscall/js: unclear behavior of js-triggered and wrapped functions - ### What version of Go are you using (`go version`)? 
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/tschinke/Library/Caches/go-build""
GOENV=""/Users/tschinke/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/tschinke/go""
GOPRIVATE=""""
GOPROXY=""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/tschinke/repos/wdy_ausbildung/trainiety/app/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/bv/6rt5ck194ls704dz9p4c0hlh0000gn/T/go-build951955169=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? ```
var outerDiv js.Value = ... var innerDiv js.Value = ... outerDiv.Call(""addEventListener"", ""click"", js.FuncOf(func(this js.Value, args []js.Value) interface{} { log.Println(""listener called: "", this, this.Get(""id"")) return nil }), once) [...] innerDiv.Call(""addEventListener"", ""click"", js.FuncOf(func(this js.Value, args []js.Value) interface{} { args[0].Call(""stopPropagation"") log.Println(""listener called: "", this, this.Get(""id"")) return nil }), once) ``` ### What did you expect to see? Naturally I expected that the listener to the inner div should always be called first. However looking at the documentation of js.FuncOf, I don't know what to expect: > Invoking the JavaScript function will synchronously call the Go function fn with the value of JavaScript's ""this"" keyword and the arguments of the invocation. > [...] > A wrapped function triggered by JavaScript's event loop gets executed on an extra goroutine. > Blocking operations in the wrapped function will block the event loop. >[...] >A blocking function should therefore explicitly start a new goroutine. The logic of these statements is contradictory: * What exactly is meant by a ""synchronous call"" in the first statement? * If a wrapped and triggered function is always executed in a goroutine, why should it block the event loop? ### What did you see instead? I tried to use `stopPropagation` but the calling order is always wrong (outer-div first), independent of registration order. Also if a callback is always executed within a new goroutine, it sounds like `stopPropagation` et. al cannot be used properly. The documentation of js.FuncOf does not help me much to understand the actual calling behavior or at least if this works as ""expected"". ",1,syscall js unclear behavior of js triggered and wrapped functions what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env on goarch gobin gocache users tschinke library caches go build goenv users tschinke library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users tschinke go goprivate goproxy direct goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users tschinke repos wdy ausbildung trainiety app go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders bv t go tmp go build gno record gcc switches fno common what did you do var outerdiv js value var innerdiv js value outerdiv call addeventlistener click js funcof func this js value args js value interface log println listener called this this get id return nil once innerdiv call addeventlistener click js funcof func this js value args js value interface args call stoppropagation log println listener called this this get id return nil once what did you expect to see naturally i expected that the listener to the inner div should always be called first however looking at the documentation of js funcof i don t know what to expect invoking the javascript function will synchronously call the go function fn with the value of javascript s this keyword and the arguments of the invocation a wrapped function triggered by javascript s event loop gets executed on an extra goroutine blocking operations in the wrapped function will block the event loop a blocking function should therefore explicitly start a new goroutine the logic of these statements is contradictory what exactly is meant by a synchronous call in the first statement if a wrapped and triggered function is always executed in a goroutine why should it block the event loop what did you see instead i tried to use stoppropagation but the calling order is always wrong outer div first independent of registration order also if a callback is always executed within a new goroutine it sounds like stoppropagation et al cannot be used properly the documentation of js funcof does not help me much to understand the actual calling behavior or at least if this works as expected ,1 86944,24993831697.0,IssuesEvent,2022-11-02 21:25:11,golang/go,https://api.github.com/repos/golang/go,closed,x/build: require TryBot-Result+1 or a new Ignore-TryBot label to submit CLs,Builders NeedsFix,"Once TryBots have failed on a CL, the open comment thread serves to remind people to make them pass before submitting. However, nothing reminds authors/reviewers to run them in the first place. This is particularly annoying if you need a second Googler +1 vote, since https://go.dev/s/needs-review requires a passing TryBot run. We can remind people that they need to run TryBots, and make it less likely that people will accidentally bypass them, by requiring an explicit vote from either an approver or the TryBots themselves for submission. Specifically, we would add a [submit requirement](https://gerrit-review.googlesource.com/Documentation/config-submit-requirements.html) like `label:TryBot-Result=+1 OR label:TryBot-Bypass=+1`. The name of the new label is up for bikeshedding. cc @golang/release ",1.0,"x/build: require TryBot-Result+1 or a new Ignore-TryBot label to submit CLs - Once TryBots have failed on a CL, the open comment thread serves to remind people to make them pass before submitting. However, nothing reminds authors/reviewers to run them in the first place. This is particularly annoying if you need a second Googler +1 vote, since https://go.dev/s/needs-review requires a passing TryBot run. We can remind people that they need to run TryBots, and make it less likely that people will accidentally bypass them, by requiring an explicit vote from either an approver or the TryBots themselves for submission. Specifically, we would add a [submit requirement](https://gerrit-review.googlesource.com/Documentation/config-submit-requirements.html) like `label:TryBot-Result=+1 OR label:TryBot-Bypass=+1`. The name of the new label is up for bikeshedding. cc @golang/release ",0,x build require trybot result or a new ignore trybot label to submit cls once trybots have failed on a cl the open comment thread serves to remind people to make them pass before submitting however nothing reminds authors reviewers to run them in the first place this is particularly annoying if you need a second googler vote since requires a passing trybot run we can remind people that they need to run trybots and make it less likely that people will accidentally bypass them by requiring an explicit vote from either an approver or the trybots themselves for submission specifically we would add a like label trybot result or label trybot bypass the name of the new label is up for bikeshedding cc golang release ,0 60854,8469455475.0,IssuesEvent,2018-10-23 23:04:42,golang/go,https://api.github.com/repos/golang/go,closed,"spec: don't use ""exception"" instead of ""panic""",Documentation NeedsFix,"When the [Spec](https://tip.golang.org/ref/spec#Integer_overflow) talks about integer overflow, there is this sentence: >(…) No *exception* is raised as a result of overflow. (…) Emphasis added. Go doesn't have exceptions, it has panics. I think this sentence should be rewritten to something like: >(…) Overflow does not trigger a run-time panic. (…) As far as I can see, the word ""exception"" meaning ""run-time error"" isn't used anywhere else in the Spec.",1.0,"spec: don't use ""exception"" instead of ""panic"" - When the [Spec](https://tip.golang.org/ref/spec#Integer_overflow) talks about integer overflow, there is this sentence: >(…) No *exception* is raised as a result of overflow. (…) Emphasis added. Go doesn't have exceptions, it has panics. I think this sentence should be rewritten to something like: >(…) Overflow does not trigger a run-time panic. (…) As far as I can see, the word ""exception"" meaning ""run-time error"" isn't used anywhere else in the Spec.",1,spec don t use exception instead of panic when the talks about integer overflow there is this sentence … no exception is raised as a result of overflow … emphasis added go doesn t have exceptions it has panics i think this sentence should be rewritten to something like … overflow does not trigger a run time panic … as far as i can see the word exception meaning run time error isn t used anywhere else in the spec ,1 57131,8141877906.0,IssuesEvent,2018-08-21 04:55:54,golang/go,https://api.github.com/repos/golang/go,closed,"net/http, security: http.FileServer may inadvertently expose sensitive directories",Documentation NeedsDecision Security,"The default `http.FileServer(http.Dir("".""))` implementation exposes all files and folders in the working directory. This includes directories like `.git` or `.svn`, which an attacker can use to recover the source code comprising the server, if for example people deploy by running a ""git clone"" and a ""go install."" This is how Heroku handles Go deployments and I am sure others do as well; it's common if you run Macs locally but deploy on Linux. This is not a hypothetical attack, one estimate found 9700 of the Alexa top 1 million sites expose the `.git` directory: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/ I am wondering whether the Go standard library should do anything to help prevent these inadvertent directory exposures. Our hands are slightly tied by the current API, which exposes everything and can't change. Some options: - Do nothing - Document the potential vulnerability and leave it at that. - Add `http.SafeDir` or similar, that 404's on any file beginning with a `.`. This should cover most private files, including `.htpasswd`. - Add `SafeDir` to httputil. - Modify `http.Dir` to exclude files that begin with a `.`. This would break backwards compatibility, and seems like a bad idea.",1.0,"net/http, security: http.FileServer may inadvertently expose sensitive directories - The default `http.FileServer(http.Dir("".""))` implementation exposes all files and folders in the working directory. This includes directories like `.git` or `.svn`, which an attacker can use to recover the source code comprising the server, if for example people deploy by running a ""git clone"" and a ""go install."" This is how Heroku handles Go deployments and I am sure others do as well; it's common if you run Macs locally but deploy on Linux. This is not a hypothetical attack, one estimate found 9700 of the Alexa top 1 million sites expose the `.git` directory: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/ I am wondering whether the Go standard library should do anything to help prevent these inadvertent directory exposures. Our hands are slightly tied by the current API, which exposes everything and can't change. Some options: - Do nothing - Document the potential vulnerability and leave it at that. - Add `http.SafeDir` or similar, that 404's on any file beginning with a `.`. This should cover most private files, including `.htpasswd`. - Add `SafeDir` to httputil. - Modify `http.Dir` to exclude files that begin with a `.`. This would break backwards compatibility, and seems like a bad idea.",1,net http security http fileserver may inadvertently expose sensitive directories the default http fileserver http dir implementation exposes all files and folders in the working directory this includes directories like git or svn which an attacker can use to recover the source code comprising the server if for example people deploy by running a git clone and a go install this is how heroku handles go deployments and i am sure others do as well it s common if you run macs locally but deploy on linux this is not a hypothetical attack one estimate found of the alexa top million sites expose the git directory i am wondering whether the go standard library should do anything to help prevent these inadvertent directory exposures our hands are slightly tied by the current api which exposes everything and can t change some options do nothing document the potential vulnerability and leave it at that add http safedir or similar that s on any file beginning with a this should cover most private files including htpasswd add safedir to httputil modify http dir to exclude files that begin with a this would break backwards compatibility and seems like a bad idea ,1 18314,4256240854.0,IssuesEvent,2016-07-10 00:36:24,golang/go,https://api.github.com/repos/golang/go,closed,fmt: define what %p means (or doesn't mean) on interfaces,Documentation,"(split from https://github.com/golang/go/issues/16230#issuecomment-231563421) What does %p mean in the `fmt` package for interface values? It seems to do something, but the documentation says nothing. /cc @josharian @robpike ",1.0,"fmt: define what %p means (or doesn't mean) on interfaces - (split from https://github.com/golang/go/issues/16230#issuecomment-231563421) What does %p mean in the `fmt` package for interface values? It seems to do something, but the documentation says nothing. /cc @josharian @robpike ",1,fmt define what p means or doesn t mean on interfaces split from what does p mean in the fmt package for interface values it seems to do something but the documentation says nothing cc josharian robpike ,1 318739,23737822591.0,IssuesEvent,2022-08-31 09:39:21,golang/go,https://api.github.com/repos/golang/go,closed,net/http/pprof: document all available default profiles,Documentation NeedsFix,"The docs at the moment only mention a few of the available profiles. See https://golang.org/pkg/net/http/pprof/ But there are plenty more: ``` var profileDescriptions = map[string]string{ ""allocs"": ""A sampling of all past memory allocations"", ""block"": ""Stack traces that led to blocking on synchronization primitives"", ""cmdline"": ""The command line invocation of the current program"", ""goroutine"": ""Stack traces of all current goroutines"", ""heap"": ""A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample."", ""mutex"": ""Stack traces of holders of contended mutexes"", ""profile"": ""CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile."", ""threadcreate"": ""Stack traces that led to the creation of new OS threads"", ""trace"": ""A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace."", } ``` Should also document the behaviour of the `""debug""` query parameter controlling the response content type.",1.0,"net/http/pprof: document all available default profiles - The docs at the moment only mention a few of the available profiles. See https://golang.org/pkg/net/http/pprof/ But there are plenty more: ``` var profileDescriptions = map[string]string{ ""allocs"": ""A sampling of all past memory allocations"", ""block"": ""Stack traces that led to blocking on synchronization primitives"", ""cmdline"": ""The command line invocation of the current program"", ""goroutine"": ""Stack traces of all current goroutines"", ""heap"": ""A sampling of memory allocations of live objects. You can specify the gc GET parameter to run GC before taking the heap sample."", ""mutex"": ""Stack traces of holders of contended mutexes"", ""profile"": ""CPU profile. You can specify the duration in the seconds GET parameter. After you get the profile file, use the go tool pprof command to investigate the profile."", ""threadcreate"": ""Stack traces that led to the creation of new OS threads"", ""trace"": ""A trace of execution of the current program. You can specify the duration in the seconds GET parameter. After you get the trace file, use the go tool trace command to investigate the trace."", } ``` Should also document the behaviour of the `""debug""` query parameter controlling the response content type.",1,net http pprof document all available default profiles the docs at the moment only mention a few of the available profiles see but there are plenty more var profiledescriptions map string allocs a sampling of all past memory allocations block stack traces that led to blocking on synchronization primitives cmdline the command line invocation of the current program goroutine stack traces of all current goroutines heap a sampling of memory allocations of live objects you can specify the gc get parameter to run gc before taking the heap sample mutex stack traces of holders of contended mutexes profile cpu profile you can specify the duration in the seconds get parameter after you get the profile file use the go tool pprof command to investigate the profile threadcreate stack traces that led to the creation of new os threads trace a trace of execution of the current program you can specify the duration in the seconds get parameter after you get the trace file use the go tool trace command to investigate the trace should also document the behaviour of the debug query parameter controlling the response content type ,1 287229,24816878749.0,IssuesEvent,2022-10-25 13:45:50,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: migrate tests from `vcs-test.golang.org` to a test-local server,Testing NeedsFix,"There are a few tests that rely on `vcs-test.golang.org`. Do we need to have these tests talk to a vcs server on the internet or can the tests just start this server themselves? If the server can be ran locally I would think that would be better than having them rely on the availability of `vcs-test.golang.org`. Follow up from: https://github.com/golang/go/issues/27127#issuecomment-417939775 cc/ @FiloSottile",1.0,"cmd/go: migrate tests from `vcs-test.golang.org` to a test-local server - There are a few tests that rely on `vcs-test.golang.org`. Do we need to have these tests talk to a vcs server on the internet or can the tests just start this server themselves? If the server can be ran locally I would think that would be better than having them rely on the availability of `vcs-test.golang.org`. Follow up from: https://github.com/golang/go/issues/27127#issuecomment-417939775 cc/ @FiloSottile",0,cmd go migrate tests from vcs test golang org to a test local server there are a few tests that rely on vcs test golang org do we need to have these tests talk to a vcs server on the internet or can the tests just start this server themselves if the server can be ran locally i would think that would be better than having them rely on the availability of vcs test golang org follow up from cc filosottile,0 108665,11597860719.0,IssuesEvent,2020-02-24 21:46:09,golang/go,https://api.github.com/repos/golang/go,closed,DocumentSymbols failed: getting file for DocumentSymbols: context canceled,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/Users/steele/go/bin""
GOCACHE=""/Users/steele/Library/Caches/go-build""
GOENV=""/Users/steele/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/steele/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/steele/conversion-service/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/m7/ks10ly_j20g2tphn554wvdcm0000gn/T/go-build947817871=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Loaded up my workspace after working in Python for a while only to notice that I wasn't getting any language server feedback anymore. Not sure if providing repo steps is possible... ### What did you expect to see? Language server works. ### What did you see instead? ``` [Info - 1:12:49 PM] 2020/02/24 13:12:49 go/packages.Load snapshot = 0 query = [./... builtin] packages = 2 2020/02/24 13:12:50 DocumentSymbols failed: getting file for DocumentSymbols: context canceled URI = file:///Users/steele/conversion-service/internal/svc/service.go 2020/02/24 13:12:50 : context canceled [Error - 1:12:50 PM] 2020/02/24 13:12:50 : context canceled ``` ",1.0,"DocumentSymbols failed: getting file for DocumentSymbols: context canceled - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/Users/steele/go/bin""
GOCACHE=""/Users/steele/Library/Caches/go-build""
GOENV=""/Users/steele/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/steele/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/steele/conversion-service/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/m7/ks10ly_j20g2tphn554wvdcm0000gn/T/go-build947817871=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Loaded up my workspace after working in Python for a while only to notice that I wasn't getting any language server feedback anymore. Not sure if providing repo steps is possible... ### What did you expect to see? Language server works. ### What did you see instead? ``` [Info - 1:12:49 PM] 2020/02/24 13:12:49 go/packages.Load snapshot = 0 query = [./... builtin] packages = 2 2020/02/24 13:12:50 DocumentSymbols failed: getting file for DocumentSymbols: context canceled URI = file:///Users/steele/conversion-service/internal/svc/service.go 2020/02/24 13:12:50 : context canceled [Error - 1:12:50 PM] 2020/02/24 13:12:50 : context canceled ``` ",1,documentsymbols failed getting file for documentsymbols context canceled please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin users steele go bin gocache users steele library caches go build goenv users steele library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users steele go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users steele conversion service go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do loaded up my workspace after working in python for a while only to notice that i wasn t getting any language server feedback anymore if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best not sure if providing repo steps is possible what did you expect to see language server works what did you see instead go packages load snapshot query packages documentsymbols failed getting file for documentsymbols context canceled uri file users steele conversion service internal svc service go context canceled context canceled ,1 8399,6536788621.0,IssuesEvent,2017-08-31 19:34:11,golang/go,https://api.github.com/repos/golang/go,closed,ioutil: ReadFile shouldn't ignore large sizes from Stat,Performance,"In Go 1.9, `io.ReadFile` checks the size of the underlying file and preallocates a buffer of that size. However, it [intentionally ignores](https://github.com/golang/go/blob/22cfe24aca80653b0e8efdd4a1aba1df00e8e72d/src/io/ioutil/ioutil.go#L59) sizes of 1GiB or larger: ```go if fi, err := f.Stat(); err == nil { // Don't preallocate a huge buffer, just in case. if size := fi.Size(); size < 1e9 { n = size } } ``` `ReadFile` then proceeds by reading into a `bytes.Buffer`, which [expands the buffer](https://github.com/golang/go/blob/22cfe24aca80653b0e8efdd4a1aba1df00e8e72d/src/bytes/buffer.go#L133) by powers of 2+𝜀: ```go // Not enough space anywhere, we need to allocate. buf := makeSlice(2*cap(b.buf) + n) copy(buf, b.buf[b.off:]) b.buf = buf ``` The combination of these two factors implies that calling `ioutil.ReadFile` on a file larger than 1GiB can sometimes waste an amount of memory equal to the size of the file: `ReadFile` is least efficient on the very files where efficiency has the biggest impact! It seems very odd to me to pessimize the behavior of `ReadFile` ""just in case"". If there are specific platforms and/or filesystems for which `Stat` dramatically over-reports file sizes, we should work around those specific platforms, but in the general case we should not ignore large sizes.",True,"ioutil: ReadFile shouldn't ignore large sizes from Stat - In Go 1.9, `io.ReadFile` checks the size of the underlying file and preallocates a buffer of that size. However, it [intentionally ignores](https://github.com/golang/go/blob/22cfe24aca80653b0e8efdd4a1aba1df00e8e72d/src/io/ioutil/ioutil.go#L59) sizes of 1GiB or larger: ```go if fi, err := f.Stat(); err == nil { // Don't preallocate a huge buffer, just in case. if size := fi.Size(); size < 1e9 { n = size } } ``` `ReadFile` then proceeds by reading into a `bytes.Buffer`, which [expands the buffer](https://github.com/golang/go/blob/22cfe24aca80653b0e8efdd4a1aba1df00e8e72d/src/bytes/buffer.go#L133) by powers of 2+𝜀: ```go // Not enough space anywhere, we need to allocate. buf := makeSlice(2*cap(b.buf) + n) copy(buf, b.buf[b.off:]) b.buf = buf ``` The combination of these two factors implies that calling `ioutil.ReadFile` on a file larger than 1GiB can sometimes waste an amount of memory equal to the size of the file: `ReadFile` is least efficient on the very files where efficiency has the biggest impact! It seems very odd to me to pessimize the behavior of `ReadFile` ""just in case"". If there are specific platforms and/or filesystems for which `Stat` dramatically over-reports file sizes, we should work around those specific platforms, but in the general case we should not ignore large sizes.",0,ioutil readfile shouldn t ignore large sizes from stat in go io readfile checks the size of the underlying file and preallocates a buffer of that size however it sizes of or larger go if fi err f stat err nil don t preallocate a huge buffer just in case if size fi size size n size readfile then proceeds by reading into a bytes buffer which by powers of 𝜀 go not enough space anywhere we need to allocate buf makeslice cap b buf n copy buf b buf b buf buf the combination of these two factors implies that calling ioutil readfile on a file larger than can sometimes waste an amount of memory equal to the size of the file readfile is least efficient on the very files where efficiency has the biggest impact it seems very odd to me to pessimize the behavior of readfile just in case if there are specific platforms and or filesystems for which stat dramatically over reports file sizes we should work around those specific platforms but in the general case we should not ignore large sizes ,0 74610,9793927779.0,IssuesEvent,2019-06-10 21:13:17,golang/go,https://api.github.com/repos/golang/go,closed,"doc: Effective Go contains a use of ""named type"", which is an obsoleted terminology.",Documentation NeedsDecision,"Should it be ""defined type"" instead? ",1.0,"doc: Effective Go contains a use of ""named type"", which is an obsoleted terminology. - Should it be ""defined type"" instead? ",1,doc effective go contains a use of named type which is an obsoleted terminology should it be defined type instead ,1 220873,16988194709.0,IssuesEvent,2021-06-30 16:44:53,golang/go,https://api.github.com/repos/golang/go,closed,os: example shows deprecated function,Documentation NeedsFix,"This is a documentation issue. One of the examples in the `os` packages shows the usage of the `IsNotExist` function; however, this function's documentation recommends avoiding it in new code: > This function predates errors.Is. It only supports errors returned by the os package. New code should use errors.Is(err, os.ErrNotExist). It seems like the example should be updated to demonstrate the new way of checking for this error instead. ",1.0,"os: example shows deprecated function - This is a documentation issue. One of the examples in the `os` packages shows the usage of the `IsNotExist` function; however, this function's documentation recommends avoiding it in new code: > This function predates errors.Is. It only supports errors returned by the os package. New code should use errors.Is(err, os.ErrNotExist). It seems like the example should be updated to demonstrate the new way of checking for this error instead. ",1,os example shows deprecated function this is a documentation issue one of the examples in the os packages shows the usage of the isnotexist function however this function s documentation recommends avoiding it in new code this function predates errors is it only supports errors returned by the os package new code should use errors is err os errnotexist it seems like the example should be updated to demonstrate the new way of checking for this error instead ,1 18359,4259810512.0,IssuesEvent,2016-07-11 12:29:15,golang/go,https://api.github.com/repos/golang/go,closed,text/template: improve documentation for creating templates,Documentation Suggested,"by **Shifter1**: 
http://play.golang.org/p/YfvMjcI7b5


Errors from that code are unhelpful, and the documentation for 
* http://golang.org/pkg/text/template/#New
* http://golang.org/pkg/text/template/#Template.ParseFiles


No mention is made in the docs that when using .New() and then .ParseFiles(), the
orginal temaplte's name needs to tbe the same as the base name of the first file.
",1.0,"text/template: improve documentation for creating templates - by **Shifter1**: 
http://play.golang.org/p/YfvMjcI7b5


Errors from that code are unhelpful, and the documentation for 
* http://golang.org/pkg/text/template/#New
* http://golang.org/pkg/text/template/#Template.ParseFiles


No mention is made in the docs that when using .New() and then .ParseFiles(), the
orginal temaplte's name needs to tbe the same as the base name of the first file.
",1,text template improve documentation for creating templates by a href errors from that code are unhelpful and the documentation for a href a href no mention is made in the docs that when using new and then parsefiles the orginal temaplte s name needs to tbe the same as the base name of the first file ,1 42459,22616125151.0,IssuesEvent,2022-06-29 22:20:37,golang/go,https://api.github.com/repos/golang/go,closed,go/token: AddFile induces heavy contention in parallel parsing [freeze exception],Performance NeedsFix release-blocker,"https://go-review.googlesource.com/c/go/+/411909 reduces two sources of contention in parser-heavy workloads: FileSet.AddFile allocates memory in the middle of an otherwise tiny critical section, and FileSet.Pos uses a mutex to guard a cache, turning read-only operations into exclusive locks. Both are major sources of contention in gopls. I'd like to include the fix in the next release. @golang/release @gri @findleyr ",True,"go/token: AddFile induces heavy contention in parallel parsing [freeze exception] - https://go-review.googlesource.com/c/go/+/411909 reduces two sources of contention in parser-heavy workloads: FileSet.AddFile allocates memory in the middle of an otherwise tiny critical section, and FileSet.Pos uses a mutex to guard a cache, turning read-only operations into exclusive locks. Both are major sources of contention in gopls. I'd like to include the fix in the next release. @golang/release @gri @findleyr ",0,go token addfile induces heavy contention in parallel parsing reduces two sources of contention in parser heavy workloads fileset addfile allocates memory in the middle of an otherwise tiny critical section and fileset pos uses a mutex to guard a cache turning read only operations into exclusive locks both are major sources of contention in gopls i d like to include the fix in the next release golang release gri findleyr ,0 52348,7759306146.0,IssuesEvent,2018-05-31 22:49:05,golang/go,https://api.github.com/repos/golang/go,closed,doc: archive/zip: *Writer.Close wording,Documentation NeedsInvestigation,"The documentation for *Writer.Close states: > Close finishes writing the zip file by writing the central directory. It does not (and cannot) close the underlying writer. The ""(and cannot)"" seems unnecessary, and differs from the docs of other Close methods in the standard library.",1.0,"doc: archive/zip: *Writer.Close wording - The documentation for *Writer.Close states: > Close finishes writing the zip file by writing the central directory. It does not (and cannot) close the underlying writer. The ""(and cannot)"" seems unnecessary, and differs from the docs of other Close methods in the standard library.",1,doc archive zip writer close wording the documentation for writer close states close finishes writing the zip file by writing the central directory it does not and cannot close the underlying writer the and cannot seems unnecessary and differs from the docs of other close methods in the standard library ,1 263631,19956732239.0,IssuesEvent,2022-01-28 00:45:22,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Effective Go needs to have a preamble re: generics,Documentation NeedsFix release-blocker,"[Effective Go](https://go.dev/doc/effective_go) needs to be updated with a preamble/disclaimer as it was not written with generics in mind. cc: @robpike ",1.0,"x/website: Effective Go needs to have a preamble re: generics - [Effective Go](https://go.dev/doc/effective_go) needs to be updated with a preamble/disclaimer as it was not written with generics in mind. cc: @robpike ",1,x website effective go needs to have a preamble re generics needs to be updated with a preamble disclaimer as it was not written with generics in mind cc robpike ,1 28246,5444462009.0,IssuesEvent,2017-03-07 02:53:38,golang/go,https://api.github.com/repos/golang/go,closed,encoding/base64: document that padchar cannot be multi-byte,Documentation,"### What version of Go are you using (`go version`)? Go 1.8 ### What did you expect to see? Looking at encoding/base64 we see that WithPadding accepts a rune: https://golang.org/pkg/encoding/base64/#Encoding.WithPadding Looking at the current implementation, the padding character can not be a multi-byte rune as the code compare bytes with padChar: https://github.com/golang/go/blob/87b1aaa37cefec8deacdf9c3c30d26015bdfb00b/src/encoding/base64/base64.go#L285 ### What did you see instead? I would like the documentation to be changed so it's explicit that we don't support multi-byte padding characters as I don't think it makes sense. ",1.0,"encoding/base64: document that padchar cannot be multi-byte - ### What version of Go are you using (`go version`)? Go 1.8 ### What did you expect to see? Looking at encoding/base64 we see that WithPadding accepts a rune: https://golang.org/pkg/encoding/base64/#Encoding.WithPadding Looking at the current implementation, the padding character can not be a multi-byte rune as the code compare bytes with padChar: https://github.com/golang/go/blob/87b1aaa37cefec8deacdf9c3c30d26015bdfb00b/src/encoding/base64/base64.go#L285 ### What did you see instead? I would like the documentation to be changed so it's explicit that we don't support multi-byte padding characters as I don't think it makes sense. ",1,encoding document that padchar cannot be multi byte what version of go are you using go version go what did you expect to see looking at encoding we see that withpadding accepts a rune looking at the current implementation the padding character can not be a multi byte rune as the code compare bytes with padchar what did you see instead i would like the documentation to be changed so it s explicit that we don t support multi byte padding characters as i don t think it makes sense ,1 72151,19043005898.0,IssuesEvent,2021-11-25 01:52:39,golang/go,https://api.github.com/repos/golang/go,closed,x/build: add a Windows ARM32 builder,Builders NeedsInvestigation new-builder,"Per https://github.com/golang/go/issues/42604#issuecomment-848870326 and https://github.com/golang/go/issues/42604#issuecomment-849186123, my builder will be decommissioned quite soon. This issue is to track spinning up of a builder on Google infrastructure, using the new ARM64 systems to run `GOOS=windows GOARCH=arm GOARM=7`. My builder was just running the 32-bit tests on the normal 64-bit OS. The replacement builder can do the same. There shouldn't be much work to do for this, as it's already been done for #42604. CC @toothrot @dmitshur @cagedmantis ",2.0,"x/build: add a Windows ARM32 builder - Per https://github.com/golang/go/issues/42604#issuecomment-848870326 and https://github.com/golang/go/issues/42604#issuecomment-849186123, my builder will be decommissioned quite soon. This issue is to track spinning up of a builder on Google infrastructure, using the new ARM64 systems to run `GOOS=windows GOARCH=arm GOARM=7`. My builder was just running the 32-bit tests on the normal 64-bit OS. The replacement builder can do the same. There shouldn't be much work to do for this, as it's already been done for #42604. CC @toothrot @dmitshur @cagedmantis ",0,x build add a windows builder per and my builder will be decommissioned quite soon this issue is to track spinning up of a builder on google infrastructure using the new systems to run goos windows goarch arm goarm my builder was just running the bit tests on the normal bit os the replacement builder can do the same there shouldn t be much work to do for this as it s already been done for cc toothrot dmitshur cagedmantis ,0 56909,8130483924.0,IssuesEvent,2018-08-17 18:39:14,golang/go,https://api.github.com/repos/golang/go,closed,doc: document go/build vs golang.org/x/tools/go/packages,Documentation NeedsFix release-blocker,"Per https://tip.golang.org/doc/go1.11#gopackages: > TODO: Note about go/build versus golang.org/x/tools/go/packages.",1.0,"doc: document go/build vs golang.org/x/tools/go/packages - Per https://tip.golang.org/doc/go1.11#gopackages: > TODO: Note about go/build versus golang.org/x/tools/go/packages.",1,doc document go build vs golang org x tools go packages per todo note about go build versus golang org x tools go packages ,1 335461,24469059360.0,IssuesEvent,2022-10-07 17:50:20,golang/go,https://api.github.com/repos/golang/go,closed,testing: add an example showcasing B.RunParallel with B.ReportMetric,Suggested Documentation NeedsFix,"I had a parallel benchmark in the form of: ``` var totalFoo int64 b.RunParallel(func(pb *testing.PB) { for pb.Next() { // benchmark... totalFoo += someFoo() } }) b.ReportMetric(float64(totalAmount)/float64(b.N), ""foo/op"") ``` I was taking a second look at the benchmark because dividing by `b.N` seemed fishy. This is a parallel benchmark, where I iterate via `pb.Next` and not `b.N`, so can I rely on `b.N` being an accurate detail of how many iterations were run across all goroutines? The docs seem to imply so: > RunParallel runs a benchmark in parallel. It creates multiple goroutines and distributes b.N iterations among them. > ReportMetric adds ""n unit"" to the reported benchmark results. If the metric is per-iteration, the caller should divide by b.N Still, I had to re-read the docs multiple times to convince myself. I think it would be nice to add an example on ReportMetric for parallel benchmarks, such as `func ExampleB_ReportMetric_parallel`, to help clarify the interaction between the two and how they are meant to be used. And there's another reason why an example would be good: since `RunParallel` hides the goroutine spawning from the user, it's relatively easy to introduce data races by mistake, like I did above! `totalFoo += someFoo()` would need to be something like `atomic.AddInt64(&totalFoo, someFoo())`. The example could also show that. Marking as a good candidate for first time contributors. Happy to review it too. cc @mpvl per https://dev.golang.org/owners",1.0,"testing: add an example showcasing B.RunParallel with B.ReportMetric - I had a parallel benchmark in the form of: ``` var totalFoo int64 b.RunParallel(func(pb *testing.PB) { for pb.Next() { // benchmark... totalFoo += someFoo() } }) b.ReportMetric(float64(totalAmount)/float64(b.N), ""foo/op"") ``` I was taking a second look at the benchmark because dividing by `b.N` seemed fishy. This is a parallel benchmark, where I iterate via `pb.Next` and not `b.N`, so can I rely on `b.N` being an accurate detail of how many iterations were run across all goroutines? The docs seem to imply so: > RunParallel runs a benchmark in parallel. It creates multiple goroutines and distributes b.N iterations among them. > ReportMetric adds ""n unit"" to the reported benchmark results. If the metric is per-iteration, the caller should divide by b.N Still, I had to re-read the docs multiple times to convince myself. I think it would be nice to add an example on ReportMetric for parallel benchmarks, such as `func ExampleB_ReportMetric_parallel`, to help clarify the interaction between the two and how they are meant to be used. And there's another reason why an example would be good: since `RunParallel` hides the goroutine spawning from the user, it's relatively easy to introduce data races by mistake, like I did above! `totalFoo += someFoo()` would need to be something like `atomic.AddInt64(&totalFoo, someFoo())`. The example could also show that. Marking as a good candidate for first time contributors. Happy to review it too. cc @mpvl per https://dev.golang.org/owners",1,testing add an example showcasing b runparallel with b reportmetric i had a parallel benchmark in the form of var totalfoo b runparallel func pb testing pb for pb next benchmark totalfoo somefoo b reportmetric totalamount b n foo op i was taking a second look at the benchmark because dividing by b n seemed fishy this is a parallel benchmark where i iterate via pb next and not b n so can i rely on b n being an accurate detail of how many iterations were run across all goroutines the docs seem to imply so runparallel runs a benchmark in parallel it creates multiple goroutines and distributes b n iterations among them reportmetric adds n unit to the reported benchmark results if the metric is per iteration the caller should divide by b n still i had to re read the docs multiple times to convince myself i think it would be nice to add an example on reportmetric for parallel benchmarks such as func exampleb reportmetric parallel to help clarify the interaction between the two and how they are meant to be used and there s another reason why an example would be good since runparallel hides the goroutine spawning from the user it s relatively easy to introduce data races by mistake like i did above totalfoo somefoo would need to be something like atomic totalfoo somefoo the example could also show that marking as a good candidate for first time contributors happy to review it too cc mpvl per ,1 3404,2762330882.0,IssuesEvent,2015-04-28 22:00:15,golang/go,https://api.github.com/repos/golang/go,closed,net/http: PostForm docs should mention PATCH method,Documentation,"The `net/http` parses the request body for the PATCH HTTP method [for quite some time now](https://codereview.appspot.com/70990044). I think the docs should mention that `PostForm` is available not only for POST and PUT but also for PATCH, that users don't need to dig into the code to discover that. gov1.4.1 ",1.0,"net/http: PostForm docs should mention PATCH method - The `net/http` parses the request body for the PATCH HTTP method [for quite some time now](https://codereview.appspot.com/70990044). I think the docs should mention that `PostForm` is available not only for POST and PUT but also for PATCH, that users don't need to dig into the code to discover that. gov1.4.1 ",1,net http postform docs should mention patch method the net http parses the request body for the patch http method i think the docs should mention that postform is available not only for post and put but also for patch that users don t need to dig into the code to discover that ,1 389619,26825754641.0,IssuesEvent,2023-02-02 12:46:02,golang/go,https://api.github.com/repos/golang/go,closed,go1.20: no docs for golang.org/x/crypto/x509roots/fallback,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20 darwin/arm64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""arm64""
GOBIN=""""
GOCACHE=""/Users/andig/Library/Caches/go-build""
GOENV=""/Users/andig/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""arm64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/andig/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/andig/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_arm64""
GOVCS=""""
GOVERSION=""go1.20""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/andig/htdocs/evcc/go.mod""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build1228287512=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.20 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.20
uname -v: Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103
ProductName:		macOS
ProductVersion:		13.1
BuildVersion:		22C65
lldb --version: lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
### What did you do? https://go.dev/doc/go1.20 mentions https://pkg.go.dev/crypto/x509#SetFallbackRoots and links https://go.dev/pkg/golang.org/x/crypto/x509roots/fallback. The link is dead afaikt and looking at https://pkg.go.dev/crypto I cannot find any reference to `x509roots`. ### What did you expect to see? Documentation for the https://go.dev/pkg/golang.org/x/crypto/x509roots/fallback package ### What did you see instead? No docs.",1.0,"go1.20: no docs for golang.org/x/crypto/x509roots/fallback - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20 darwin/arm64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""arm64""
GOBIN=""""
GOCACHE=""/Users/andig/Library/Caches/go-build""
GOENV=""/Users/andig/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""arm64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/andig/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/andig/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_arm64""
GOVCS=""""
GOVERSION=""go1.20""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/andig/htdocs/evcc/go.mod""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sv/rs_453y57xj86xsbz3kw1mbc0000gn/T/go-build1228287512=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.20 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.20
uname -v: Darwin Kernel Version 22.2.0: Fri Nov 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103
ProductName:		macOS
ProductVersion:		13.1
BuildVersion:		22C65
lldb --version: lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
### What did you do? https://go.dev/doc/go1.20 mentions https://pkg.go.dev/crypto/x509#SetFallbackRoots and links https://go.dev/pkg/golang.org/x/crypto/x509roots/fallback. The link is dead afaikt and looking at https://pkg.go.dev/crypto I cannot find any reference to `x509roots`. ### What did you expect to see? Documentation for the https://go.dev/pkg/golang.org/x/crypto/x509roots/fallback package ### What did you see instead? No docs.",1, no docs for golang org x crypto fallback what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users andig library caches go build goenv users andig library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users andig go pkg mod gonoproxy gonosumdb goos darwin gopath users andig go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users andig htdocs evcc go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders sv rs t go tmp go build gno record gcc switches fno common goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version fri nov pst root xnu release productname macos productversion buildversion lldb version lldb apple swift version swiftlang clang what did you do mentions and links the link is dead afaikt and looking at i cannot find any reference to what did you expect to see documentation for the package what did you see instead no docs ,1 103985,11387294431.0,IssuesEvent,2020-01-29 14:47:36,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.14: RISC-V status,Documentation NeedsFix arch-riscv,"

(I'm not sure if making issues about draft documents is allowed, so please feel free to close.)

https://tip.golang.org/doc/go1.14 doesn't seem to mention the new RISC-V port anywhere. AFAIK, the port will probably enter Go 1.14 in some way, even if highly experimental, so I think it needs to be documented.

",1.0,"doc/go1.14: RISC-V status -

(I'm not sure if making issues about draft documents is allowed, so please feel free to close.)

https://tip.golang.org/doc/go1.14 doesn't seem to mention the new RISC-V port anywhere. AFAIK, the port will probably enter Go 1.14 in some way, even if highly experimental, so I think it needs to be documented.

",1,doc risc v status i m not sure if making issues about draft documents is allowed so please feel free to close a href doesn t seem to mention the new risc v port anywhere afaik the port will probably enter go in some way even if highly experimental so i think it needs to be documented ,1 5883,5198995154.0,IssuesEvent,2017-01-23 19:39:51,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: 63% benchmark slowdown in 1.7 -> 1.8rc2,Performance,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? $ go version go version go1.7 darwin/amd64 $ go1.8rc2 version go version go1.8rc2 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/smansfield/gopkg"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.7/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.7/libexec/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f2/wwlcfvc5267dkl3c2_5_mcsw0000gp/T/go-build461692826=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ### 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. I have the disasm output for both 1.7 and 1.8 with a command to run benchtime 10s 1.7: https://play.golang.org/p/N04n8MwmS4 1.8: https://play.golang.org/p/sZpOz59PbS ### What did you expect to see? Approximately equal or better performance ### What did you see instead? Worse performance by far for 1.8, by 63% - 65% What's interesting in the 1.8 output is that the profiling shows a single MOVL taking 4.98 of the 9.37 seconds 4.98s 1144938: MOVL 0x30(SP), CX Unfortunately the code to do all this is private, but I might be able to extract an example if it's necessary. Right now I don't have one outside my project.",True,"cmd/compile: 63% benchmark slowdown in 1.7 -> 1.8rc2 - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? $ go version go version go1.7 darwin/amd64 $ go1.8rc2 version go version go1.8rc2 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/smansfield/gopkg"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.7/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.7/libexec/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f2/wwlcfvc5267dkl3c2_5_mcsw0000gp/T/go-build461692826=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ### 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. I have the disasm output for both 1.7 and 1.8 with a command to run benchtime 10s 1.7: https://play.golang.org/p/N04n8MwmS4 1.8: https://play.golang.org/p/sZpOz59PbS ### What did you expect to see? Approximately equal or better performance ### What did you see instead? Worse performance by far for 1.8, by 63% - 65% What's interesting in the 1.8 output is that the profiling shows a single MOVL taking 4.98 of the 9.37 seconds 4.98s 1144938: MOVL 0x30(SP), CX Unfortunately the code to do all this is private, but I might be able to extract an example if it's necessary. Right now I don't have one outside my project.",0,cmd compile benchmark slowdown in please answer these questions before submitting your issue thanks what version of go are you using go version go version go version darwin version go version darwin what operating system and processor architecture are you using go env go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users smansfield gopkg gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled 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 i have the disasm output for both and with a command to run benchtime what did you expect to see approximately equal or better performance what did you see instead worse performance by far for by what s interesting in the output is that the profiling shows a single movl taking of the seconds movl sp cx unfortunately the code to do all this is private but i might be able to extract an example if it s necessary right now i don t have one outside my project ,0 55370,7978387939.0,IssuesEvent,2018-07-17 18:09:41,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/godoc: show which version of Go introduced symbols,Documentation FeatureRequest NeedsFix help wanted,"

Go documentation is very good, but it doesn't clearly label which go version features
are available in.

For instance I was caught out by http://golang.org/pkg/time/#Timer.Reset being a go 1.1
feature which meant my code would no longer compile with go 1.0.

Other examples are 

  * http://golang.org/pkg/net/http/#Transport.CancelRequest
  * ResponseHeaderTimeout in http://golang.org/pkg/net/http/#Transport
",1.0,"x/tools/cmd/godoc: show which version of Go introduced symbols - 
Go documentation is very good, but it doesn't clearly label which go version features
are available in.

For instance I was caught out by http://golang.org/pkg/time/#Timer.Reset being a go 1.1
feature which meant my code would no longer compile with go 1.0.

Other examples are 

  * http://golang.org/pkg/net/http/#Transport.CancelRequest
  * ResponseHeaderTimeout in http://golang.org/pkg/net/http/#Transport
",1,x tools cmd godoc show which version of go introduced symbols go documentation is very good but it doesn t clearly label which go version features are available in for instance i was caught out by a href being a go feature which meant my code would no longer compile with go other examples are a href responseheadertimeout in a href ,1 246163,18837853004.0,IssuesEvent,2021-11-11 04:48:10,golang/go,https://api.github.com/repos/golang/go,closed,sync: clarify if it's valid to call Map methods inside the Map.Range callback,Documentation help wanted NeedsFix,"Map is documented as safe for concurrent use, so I understand it is safe to call a method like LoadAndDelete while Range is running in another goroutine, for example. However, what isn't clear is whether I can call a method like LoadAndDelete in Range's callback. Technically it's not a concurrent call, as it's happening on the same goroutine - it's just a nested call, as it happens within Range. Is that supported? From my reading of the code it seems like it shouldn't cause a data race. I wonder if it could lead to undesirable effects however, such as if I delete a key that I haven't ranged over yet, or if I keep adding more keys and potentially make the range run for a long time. I don't know what the answer is or what it should be, but I think the docs could be a bit clearer. cc @rsc @ianlancetaylor @dvyukov @aclements as per https://dev.golang.org/owners",1.0,"sync: clarify if it's valid to call Map methods inside the Map.Range callback - Map is documented as safe for concurrent use, so I understand it is safe to call a method like LoadAndDelete while Range is running in another goroutine, for example. However, what isn't clear is whether I can call a method like LoadAndDelete in Range's callback. Technically it's not a concurrent call, as it's happening on the same goroutine - it's just a nested call, as it happens within Range. Is that supported? From my reading of the code it seems like it shouldn't cause a data race. I wonder if it could lead to undesirable effects however, such as if I delete a key that I haven't ranged over yet, or if I keep adding more keys and potentially make the range run for a long time. I don't know what the answer is or what it should be, but I think the docs could be a bit clearer. cc @rsc @ianlancetaylor @dvyukov @aclements as per https://dev.golang.org/owners",1,sync clarify if it s valid to call map methods inside the map range callback map is documented as safe for concurrent use so i understand it is safe to call a method like loadanddelete while range is running in another goroutine for example however what isn t clear is whether i can call a method like loadanddelete in range s callback technically it s not a concurrent call as it s happening on the same goroutine it s just a nested call as it happens within range is that supported from my reading of the code it seems like it shouldn t cause a data race i wonder if it could lead to undesirable effects however such as if i delete a key that i haven t ranged over yet or if i keep adding more keys and potentially make the range run for a long time i don t know what the answer is or what it should be but i think the docs could be a bit clearer cc rsc ianlancetaylor dvyukov aclements as per ,1 212963,16505752816.0,IssuesEvent,2021-05-25 19:04:41,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document closure inlining affects function PC comparison,Documentation NeedsFix okay-after-beta1," ### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.17-d5d24dbe41 Mon Apr 26 17:13:36 2021 +0000 linux/amd64
### Does this issue reproduce with the latest release? only master ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
~/go/src/playground/at-2021-04-26-204402 $ ~/Code/go/bin/go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/rski/.cache/go-build""
GOENV=""/home/rski/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/rski/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""=""
GOOS=""linux""
GOPATH=""/home/rski/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/rski/Code/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/rski/Code/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.17-d5d24dbe41 Mon Apr 26 17:13:36 2021 +0000""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""0""
GOMOD=""/home/rski/go/src/playground/at-2021-04-26-204402/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2782832869=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://play.golang.org/p/Yw1lgRph4Kd ### What did you expect to see? This should print `main.WithFoo.func1`, as with go 16.3 ### What did you see instead? After the regabi branch merge, this prints main.init.func1 This was temporarily fixed by 1129a60f1c1e64147ca1133857c4571ce9b87a35, which disabled inlining of functions that contain closures. ",1.0,"doc/go1.17: document closure inlining affects function PC comparison - ### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.17-d5d24dbe41 Mon Apr 26 17:13:36 2021 +0000 linux/amd64
### Does this issue reproduce with the latest release? only master ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
~/go/src/playground/at-2021-04-26-204402 $ ~/Code/go/bin/go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/rski/.cache/go-build""
GOENV=""/home/rski/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/rski/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""=""
GOOS=""linux""
GOPATH=""/home/rski/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/rski/Code/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/rski/Code/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.17-d5d24dbe41 Mon Apr 26 17:13:36 2021 +0000""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""0""
GOMOD=""/home/rski/go/src/playground/at-2021-04-26-204402/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2782832869=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://play.golang.org/p/Yw1lgRph4Kd ### What did you expect to see? This should print `main.WithFoo.func1`, as with go 16.3 ### What did you see instead? After the regabi branch merge, this prints main.init.func1 This was temporarily fixed by 1129a60f1c1e64147ca1133857c4571ce9b87a35, which disabled inlining of functions that contain closures. ",1,doc document closure inlining affects function pc comparison please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version devel mon apr linux does this issue reproduce with the latest release only master what operating system and processor architecture are you using go env go env output go env go src playground at code go bin go env on goarch gobin gocache home rski cache go build goenv home rski config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home rski go pkg mod gonoproxy gonosumdb goos linux gopath home rski go goprivate goproxy goroot home rski code go gosumdb sum golang org gotmpdir gotooldir home rski code go pkg tool linux govcs goversion devel mon apr gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home rski go src playground at go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do what did you expect to see this should print main withfoo as with go what did you see instead after the regabi branch merge this prints main init this was temporarily fixed by which disabled inlining of functions that contain closures ,1 32667,6102267002.0,IssuesEvent,2017-06-20 16:08:08,golang/go,https://api.github.com/repos/golang/go,closed,doc: FAQ versioning question out of date,Documentation,https://golang.org/doc/faq#get_version mentions Go 1.5 and vendoring but not dep. It needs to be updated.,1.0,doc: FAQ versioning question out of date - https://golang.org/doc/faq#get_version mentions Go 1.5 and vendoring but not dep. It needs to be updated.,1,doc faq versioning question out of date mentions go and vendoring but not dep it needs to be updated ,1 250900,18911832750.0,IssuesEvent,2021-11-16 14:50:00,golang/go,https://api.github.com/repos/golang/go,closed,x/website: page showing .go source file under doc/articles has invalid link to documentation,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? not related $ go version ### Does this issue reproduce with the latest release? not related ### What operating system and processor architecture are you using (`go env`)? not related ### What did you do? I was reading the code example at the following article: https://golang.org/doc/articles/wiki/final.go the link included at the beggining of the site didn t work: the href at: 'Documentation: doc/articles/wiki' ### What did you expect to see? I expected to see the the link to move me to the page : I expected link to redirect me to: golang.org/doc/articles/wiki/ ### What did you see instead? it sends me to: https://golang.org/pkg/doc/articles/wiki/ which is not avaliable :/",1.0,"x/website: page showing .go source file under doc/articles has invalid link to documentation - ### What version of Go are you using (`go version`)? not related $ go version ### Does this issue reproduce with the latest release? not related ### What operating system and processor architecture are you using (`go env`)? not related ### What did you do? I was reading the code example at the following article: https://golang.org/doc/articles/wiki/final.go the link included at the beggining of the site didn t work: the href at: 'Documentation: doc/articles/wiki' ### What did you expect to see? I expected to see the the link to move me to the page : I expected link to redirect me to: golang.org/doc/articles/wiki/ ### What did you see instead? it sends me to: https://golang.org/pkg/doc/articles/wiki/ which is not avaliable :/",1,x website page showing go source file under doc articles has invalid link to documentation please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version not related go version does this issue reproduce with the latest release not related what operating system and processor architecture are you using go env not related what did you do i was reading the code example at the following article the link included at the beggining of the site didn t work the href at documentation doc articles wiki what did you expect to see i expected to see the the link to move me to the page i expected link to redirect me to golang org doc articles wiki what did you see instead it sends me to which is not avaliable ,1 238533,18244039867.0,IssuesEvent,2021-10-01 16:01:16,golang/go,https://api.github.com/repos/golang/go,closed,doc/modules/managing-dependencies: describe GOPRIVATE,Documentation NeedsFix,"https://golang.org/doc/modules/managing-dependencies currently describes how to set `GOPROXY` to a private module proxy. However, I expect that it is much more common for users to use the public proxy (proxy.golang.org) in conjunction with a few modules that are not publicly available. We have the [`GOPRIVATE`](https://golang.org/ref/mod#private-module-privacy) variable for that use-case, but a search of the “Managing dependencies” page doesn't currently turn up any hits for the word “private”. The Go Modules Reference page does describe `GOPRIVATE`, but that's probably presented at a lower level than most users would prefer. (See https://stackoverflow.com/q/65639718 for an example of a user who could benefit from such documentation.) CC @jayconrod @matloob @stevetraut ",1.0,"doc/modules/managing-dependencies: describe GOPRIVATE - https://golang.org/doc/modules/managing-dependencies currently describes how to set `GOPROXY` to a private module proxy. However, I expect that it is much more common for users to use the public proxy (proxy.golang.org) in conjunction with a few modules that are not publicly available. We have the [`GOPRIVATE`](https://golang.org/ref/mod#private-module-privacy) variable for that use-case, but a search of the “Managing dependencies” page doesn't currently turn up any hits for the word “private”. The Go Modules Reference page does describe `GOPRIVATE`, but that's probably presented at a lower level than most users would prefer. (See https://stackoverflow.com/q/65639718 for an example of a user who could benefit from such documentation.) CC @jayconrod @matloob @stevetraut ",1,doc modules managing dependencies describe goprivate currently describes how to set goproxy to a private module proxy however i expect that it is much more common for users to use the public proxy proxy golang org in conjunction with a few modules that are not publicly available we have the variable for that use case but a search of the “managing dependencies” page doesn t currently turn up any hits for the word “private” the go modules reference page does describe goprivate but that s probably presented at a lower level than most users would prefer see for an example of a user who could benefit from such documentation cc jayconrod matloob stevetraut ,1 58180,8233632943.0,IssuesEvent,2018-09-08 03:27:50,golang/go,https://api.github.com/repos/golang/go,closed,doc/effective_go.html: select is not mentioned in control structures section,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? N/A , see https://golang.org/doc/effective_go.html#control-structures ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? opened effective go and searched for `select` ### What did you expect to see? documentation about the nuances and patterns of usage for select: * Frequently used within a ""while loop"" (`for {`) ```go for { select { case o := <-one: fmt.Println(""one"", o) case o := <- two: fmt.Println(""two"", o) } } ``` * Chooses at random if multiple available ```go one := make(chan bool) two := make(chan int) go func() { one <- true } go func() { two <- 13 } select { case o := <- one: fmt.Println(""one"", o) case o := <- two: fmt.Println(""two"", o) } // Output: will randomly output either ""one true"" or ""two 13"" ``` * timeout pattern: https://gobyexample.com/timeouts * wait for N channels to close pattern: https://stackoverflow.com/a/13666733/1114274 personally, i prefer: ```go for o != nil && e != nil { select { case i, ok := <-o: if !ok { o = nil } fmt.Println(""o"", i) case i, ok := <-e: if !ok { e = nil } fmt.Println(""e"", i) } } ``` ### What did you see instead? only one example in ""Leaky Buffer"" section? https://golang.org/doc/effective_go.html#leaky_buffer ",1.0,"doc/effective_go.html: select is not mentioned in control structures section - ### What version of Go are you using (`go version`)? N/A , see https://golang.org/doc/effective_go.html#control-structures ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? opened effective go and searched for `select` ### What did you expect to see? documentation about the nuances and patterns of usage for select: * Frequently used within a ""while loop"" (`for {`) ```go for { select { case o := <-one: fmt.Println(""one"", o) case o := <- two: fmt.Println(""two"", o) } } ``` * Chooses at random if multiple available ```go one := make(chan bool) two := make(chan int) go func() { one <- true } go func() { two <- 13 } select { case o := <- one: fmt.Println(""one"", o) case o := <- two: fmt.Println(""two"", o) } // Output: will randomly output either ""one true"" or ""two 13"" ``` * timeout pattern: https://gobyexample.com/timeouts * wait for N channels to close pattern: https://stackoverflow.com/a/13666733/1114274 personally, i prefer: ```go for o != nil && e != nil { select { case i, ok := <-o: if !ok { o = nil } fmt.Println(""o"", i) case i, ok := <-e: if !ok { e = nil } fmt.Println(""e"", i) } } ``` ### What did you see instead? only one example in ""Leaky Buffer"" section? https://golang.org/doc/effective_go.html#leaky_buffer ",1,doc effective go html select is not mentioned in control structures section what version of go are you using go version n a see does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env n a what did you do opened effective go and searched for select what did you expect to see documentation about the nuances and patterns of usage for select frequently used within a while loop for go for select case o one fmt println one o case o two fmt println two o chooses at random if multiple available go one make chan bool two make chan int go func one true go func two select case o one fmt println one o case o two fmt println two o output will randomly output either one true or two timeout pattern wait for n channels to close pattern personally i prefer go for o nil e nil select case i ok o if ok o nil fmt println o i case i ok e if ok e nil fmt println e i what did you see instead only one example in leaky buffer section ,1 32817,6122530265.0,IssuesEvent,2017-06-23 00:10:31,golang/go,https://api.github.com/repos/golang/go,closed,net: Is net.IP.IsUnspecified() not specific enough?,Documentation,"### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 But it's been this way for a long time. ### What operating system and processor architecture are you using (`go env`)? darwin_amd64 but all architectures. ### What did you do? Called net.IP.IsUnspecified() with an unassigned net.IP struct If possible, provide a recipe for reproducing the error. https://play.golang.org/p/GHc6PatP8i ### What did you expect to see? I expect any net.IP struct that does not contain a valid ipv4 or ipv6 address to be ""unspecified"". ### What did you see instead? IP structs that are neither ipv4 or ipv6 are accepted as ""specified"". I think IsUnspecified() should check that the IP is a valid v4 or v6 length before testing against their respective zero values. The playground link show an implementation of IsUnspecified() that I think has more precise semantics.",1.0,"net: Is net.IP.IsUnspecified() not specific enough? - ### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 But it's been this way for a long time. ### What operating system and processor architecture are you using (`go env`)? darwin_amd64 but all architectures. ### What did you do? Called net.IP.IsUnspecified() with an unassigned net.IP struct If possible, provide a recipe for reproducing the error. https://play.golang.org/p/GHc6PatP8i ### What did you expect to see? I expect any net.IP struct that does not contain a valid ipv4 or ipv6 address to be ""unspecified"". ### What did you see instead? IP structs that are neither ipv4 or ipv6 are accepted as ""specified"". I think IsUnspecified() should check that the IP is a valid v4 or v6 length before testing against their respective zero values. The playground link show an implementation of IsUnspecified() that I think has more precise semantics.",1,net is net ip isunspecified not specific enough what version of go are you using go version go version darwin but it s been this way for a long time what operating system and processor architecture are you using go env darwin but all architectures what did you do called net ip isunspecified with an unassigned net ip struct if possible provide a recipe for reproducing the error what did you expect to see i expect any net ip struct that does not contain a valid or address to be unspecified what did you see instead ip structs that are neither or are accepted as specified i think isunspecified should check that the ip is a valid or length before testing against their respective zero values the playground link show an implementation of isunspecified that i think has more precise semantics ,1 53961,13233848499.0,IssuesEvent,2020-08-18 15:23:08,golang/go,https://api.github.com/repos/golang/go,closed,x/build: add Amazon EC2 ARM instances for builders,Builders NeedsInvestigation,"As @bradfitz noted, we should explore adding ephemeral AWS ARM instances for both 32-bit and 64-bit ARM builds. @toothrot @dmitshur ",1.0,"x/build: add Amazon EC2 ARM instances for builders - As @bradfitz noted, we should explore adding ephemeral AWS ARM instances for both 32-bit and 64-bit ARM builds. @toothrot @dmitshur ",0,x build add amazon arm instances for builders as bradfitz noted we should explore adding ephemeral aws arm instances for both bit and bit arm builds toothrot dmitshur ,0 408180,27656655398.0,IssuesEvent,2023-03-12 02:27:00,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: mention `go get` in `go help mod`,Documentation help wanted NeedsFix GoCommand," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16
### Does this issue reproduce with the latest release? Yes ### What did you do? I were working with a module using command `go mod`; i expected that i can update dependency with commands: `go mod update -u ` `go mod update @commit` ### What did you expect to see? I expected for this to work. I expected for this to show in `go help mod`: ```` Usage: go mod [arguments] The commands are: download download modules to local cache edit edit go.mod from tools or scripts graph print module requirement graph init initialize new module in current directory tidy add missing and remove unused modules vendor make vendored copy of dependencies verify verify dependencies have expected content why explain why packages or modules are needed ```` ### What did you see instead? After asking a question regarding this topic on golang slack channel i received help from `Tim Heckman` that stated: ```` yeah, the choice was made to keep it as go get so all the existing Gophers wouldn't need to relearn the command(s). ```` ```` yeah, that was kept for historical purposes... that was how dependencies have always been gotten. ```` He nicely explained to me that i have to use: ```` go get @commit go get -u ```` Which for me is confusing - i expected that subcommand to be related to `go mod` but - it's not in the help of that command - while it's clearly related to modules.",1.0,"cmd/go: mention `go get` in `go help mod` - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16
### Does this issue reproduce with the latest release? Yes ### What did you do? I were working with a module using command `go mod`; i expected that i can update dependency with commands: `go mod update -u ` `go mod update @commit` ### What did you expect to see? I expected for this to work. I expected for this to show in `go help mod`: ```` Usage: go mod [arguments] The commands are: download download modules to local cache edit edit go.mod from tools or scripts graph print module requirement graph init initialize new module in current directory tidy add missing and remove unused modules vendor make vendored copy of dependencies verify verify dependencies have expected content why explain why packages or modules are needed ```` ### What did you see instead? After asking a question regarding this topic on golang slack channel i received help from `Tim Heckman` that stated: ```` yeah, the choice was made to keep it as go get so all the existing Gophers wouldn't need to relearn the command(s). ```` ```` yeah, that was kept for historical purposes... that was how dependencies have always been gotten. ```` He nicely explained to me that i have to use: ```` go get @commit go get -u ```` Which for me is confusing - i expected that subcommand to be related to `go mod` but - it's not in the help of that command - while it's clearly related to modules.",1,cmd go mention go get in go help mod please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version does this issue reproduce with the latest release yes what did you do i were working with a module using command go mod i expected that i can update dependency with commands go mod update u go mod update commit what did you expect to see i expected for this to work i expected for this to show in go help mod usage go mod the commands are download download modules to local cache edit edit go mod from tools or scripts graph print module requirement graph init initialize new module in current directory tidy add missing and remove unused modules vendor make vendored copy of dependencies verify verify dependencies have expected content why explain why packages or modules are needed what did you see instead after asking a question regarding this topic on golang slack channel i received help from tim heckman that stated yeah the choice was made to keep it as go get so all the existing gophers wouldn t need to relearn the command s yeah that was kept for historical purposes that was how dependencies have always been gotten he nicely explained to me that i have to use go get commit go get u which for me is confusing i expected that subcommand to be related to go mod but it s not in the help of that command while it s clearly related to modules ,1 189718,15193903713.0,IssuesEvent,2021-02-16 02:04:31,golang/go,https://api.github.com/repos/golang/go,closed,x/website: update /doc/install/source page after GO386 changes,Documentation NeedsFix early-in-cycle release-blocker,"The [Installing Go from source](https://tip.golang.org/doc/install/source#environment) page says (in the section dedicated to Env Variables): > $GO386 (for 386 only, default is auto-detected if built on either 386 or amd64, 387 otherwise) > > This controls the code generated by gc to use either the 387 floating-point unit (set to 387) or SSE2 instructions (set to sse2) for floating point computations. > - GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later). > - GO386=sse2: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later. The section should be updated to reflect the planned 1.16 deprecation of 387, and the softfloat support. cc @dmitshur ",1.0,"x/website: update /doc/install/source page after GO386 changes - The [Installing Go from source](https://tip.golang.org/doc/install/source#environment) page says (in the section dedicated to Env Variables): > $GO386 (for 386 only, default is auto-detected if built on either 386 or amd64, 387 otherwise) > > This controls the code generated by gc to use either the 387 floating-point unit (set to 387) or SSE2 instructions (set to sse2) for floating point computations. > - GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later). > - GO386=sse2: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later. The section should be updated to reflect the planned 1.16 deprecation of 387, and the softfloat support. cc @dmitshur ",1,x website update doc install source page after changes the page says in the section dedicated to env variables for only default is auto detected if built on either or otherwise this controls the code generated by gc to use either the floating point unit set to or instructions set to for floating point computations use for floating point operations should support all chips pentium mmx or later use for floating point operations has better performance than but only available on pentium opteron athlon or later the section should be updated to reflect the planned deprecation of and the softfloat support cc dmitshur ,1 32069,6028917795.0,IssuesEvent,2017-06-08 16:46:45,golang/go,https://api.github.com/repos/golang/go,closed,spec: clarify restrictions on RHS of non-constant shifts,Documentation,"The spec says (https://golang.org/ref/spec#Operators): > The right operand in a shift expression must have unsigned integer type or be an untyped constant > that can be converted to unsigned integer type. All of go, gotype and gccgo seem to allow any unsigned type as the right operand. However, if the right operand is untyped, all of them seem to try to convert the operand specifically to `uint`, as opposed to, say, trying to find some unsigned integer type, capable of representing the value. ``` Go package main const A0 uint64 = 0xffffffff + 1 const A1 = 0xffffffff const A2 = 0xffffffff + 1 var B, C uint64 func main() { C = B << A0 C = B << A1 C = B << A2 // error } ``` If this is the intended behavior, then the spec should look like: > The right operand in a shift expression must have unsigned integer type or be an untyped constant > that can be converted to `uint`. ",1.0,"spec: clarify restrictions on RHS of non-constant shifts - The spec says (https://golang.org/ref/spec#Operators): > The right operand in a shift expression must have unsigned integer type or be an untyped constant > that can be converted to unsigned integer type. All of go, gotype and gccgo seem to allow any unsigned type as the right operand. However, if the right operand is untyped, all of them seem to try to convert the operand specifically to `uint`, as opposed to, say, trying to find some unsigned integer type, capable of representing the value. ``` Go package main const A0 uint64 = 0xffffffff + 1 const A1 = 0xffffffff const A2 = 0xffffffff + 1 var B, C uint64 func main() { C = B << A0 C = B << A1 C = B << A2 // error } ``` If this is the intended behavior, then the spec should look like: > The right operand in a shift expression must have unsigned integer type or be an untyped constant > that can be converted to `uint`. ",1,spec clarify restrictions on rhs of non constant shifts the spec says the right operand in a shift expression must have unsigned integer type or be an untyped constant that can be converted to unsigned integer type all of go gotype and gccgo seem to allow any unsigned type as the right operand however if the right operand is untyped all of them seem to try to convert the operand specifically to uint as opposed to say trying to find some unsigned integer type capable of representing the value go package main const const const var b c func main c b c b c b error if this is the intended behavior then the spec should look like the right operand in a shift expression must have unsigned integer type or be an untyped constant that can be converted to uint ,1 241757,20159817704.0,IssuesEvent,2022-02-09 20:12:50,golang/go,https://api.github.com/repos/golang/go,closed,net: TestLookupContextCancel failure with nil-error conversion panic on windows-arm64-10,Testing NeedsFix,"``` --- FAIL: TestLookupContextCancel (0.00s) panic: interface conversion: error is nil, not *net.DNSError [recovered] panic: interface conversion: error is nil, not *net.DNSError goroutine 185 [running]: panic({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/runtime/panic.go:941 +0x3d8 fp=0x400006db50 sp=0x400006da90 pc=0x7ff6c67b6658 testing.tRunner.func1.2({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/testing/testing.go:1389 +0x1c8 fp=0x400006dc00 sp=0x400006db50 pc=0x7ff6c68651d8 testing.tRunner.func1() C:/workdir/go/src/testing/testing.go:1392 +0x380 fp=0x400006dd70 sp=0x400006dc00 pc=0x7ff6c6864d40 runtime.deferCallSave(0x400006de50, 0x40000c9f88?) C:/workdir/go/src/runtime/panic.go:750 +0x94 fp=0x400006dd80 sp=0x400006dd70 pc=0x7ff6c67b6224 runtime.runOpenDeferFrame(0x4000064050?, 0x4000064000) C:/workdir/go/src/runtime/panic.go:723 +0x1b8 fp=0x400006ddd0 sp=0x400006dd80 pc=0x7ff6c67b6048 panic({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/runtime/panic.go:838 +0x20c fp=0x400006de90 sp=0x400006ddd0 pc=0x7ff6c67b648c runtime.panicdottypeE(...) C:/workdir/go/src/runtime/iface.go:262 runtime.panicdottypeI(0x7ff6c6b33900?, 0x7ff6c697a2c0, 0x7ff6c6978340) C:/workdir/go/src/runtime/iface.go:272 +0x78 fp=0x400006dec0 sp=0x400006de90 pc=0x7ff6c6789618 net.TestLookupContextCancel(0x40001a4ea0) C:/workdir/go/src/net/lookup_test.go:891 +0x230 fp=0x400006df60 sp=0x400006dec0 pc=0x7ff6c69031b0 testing.tRunner(0x40001a4ea0, 0x7ff6c69bd7a0) C:/workdir/go/src/testing/testing.go:1439 +0x110 fp=0x400006dfb0 sp=0x400006df60 pc=0x7ff6c68648f0 testing.(*T).Run.func1() C:/workdir/go/src/testing/testing.go:1486 +0x30 fp=0x400006dfd0 sp=0x400006dfb0 pc=0x7ff6c6865660 runtime.goexit() C:/workdir/go/src/runtime/asm_arm64.s:1259 +0x4 fp=0x400006dfd0 sp=0x400006dfd0 pc=0x7ff6c67e62b4 created by testing.(*T).Run C:/workdir/go/src/testing/testing.go:1486 +0x328 ``` `greplogs --dashboard -md -l -e 'FAIL: TestLookupContextCancel .*\npanic: interface conversion'` [2022-02-08T08:41:09-c856fbf/windows-arm64-10](https://build.golang.org/log/4c72c3aee2190398e0393cacc50de821aa0c4585)",1.0,"net: TestLookupContextCancel failure with nil-error conversion panic on windows-arm64-10 - ``` --- FAIL: TestLookupContextCancel (0.00s) panic: interface conversion: error is nil, not *net.DNSError [recovered] panic: interface conversion: error is nil, not *net.DNSError goroutine 185 [running]: panic({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/runtime/panic.go:941 +0x3d8 fp=0x400006db50 sp=0x400006da90 pc=0x7ff6c67b6658 testing.tRunner.func1.2({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/testing/testing.go:1389 +0x1c8 fp=0x400006dc00 sp=0x400006db50 pc=0x7ff6c68651d8 testing.tRunner.func1() C:/workdir/go/src/testing/testing.go:1392 +0x380 fp=0x400006dd70 sp=0x400006dc00 pc=0x7ff6c6864d40 runtime.deferCallSave(0x400006de50, 0x40000c9f88?) C:/workdir/go/src/runtime/panic.go:750 +0x94 fp=0x400006dd80 sp=0x400006dd70 pc=0x7ff6c67b6224 runtime.runOpenDeferFrame(0x4000064050?, 0x4000064000) C:/workdir/go/src/runtime/panic.go:723 +0x1b8 fp=0x400006ddd0 sp=0x400006dd80 pc=0x7ff6c67b6048 panic({0x7ff6c6976fa0, 0x4000257920}) C:/workdir/go/src/runtime/panic.go:838 +0x20c fp=0x400006de90 sp=0x400006ddd0 pc=0x7ff6c67b648c runtime.panicdottypeE(...) C:/workdir/go/src/runtime/iface.go:262 runtime.panicdottypeI(0x7ff6c6b33900?, 0x7ff6c697a2c0, 0x7ff6c6978340) C:/workdir/go/src/runtime/iface.go:272 +0x78 fp=0x400006dec0 sp=0x400006de90 pc=0x7ff6c6789618 net.TestLookupContextCancel(0x40001a4ea0) C:/workdir/go/src/net/lookup_test.go:891 +0x230 fp=0x400006df60 sp=0x400006dec0 pc=0x7ff6c69031b0 testing.tRunner(0x40001a4ea0, 0x7ff6c69bd7a0) C:/workdir/go/src/testing/testing.go:1439 +0x110 fp=0x400006dfb0 sp=0x400006df60 pc=0x7ff6c68648f0 testing.(*T).Run.func1() C:/workdir/go/src/testing/testing.go:1486 +0x30 fp=0x400006dfd0 sp=0x400006dfb0 pc=0x7ff6c6865660 runtime.goexit() C:/workdir/go/src/runtime/asm_arm64.s:1259 +0x4 fp=0x400006dfd0 sp=0x400006dfd0 pc=0x7ff6c67e62b4 created by testing.(*T).Run C:/workdir/go/src/testing/testing.go:1486 +0x328 ``` `greplogs --dashboard -md -l -e 'FAIL: TestLookupContextCancel .*\npanic: interface conversion'` [2022-02-08T08:41:09-c856fbf/windows-arm64-10](https://build.golang.org/log/4c72c3aee2190398e0393cacc50de821aa0c4585)",0,net testlookupcontextcancel failure with nil error conversion panic on windows fail testlookupcontextcancel panic interface conversion error is nil not net dnserror panic interface conversion error is nil not net dnserror goroutine panic c workdir go src runtime panic go fp sp pc testing trunner c workdir go src testing testing go fp sp pc testing trunner c workdir go src testing testing go fp sp pc runtime defercallsave c workdir go src runtime panic go fp sp pc runtime runopendeferframe c workdir go src runtime panic go fp sp pc panic c workdir go src runtime panic go fp sp pc runtime panicdottypee c workdir go src runtime iface go runtime panicdottypei c workdir go src runtime iface go fp sp pc net testlookupcontextcancel c workdir go src net lookup test go fp sp pc testing trunner c workdir go src testing testing go fp sp pc testing t run c workdir go src testing testing go fp sp pc runtime goexit c workdir go src runtime asm s fp sp pc created by testing t run c workdir go src testing testing go greplogs dashboard md l e fail testlookupcontextcancel npanic interface conversion ,0 5768,5154883240.0,IssuesEvent,2017-01-15 05:12:12,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: statically initialize compute-only data,Performance,"Consider the LUT: ```go var ReverseLUT = []byte{ 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8, 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8, 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4, 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4, 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec, 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc, 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2, 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2, 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea, 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa, 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6, 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6, 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee, 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe, 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1, 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1, 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9, 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9, 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5, 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5, 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed, 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd, 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3, 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3, 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb, 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb, 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7, 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7, 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff, } ``` This could represented with the compute-only function: ```go var ReverseLUT = func() (lut [256]byte) { for i := range lut { b := uint8(i) b = (b&0xaa)>>1 | (b&0x55)<<1 b = (b&0xcc)>>2 | (b&0x33)<<2 b = (b&0xf0)>>4 | (b&0x0f)<<4 lut[i] = b } return lut }() ``` For functions that are compute only at initialization, we could consider pre-computing their value at compilation time and statically assigning the resulting in the compiled binary (assuming the space-complexity is a better trade-off compared to the time-complexity). While the above example is somewhat trivial, it is helpful for more complex LUTs. For example, this commit 5c78589b69c87f25a4792d9c8a1446294c07600e removed a more complex LUT for huffman decoding and perform the LUT computation at runtime. It was annoying keeping two separate huffman decoder implementations in sync along with using code-generation to create the LUT. It would have been nice to just do: ```go var fixedHuffmanDecoder = func() (d huffmanDecoder) { var bits [288]int for i := 0; i < 144; i++ { bits[i] = 8 } for i := 144; i < 256; i++ { bits[i] = 9 } for i := 256; i < 280; i++ { bits[i] = 7 } for i := 280; i < 288; i++ { bits[i] = 8 } d.init(bits[:]) return }() ```",True,"cmd/compile: statically initialize compute-only data - Consider the LUT: ```go var ReverseLUT = []byte{ 0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0, 0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8, 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8, 0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4, 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4, 0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec, 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc, 0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2, 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2, 0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea, 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa, 0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6, 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6, 0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee, 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe, 0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1, 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1, 0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9, 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9, 0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5, 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5, 0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed, 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd, 0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3, 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3, 0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb, 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb, 0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7, 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7, 0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff, } ``` This could represented with the compute-only function: ```go var ReverseLUT = func() (lut [256]byte) { for i := range lut { b := uint8(i) b = (b&0xaa)>>1 | (b&0x55)<<1 b = (b&0xcc)>>2 | (b&0x33)<<2 b = (b&0xf0)>>4 | (b&0x0f)<<4 lut[i] = b } return lut }() ``` For functions that are compute only at initialization, we could consider pre-computing their value at compilation time and statically assigning the resulting in the compiled binary (assuming the space-complexity is a better trade-off compared to the time-complexity). While the above example is somewhat trivial, it is helpful for more complex LUTs. For example, this commit 5c78589b69c87f25a4792d9c8a1446294c07600e removed a more complex LUT for huffman decoding and perform the LUT computation at runtime. It was annoying keeping two separate huffman decoder implementations in sync along with using code-generation to create the LUT. It would have been nice to just do: ```go var fixedHuffmanDecoder = func() (d huffmanDecoder) { var bits [288]int for i := 0; i < 144; i++ { bits[i] = 8 } for i := 144; i < 256; i++ { bits[i] = 9 } for i := 256; i < 280; i++ { bits[i] = 7 } for i := 280; i < 288; i++ { bits[i] = 8 } d.init(bits[:]) return }() ```",0,cmd compile statically initialize compute only data consider the lut go var reverselut byte this could represented with the compute only function go var reverselut func lut byte for i range lut b i b b b b b b b b b lut b return lut for functions that are compute only at initialization we could consider pre computing their value at compilation time and statically assigning the resulting in the compiled binary assuming the space complexity is a better trade off compared to the time complexity while the above example is somewhat trivial it is helpful for more complex luts for example this commit removed a more complex lut for huffman decoding and perform the lut computation at runtime it was annoying keeping two separate huffman decoder implementations in sync along with using code generation to create the lut it would have been nice to just do go var fixedhuffmandecoder func d huffmandecoder var bits int for i i i bits for i i i bits for i i i bits for i i i bits d init bits return ,0 15290,3940752474.0,IssuesEvent,2016-04-27 02:59:17,golang/go,https://api.github.com/repos/golang/go,closed,context: typo in documentation,Documentation,"In the documentation: ``` // func Stream(ctx context.Context, out <-chan Value) error { // for { // v, err := DoSomething(ctx) // if err != nil { // return err // } // select { // case <-ctx.Done(): // return ctx.Err() // case out <- v: // } // } // } ``` `out <-chan Value` should be replaced by `out chan<- Value` There is the same typo in `golang.org/x/net/context`",1.0,"context: typo in documentation - In the documentation: ``` // func Stream(ctx context.Context, out <-chan Value) error { // for { // v, err := DoSomething(ctx) // if err != nil { // return err // } // select { // case <-ctx.Done(): // return ctx.Err() // case out <- v: // } // } // } ``` `out <-chan Value` should be replaced by `out chan<- Value` There is the same typo in `golang.org/x/net/context`",1,context typo in documentation in the documentation func stream ctx context context out chan value error for v err dosomething ctx if err nil return err select case ctx done return ctx err case out v out chan value should be replaced by out chan value there is the same typo in golang org x net context ,1 48768,7457047745.0,IssuesEvent,2018-03-30 01:28:03,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: docs: document that main packages cannot be imported,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.9 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/elliott/me/projects/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build792066057=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? A non-main package cannot import a main package. I discovered this when importing my main package by its canonical name, `github.com/e-beach/main-package-example`, in a test package. I also believe that main packages _can_ import other main packages, but did not test that here. See https://github.com/e-beach/main-package-example for an example. See https://groups.google.com/forum/#!topic/Golang-nuts/frh9zQPEjUk for the discussion that gave birth to the issue. ### What did you expect to see? I expected `cd test && go test` to pass without error. ### What did you see instead? ``` # github.com/e-beach/main-package-example/test main_test.go:4:2: import ""github.com/e-beach/main-package-example"" is a program, not an importable package FAIL github.com/e-beach/main-package-example/test [setup failed] ``` This behavior is reasonable, but is not in the spec and should be documented. ",1.0,"cmd/go: docs: document that main packages cannot be imported - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.9 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/elliott/me/projects/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build792066057=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? A non-main package cannot import a main package. I discovered this when importing my main package by its canonical name, `github.com/e-beach/main-package-example`, in a test package. I also believe that main packages _can_ import other main packages, but did not test that here. See https://github.com/e-beach/main-package-example for an example. See https://groups.google.com/forum/#!topic/Golang-nuts/frh9zQPEjUk for the discussion that gave birth to the issue. ### What did you expect to see? I expected `cd test && go test` to pass without error. ### What did you see instead? ``` # github.com/e-beach/main-package-example/test main_test.go:4:2: import ""github.com/e-beach/main-package-example"" is a program, not an importable package FAIL github.com/e-beach/main-package-example/test [setup failed] ``` This behavior is reasonable, but is not in the spec and should be documented. ",1,cmd go docs document that main packages cannot be imported please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath home elliott me projects go gorace goroot usr local go gotooldir usr local go pkg tool linux gccgo gccgo cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do a non main package cannot import a main package i discovered this when importing my main package by its canonical name github com e beach main package example in a test package i also believe that main packages can import other main packages but did not test that here see for an example see for the discussion that gave birth to the issue what did you expect to see i expected cd test go test to pass without error what did you see instead github com e beach main package example test main test go import github com e beach main package example is a program not an importable package fail github com e beach main package example test this behavior is reasonable but is not in the spec and should be documented ,1 132580,12512274061.0,IssuesEvent,2020-06-02 22:21:24,golang/go,https://api.github.com/repos/golang/go,closed,time: document that RFC3339 accepts invalid formats when used with Parse,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? It reproduces on play.golang.org and the underlying issue is still present in the source. ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? Parsed a faulty ISO 8601 string with a single-digit hour using `time.RFC3339`. E.g. `2020-02-02T2:02:02Z`. ### What did you expect to see? I expected this parse to error because [RFC-3339 sec 5.6](https://tools.ietf.org/html/rfc3339#section-5.6) defines the following token, requiring two digits for the hour: ``` time-hour = 2DIGIT ; 00-23 ``` ### What did you see instead? The parse succeeded. This could be fixed by changing `time.RFC3339` to `2006-01-02T03:04:05Z07:00`. If this is deemed a backward incompatible change, adding a new `time.RFC3339Strict` constant would also be an acceptable option. See https://play.golang.org/p/6qyFYfx6pMr for example with one and two-digit years with `time.Parse3339` and the stricter version.",1.0,"time: document that RFC3339 accepts invalid formats when used with Parse - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? It reproduces on play.golang.org and the underlying issue is still present in the source. ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? Parsed a faulty ISO 8601 string with a single-digit hour using `time.RFC3339`. E.g. `2020-02-02T2:02:02Z`. ### What did you expect to see? I expected this parse to error because [RFC-3339 sec 5.6](https://tools.ietf.org/html/rfc3339#section-5.6) defines the following token, requiring two digits for the hour: ``` time-hour = 2DIGIT ; 00-23 ``` ### What did you see instead? The parse succeeded. This could be fixed by changing `time.RFC3339` to `2006-01-02T03:04:05Z07:00`. If this is deemed a backward incompatible change, adding a new `time.RFC3339Strict` constant would also be an acceptable option. See https://play.golang.org/p/6qyFYfx6pMr for example with one and two-digit years with `time.Parse3339` and the stricter version.",1,time document that accepts invalid formats when used with parse please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release it reproduces on play golang org and the underlying issue is still present in the source what operating system and processor architecture are you using go env darwin what did you do parsed a faulty iso string with a single digit hour using time e g what did you expect to see i expected this parse to error because defines the following token requiring two digits for the hour time hour what did you see instead the parse succeeded this could be fixed by changing time to if this is deemed a backward incompatible change adding a new time constant would also be an acceptable option see for example with one and two digit years with time and the stricter version ,1 174243,13463579481.0,IssuesEvent,2020-09-09 17:49:33,golang/go,https://api.github.com/repos/golang/go,closed,"runtime: ""fatal error: unexpected signal during runtime execution"" on windows-amd64-longtest builder of Go 1.15.2 commit",NeedsFix Testing,"We've observed the following failure during `runtime` tests on a `windows-amd64-longtest` slowbot on a commit for the upcoming Go 1.15.2: ``` fatal error: unexpected signal during runtime execution [signal 0xc0000005 code=0x0 addr=0x0 pc=0x12efa46] runtime stack: runtime.throw(0x151e8d7, 0x2a) C:/workdir/go/src/runtime/panic.go:1116 +0x79 fp=0xc0709ff8f8 sp=0xc0709ff8c8 pc=0x12bc659 runtime.sigpanic() C:/workdir/go/src/runtime/signal_windows.go:240 +0x285 fp=0xc0709ff928 sp=0xc0709ff8f8 pc=0x12d1745 runtime.(*pageAlloc).chunkOf(...) C:/workdir/go/src/runtime/mpagealloc.go:331 runtime.CheckScavengedBitsCleared.func1() C:/workdir/go/src/runtime/export_test.go:905 +0x186 fp=0xc0709ff960 sp=0xc0709ff928 pc=0x12efa46 runtime.systemstack(0x0) C:/workdir/go/src/runtime/asm_amd64.s:370 +0x6b fp=0xc0709ff968 sp=0xc0709ff960 pc=0x12f4e0b runtime.mstart() C:/workdir/go/src/runtime/proc.go:1116 fp=0xc0709ff970 sp=0xc0709ff968 pc=0x12c18e0 goroutine 20213428 [running]: runtime.systemstack_switch() C:/workdir/go/src/runtime/asm_amd64.s:330 fp=0xc0001a92c0 sp=0xc0001a92b8 pc=0x12f4d80 [...] FAIL runtime 143.911s ``` See [here](https://go-review.googlesource.com/c/go/+/253717/1#message-c1837523011ceb181c0cfff0399db6db44352946) for more context and the complete build log. The `windows-amd64-longtest` slowbot passed all tests on the second try, so this failure is intermittent. It doesn't seem to happen often, but it may be connected to (or the same as) issues #41285, #41099. I've tried running `go test -timeout=0 -count=5 runtime` on a machine with Windows 10, and it passed. We should see if there's any useful information in this particular instance, and if not, this issue can probably be closed as a duplicate. /cc @randall77 @ianlancetaylor @toothrot @andybons ",1.0,"runtime: ""fatal error: unexpected signal during runtime execution"" on windows-amd64-longtest builder of Go 1.15.2 commit - We've observed the following failure during `runtime` tests on a `windows-amd64-longtest` slowbot on a commit for the upcoming Go 1.15.2: ``` fatal error: unexpected signal during runtime execution [signal 0xc0000005 code=0x0 addr=0x0 pc=0x12efa46] runtime stack: runtime.throw(0x151e8d7, 0x2a) C:/workdir/go/src/runtime/panic.go:1116 +0x79 fp=0xc0709ff8f8 sp=0xc0709ff8c8 pc=0x12bc659 runtime.sigpanic() C:/workdir/go/src/runtime/signal_windows.go:240 +0x285 fp=0xc0709ff928 sp=0xc0709ff8f8 pc=0x12d1745 runtime.(*pageAlloc).chunkOf(...) C:/workdir/go/src/runtime/mpagealloc.go:331 runtime.CheckScavengedBitsCleared.func1() C:/workdir/go/src/runtime/export_test.go:905 +0x186 fp=0xc0709ff960 sp=0xc0709ff928 pc=0x12efa46 runtime.systemstack(0x0) C:/workdir/go/src/runtime/asm_amd64.s:370 +0x6b fp=0xc0709ff968 sp=0xc0709ff960 pc=0x12f4e0b runtime.mstart() C:/workdir/go/src/runtime/proc.go:1116 fp=0xc0709ff970 sp=0xc0709ff968 pc=0x12c18e0 goroutine 20213428 [running]: runtime.systemstack_switch() C:/workdir/go/src/runtime/asm_amd64.s:330 fp=0xc0001a92c0 sp=0xc0001a92b8 pc=0x12f4d80 [...] FAIL runtime 143.911s ``` See [here](https://go-review.googlesource.com/c/go/+/253717/1#message-c1837523011ceb181c0cfff0399db6db44352946) for more context and the complete build log. The `windows-amd64-longtest` slowbot passed all tests on the second try, so this failure is intermittent. It doesn't seem to happen often, but it may be connected to (or the same as) issues #41285, #41099. I've tried running `go test -timeout=0 -count=5 runtime` on a machine with Windows 10, and it passed. We should see if there's any useful information in this particular instance, and if not, this issue can probably be closed as a duplicate. /cc @randall77 @ianlancetaylor @toothrot @andybons ",0,runtime fatal error unexpected signal during runtime execution on windows longtest builder of go commit we ve observed the following failure during runtime tests on a windows longtest slowbot on a commit for the upcoming go fatal error unexpected signal during runtime execution runtime stack runtime throw c workdir go src runtime panic go fp sp pc runtime sigpanic c workdir go src runtime signal windows go fp sp pc runtime pagealloc chunkof c workdir go src runtime mpagealloc go runtime checkscavengedbitscleared c workdir go src runtime export test go fp sp pc runtime systemstack c workdir go src runtime asm s fp sp pc runtime mstart c workdir go src runtime proc go fp sp pc goroutine runtime systemstack switch c workdir go src runtime asm s fp sp pc fail runtime see for more context and the complete build log the windows longtest slowbot passed all tests on the second try so this failure is intermittent it doesn t seem to happen often but it may be connected to or the same as issues i ve tried running go test timeout count runtime on a machine with windows and it passed we should see if there s any useful information in this particular instance and if not this issue can probably be closed as a duplicate cc ianlancetaylor toothrot andybons ,0 33152,6160113552.0,IssuesEvent,2017-06-29 03:29:53,golang/go,https://api.github.com/repos/golang/go,closed,time: RFC3339Nano does not guarantee natural ordering,Documentation,"Hi! When the time.Time used in Format(time.RFC3339Nano) is rounded to the nearest second (or anything lower than nanosecond), any trailing 0s are not formatted due to the formatting string. RFC3339Nano should format to a natural/string sortable value. This is mentioned in section 5.1 of RFC3339 https://www.ietf.org/rfc/rfc3339.txt ``` 5.1. Ordering If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all ""Z"" or all ""+00:00""), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result. The presence of optional punctuation would violate this characteristic. ``` I propose that time.RFC3339Nano is updated to the following formatting string: `""2006-01-02T15:04:05.000000000Z07:00""` or that a time.RFC3339NanoNatural (or similar) constant is declared thanks for your time! ### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/alex/dev/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l5/x43qw4sd10j_459gxsy9h3j80000gn/T/go-build164235018=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? I formatted two time.Time values using RFC3339Nano https://play.golang.org/p/qY81JM6Np8 ### What did you expect to see? ``` Hello, playground 2009-11-10T23:00:00.00000000Z 2009-11-10T23:00:00.00000001Z ``` ### What did you see instead? ``` Hello, playground 2009-11-10T23:00:00Z 2009-11-10T23:00:00.00000001Z ``` ",1.0,"time: RFC3339Nano does not guarantee natural ordering - Hi! When the time.Time used in Format(time.RFC3339Nano) is rounded to the nearest second (or anything lower than nanosecond), any trailing 0s are not formatted due to the formatting string. RFC3339Nano should format to a natural/string sortable value. This is mentioned in section 5.1 of RFC3339 https://www.ietf.org/rfc/rfc3339.txt ``` 5.1. Ordering If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all ""Z"" or all ""+00:00""), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result. The presence of optional punctuation would violate this characteristic. ``` I propose that time.RFC3339Nano is updated to the following formatting string: `""2006-01-02T15:04:05.000000000Z07:00""` or that a time.RFC3339NanoNatural (or similar) constant is declared thanks for your time! ### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/alex/dev/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l5/x43qw4sd10j_459gxsy9h3j80000gn/T/go-build164235018=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? I formatted two time.Time values using RFC3339Nano https://play.golang.org/p/qY81JM6Np8 ### What did you expect to see? ``` Hello, playground 2009-11-10T23:00:00.00000000Z 2009-11-10T23:00:00.00000001Z ``` ### What did you see instead? ``` Hello, playground 2009-11-10T23:00:00Z 2009-11-10T23:00:00.00000001Z ``` ",1,time does not guarantee natural ordering hi when the time time used in format time is rounded to the nearest second or anything lower than nanosecond any trailing are not formatted due to the formatting string should format to a natural string sortable value this is mentioned in section of ordering if date and time components are ordered from least precise to most precise then a useful property is achieved assuming that the time zones of the dates and times are the same e g all in utc expressed using the same string e g all z or all and all times have the same number of fractional second digits then the date and time strings may be sorted as strings e g using the strcmp function in c and a time ordered sequence will result the presence of optional punctuation would violate this characteristic i propose that time is updated to the following formatting string or that a time or similar constant is declared thanks for your time what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users alex dev go gorace goroot usr local go gotooldir usr local go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do i formatted two time time values using what did you expect to see hello playground what did you see instead hello playground ,1 327587,24143862200.0,IssuesEvent,2022-09-21 16:55:50,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: index out of range while trying to run textDocument/codeAction on entire document,Documentation gopls Tools," ### gopls version ``` Build info ---------- golang.org/x/tools/gopls master golang.org/x/tools/gopls@(devel) github.com/BurntSushi/toml@v1.2.0 h1:Rt8g24XnyGTyglgET/PRUNlrUeu9F5L+7FilkXfZgs0= github.com/google/go-cmp@v0.5.8 h1:e6P7q2lk1O+qJJb4BtCQXlK8vWEO8V1ZeuEdJNOqZyg= github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= golang.org/x/exp@v0.0.0-20220722155223-a9213eeb770e h1:+WEEuIdZHnUeJJmEUjyYC2gfUMj69yZXw17EnHg/otA= golang.org/x/exp/typeparams@v0.0.0-20220722155223-a9213eeb770e h1:7Xs2YCOpMlNqSQSmrrnhlzBXIE/bpMecZplbLePTJvE= golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s= golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4 h1:uVc8UZUe6tr40fFVnUP5Oj+veunVezqYl9z7DYw9xzw= golang.org/x/sys@v0.0.0-20220808155132-1c4a2a72c664 h1:v1W7bwXHsnLLloWYTVEdvGvA7BHMeBYsPcF0GLDxIRs= golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk= golang.org/x/tools@v0.1.13-0.20220810174125-0ad49fdeb955 => ../ golang.org/x/vuln@v0.0.0-20220919155316-41b1fc70d0a6 h1:tQFrcJZ95V1wiLLPoAIaEuEVXJ7JkhbZI4Hws7Fx69c= honnef.co/go/tools@v0.3.3 h1:oDx7VAwstgpYpb3wv0oxiZlxY+foCpRAwY7Vk6XpAgA= mvdan.cc/gofumpt@v0.3.1 h1:avhhrOmv0IuvQVK7fvwV91oFSGAk5/6Po8GXTzICeu8= mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc= go: devel go1.20-d11c58eedb Wed Sep 21 01:56:24 2022 +0000 ``` ### go env ``` ％ go env GO111MODULE="""" GOARCH=""arm64"" GOBIN=""/Users/fsouza/bin"" GOCACHE=""/Users/fsouza/Library/Caches/go-build"" GOENV=""/Users/fsouza/Library/Application Support/go/env"" GOEXE="""" GOEXPERIMENT="""" GOFLAGS=""-modcacherw"" GOHOSTARCH=""arm64"" GOHOSTOS=""darwin"" GOINSECURE="""" GOMODCACHE=""/Users/fsouza/.cache/go/path/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""darwin"" GOPATH=""/Users/fsouza/.cache/go/path"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/Users/fsouza/.cache/go/sdk/gotip"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/Users/fsouza/.cache/go/sdk/gotip/pkg/tool/darwin_arm64"" GOVCS="""" GOVERSION=""devel go1.20-d11c58eedb Wed Sep 21 01:56:24 2022 +0000"" GCCGO=""gccgo"" AR=""ar"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD=""/Users/fsouza/Projects/os/p/fake-gcs-server/go.mod"" GOWORK="""" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOGCCFLAGS=""-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rz/8d0l4yp51sd3jh9f34x7pkg80000gn/T/go-build3810227374=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? Invoke `textDocument/codeAction` passing a range that covers the entire file (following the [spec for range](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#range), which means that the end position is exclusive). Here's what the range I'm sending looks like (in JSON-ish): ```json { ... other fields ""range"": { ""start"": { ""line"": 0, ""character"": 0 }, ""end"": { ""line"": $N, ""character"": 0 } } } ``` Where `$N` = number of lines in the file. For full reproduction steps, see ""Editor & Settings"" below. ### What did you expect to see? The list of code actions available in the entire file. ### What did you see instead? gopls panics with an index out of range. Since this is a panic, the stacktrace isn't available in the logs for gopls, but I'm able to get the process output from my editor's logs: ``` [ERROR][2022-09-21 09:02:06] .../vim/lsp/rpc.lua:733 ""rpc"" ""/Users/fsouza/.cache/nvim/langservers/bin/gopls"" ""stderr"" ""panic: runtime error: index out of range [2] with length 2\n\ngoroutine 8707 [running]:\ngolang.org/x/tools/gopls/internal/lsp/source.adjustRangeForCommentsAndWhiteSpace({0x140038d9380?, 0x69?, 0x1?}, 0x140038d9380, {0x14001dea000, 0xbc7, 0x140000f4640?}, 0x1400370b400)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:704 +0x3e0\ngolang.org/x/tools/gopls/internal/lsp/source.CanExtractFunction(0x140038d9380, {0x140038d9380, 0x92e342, 0x92eef2}, {0x14001dea000, 0xbc7, 0xbc8"" [ERROR][2022-09-21 09:02:06] .../vim/lsp/rpc.lua:733 ""rpc"" ""/Users/fsouza/.cache/nvim/langservers/bin/gopls"" ""stderr"" ""}, 0x102f5bfe4?)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:984 +0xc4\ngolang.org/x/tools/gopls/internal/lsp.extractionFixes({0x1034480e0, 0x1400d856440}, {0x103453b18?, 0x140038e2640?}, {0x103408780?, 0x0?}, {0x140069ec9c0, 0x3a}, {{0x0?, 0x0?}, ...})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:301 +0x180\ngolang.org/x/tools/gopls/internal/lsp.(*Server).codeAction(0x1400d8b4180?, {0x1034480e0, 0x1400d856440}, 0x1400d8b4180)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:196 +0x13c4\ngolang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0x14000138210?, {0x1034480e0?, 0x1400d856440?}, 0x1032e84c0?)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/server_gen.go:16 +0x24\ngolang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x1034480e0, 0x1400d856440}, {0x1034571a8, 0x140004f2360}, 0x1400d66e750, {0x103448498, 0x1400d8562c0})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/tsserver.go:239 +0x18cc\ngolang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498, 0x1400d8562c0})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/protocol.go:157 +0x6c\ngolang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498?, 0x1400d8562c0?})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/lsprpc/lsprpc.go:515 +0x768\ngolang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d5bd128, {0x103448498?, 0x1400d8562c0?})\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:35 +0xf0\ngolang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:103 +0x90\ncreated by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:100 +0x1dc\n"" ``` In order to make it easier to read, I've also expanded the two lines above. This is the output from gopls: ``` panic: runtime error: index out of range [2] with length 2 goroutine 8707 [running]: golang.org/x/tools/gopls/internal/lsp/source.adjustRangeForCommentsAndWhiteSpace({0x140038d9380?, 0x69?, 0x1?}, 0x140038d9380, {0x14001dea000, 0xbc7, 0x140000f4640?}, 0x1400370b400) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:704 +0x3e0 golang.org/x/tools/gopls/internal/lsp/source.CanExtractFunction(0x140038d9380, {0x140038d9380, 0x92e342, 0x92eef2}, {0x14001dea000, 0xbc7, 0xbc8}, 0x102f5bfe4?) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:984 +0xc4 golang.org/x/tools/gopls/internal/lsp.extractionFixes({0x1034480e0, 0x1400d856440}, {0x103453b18?, 0x140038e2640?}, {0x103408780?, 0x0?}, {0x140069ec9c0, 0x3a}, {{0x0?, 0x0?}, ...}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:301 +0x180 golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction(0x1400d8b4180?, {0x1034480e0, 0x1400d856440}, 0x1400d8b4180) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:196 +0x13c4 golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0x14000138210?, {0x1034480e0?, 0x1400d856440?}, 0x1032e84c0?) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/server_gen.go:16 +0x24 golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x1034480e0, 0x1400d856440}, {0x1034571a8, 0x140004f2360}, 0x1400d66e750, {0x103448498, 0x1400d8562c0}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/tsserver.go:239 +0x18cc golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498, 0x1400d8562c0}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/protocol.go:157 +0x6c golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498?, 0x1400d8562c0?}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/lsprpc/lsprpc.go:515 +0x768 golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d5bd128, {0x103448498?, 0x1400d8562c0?}) /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:35 +0xf0 golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2() /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:103 +0x90 created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1 /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:100 +0x1dc ``` This is a regression and I was able to bisect it to this commit: ``` fdf581fdab091d9dd12425be67e59db67a2ad501 is the first bad commit commit fdf581fdab091d9dd12425be67e59db67a2ad501 Author: Suzy Mueller Date: Thu Sep 23 19:52:37 2021 -0600 internal/lsp: allow extract func ranges to begin/end with comments CanExtract strips of the whitespace on either end of the range in order to get an exact range to extract to function. We can do the same thing for comments by moving adjusting the range if the start or end positions contain the position. Updates golang/go#37170 Fixes golang/go#54816 Change-Id: I3508c822434400f084a273730380c89611803e97 Reviewed-on: https://go-review.googlesource.com/c/tools/+/351989 Reviewed-by: Robert Findley gopls-CI: kokoro Run-TryBot: Suzy Mueller TryBot-Result: Gopher Robot gopls/internal/lsp/source/extract.go | 94 +++++++++++++++------- .../extract_function/extract_basic_comment.go | 10 ++- .../extract_basic_comment.go.golden | 46 ++++++++++- gopls/internal/lsp/testdata/summary.txt.golden | 2 +- .../lsp/testdata/summary_go1.18.txt.golden | 2 +- 5 files changed, 115 insertions(+), 39 deletions(-) ``` ### Editor and settings This is neovim. It can be reproduced with just gopls installed. Minimal reproducer in neovim: https://gist.github.com/fsouza/01bf91accbce744ae528bad2472c79f3 How to reproduce in neovim with the config file above, using some Go repo (I tested with [fake-gcs-server](https://github.com/fsouza/fake-gcs-server), but I suspect that any project/file will do): ``` nvim -u minimal_init.lua :e main.go :lua document_code_action() ``` ### Logs Logs from gopls: https://gist.github.com/fsouza/ecc217ae4f2bbdc4dbcf2033c6b34581 Logs from the editor (includes the process stderr with the crash at the very end): https://gist.github.com/fsouza/9700b8daa4658fb226440fbedf1dbff5",1.0,"x/tools/gopls: index out of range while trying to run textDocument/codeAction on entire document - ### gopls version ``` Build info ---------- golang.org/x/tools/gopls master golang.org/x/tools/gopls@(devel) github.com/BurntSushi/toml@v1.2.0 h1:Rt8g24XnyGTyglgET/PRUNlrUeu9F5L+7FilkXfZgs0= github.com/google/go-cmp@v0.5.8 h1:e6P7q2lk1O+qJJb4BtCQXlK8vWEO8V1ZeuEdJNOqZyg= github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= golang.org/x/exp@v0.0.0-20220722155223-a9213eeb770e h1:+WEEuIdZHnUeJJmEUjyYC2gfUMj69yZXw17EnHg/otA= golang.org/x/exp/typeparams@v0.0.0-20220722155223-a9213eeb770e h1:7Xs2YCOpMlNqSQSmrrnhlzBXIE/bpMecZplbLePTJvE= golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s= golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4 h1:uVc8UZUe6tr40fFVnUP5Oj+veunVezqYl9z7DYw9xzw= golang.org/x/sys@v0.0.0-20220808155132-1c4a2a72c664 h1:v1W7bwXHsnLLloWYTVEdvGvA7BHMeBYsPcF0GLDxIRs= golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk= golang.org/x/tools@v0.1.13-0.20220810174125-0ad49fdeb955 => ../ golang.org/x/vuln@v0.0.0-20220919155316-41b1fc70d0a6 h1:tQFrcJZ95V1wiLLPoAIaEuEVXJ7JkhbZI4Hws7Fx69c= honnef.co/go/tools@v0.3.3 h1:oDx7VAwstgpYpb3wv0oxiZlxY+foCpRAwY7Vk6XpAgA= mvdan.cc/gofumpt@v0.3.1 h1:avhhrOmv0IuvQVK7fvwV91oFSGAk5/6Po8GXTzICeu8= mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc= go: devel go1.20-d11c58eedb Wed Sep 21 01:56:24 2022 +0000 ``` ### go env ``` ％ go env GO111MODULE="""" GOARCH=""arm64"" GOBIN=""/Users/fsouza/bin"" GOCACHE=""/Users/fsouza/Library/Caches/go-build"" GOENV=""/Users/fsouza/Library/Application Support/go/env"" GOEXE="""" GOEXPERIMENT="""" GOFLAGS=""-modcacherw"" GOHOSTARCH=""arm64"" GOHOSTOS=""darwin"" GOINSECURE="""" GOMODCACHE=""/Users/fsouza/.cache/go/path/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""darwin"" GOPATH=""/Users/fsouza/.cache/go/path"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/Users/fsouza/.cache/go/sdk/gotip"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/Users/fsouza/.cache/go/sdk/gotip/pkg/tool/darwin_arm64"" GOVCS="""" GOVERSION=""devel go1.20-d11c58eedb Wed Sep 21 01:56:24 2022 +0000"" GCCGO=""gccgo"" AR=""ar"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD=""/Users/fsouza/Projects/os/p/fake-gcs-server/go.mod"" GOWORK="""" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOGCCFLAGS=""-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rz/8d0l4yp51sd3jh9f34x7pkg80000gn/T/go-build3810227374=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? Invoke `textDocument/codeAction` passing a range that covers the entire file (following the [spec for range](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#range), which means that the end position is exclusive). Here's what the range I'm sending looks like (in JSON-ish): ```json { ... other fields ""range"": { ""start"": { ""line"": 0, ""character"": 0 }, ""end"": { ""line"": $N, ""character"": 0 } } } ``` Where `$N` = number of lines in the file. For full reproduction steps, see ""Editor & Settings"" below. ### What did you expect to see? The list of code actions available in the entire file. ### What did you see instead? gopls panics with an index out of range. Since this is a panic, the stacktrace isn't available in the logs for gopls, but I'm able to get the process output from my editor's logs: ``` [ERROR][2022-09-21 09:02:06] .../vim/lsp/rpc.lua:733 ""rpc"" ""/Users/fsouza/.cache/nvim/langservers/bin/gopls"" ""stderr"" ""panic: runtime error: index out of range [2] with length 2\n\ngoroutine 8707 [running]:\ngolang.org/x/tools/gopls/internal/lsp/source.adjustRangeForCommentsAndWhiteSpace({0x140038d9380?, 0x69?, 0x1?}, 0x140038d9380, {0x14001dea000, 0xbc7, 0x140000f4640?}, 0x1400370b400)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:704 +0x3e0\ngolang.org/x/tools/gopls/internal/lsp/source.CanExtractFunction(0x140038d9380, {0x140038d9380, 0x92e342, 0x92eef2}, {0x14001dea000, 0xbc7, 0xbc8"" [ERROR][2022-09-21 09:02:06] .../vim/lsp/rpc.lua:733 ""rpc"" ""/Users/fsouza/.cache/nvim/langservers/bin/gopls"" ""stderr"" ""}, 0x102f5bfe4?)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:984 +0xc4\ngolang.org/x/tools/gopls/internal/lsp.extractionFixes({0x1034480e0, 0x1400d856440}, {0x103453b18?, 0x140038e2640?}, {0x103408780?, 0x0?}, {0x140069ec9c0, 0x3a}, {{0x0?, 0x0?}, ...})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:301 +0x180\ngolang.org/x/tools/gopls/internal/lsp.(*Server).codeAction(0x1400d8b4180?, {0x1034480e0, 0x1400d856440}, 0x1400d8b4180)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:196 +0x13c4\ngolang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0x14000138210?, {0x1034480e0?, 0x1400d856440?}, 0x1032e84c0?)\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/server_gen.go:16 +0x24\ngolang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x1034480e0, 0x1400d856440}, {0x1034571a8, 0x140004f2360}, 0x1400d66e750, {0x103448498, 0x1400d8562c0})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/tsserver.go:239 +0x18cc\ngolang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498, 0x1400d8562c0})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/protocol.go:157 +0x6c\ngolang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498?, 0x1400d8562c0?})\n\t/Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/lsprpc/lsprpc.go:515 +0x768\ngolang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d5bd128, {0x103448498?, 0x1400d8562c0?})\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:35 +0xf0\ngolang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:103 +0x90\ncreated by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1\n\t/Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:100 +0x1dc\n"" ``` In order to make it easier to read, I've also expanded the two lines above. This is the output from gopls: ``` panic: runtime error: index out of range [2] with length 2 goroutine 8707 [running]: golang.org/x/tools/gopls/internal/lsp/source.adjustRangeForCommentsAndWhiteSpace({0x140038d9380?, 0x69?, 0x1?}, 0x140038d9380, {0x14001dea000, 0xbc7, 0x140000f4640?}, 0x1400370b400) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:704 +0x3e0 golang.org/x/tools/gopls/internal/lsp/source.CanExtractFunction(0x140038d9380, {0x140038d9380, 0x92e342, 0x92eef2}, {0x14001dea000, 0xbc7, 0xbc8}, 0x102f5bfe4?) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/source/extract.go:984 +0xc4 golang.org/x/tools/gopls/internal/lsp.extractionFixes({0x1034480e0, 0x1400d856440}, {0x103453b18?, 0x140038e2640?}, {0x103408780?, 0x0?}, {0x140069ec9c0, 0x3a}, {{0x0?, 0x0?}, ...}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:301 +0x180 golang.org/x/tools/gopls/internal/lsp.(*Server).codeAction(0x1400d8b4180?, {0x1034480e0, 0x1400d856440}, 0x1400d8b4180) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/code_action.go:196 +0x13c4 golang.org/x/tools/gopls/internal/lsp.(*Server).CodeAction(0x14000138210?, {0x1034480e0?, 0x1400d856440?}, 0x1032e84c0?) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/server_gen.go:16 +0x24 golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x1034480e0, 0x1400d856440}, {0x1034571a8, 0x140004f2360}, 0x1400d66e750, {0x103448498, 0x1400d8562c0}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/tsserver.go:239 +0x18cc golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498, 0x1400d8562c0}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/protocol/protocol.go:157 +0x6c golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x1034480e0, 0x1400d856440}, 0x1400d66e750, {0x103448498?, 0x1400d8562c0?}) /Users/fsouza/.cache/nvim/langservers/tools/gopls/internal/lsp/lsprpc/lsprpc.go:515 +0x768 golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x1034480e0, 0x1400d856440}, 0x1400d5bd128, {0x103448498?, 0x1400d8562c0?}) /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:35 +0xf0 golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2() /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:103 +0x90 created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1 /Users/fsouza/.cache/nvim/langservers/tools/internal/jsonrpc2/handler.go:100 +0x1dc ``` This is a regression and I was able to bisect it to this commit: ``` fdf581fdab091d9dd12425be67e59db67a2ad501 is the first bad commit commit fdf581fdab091d9dd12425be67e59db67a2ad501 Author: Suzy Mueller Date: Thu Sep 23 19:52:37 2021 -0600 internal/lsp: allow extract func ranges to begin/end with comments CanExtract strips of the whitespace on either end of the range in order to get an exact range to extract to function. We can do the same thing for comments by moving adjusting the range if the start or end positions contain the position. Updates golang/go#37170 Fixes golang/go#54816 Change-Id: I3508c822434400f084a273730380c89611803e97 Reviewed-on: https://go-review.googlesource.com/c/tools/+/351989 Reviewed-by: Robert Findley gopls-CI: kokoro Run-TryBot: Suzy Mueller TryBot-Result: Gopher Robot gopls/internal/lsp/source/extract.go | 94 +++++++++++++++------- .../extract_function/extract_basic_comment.go | 10 ++- .../extract_basic_comment.go.golden | 46 ++++++++++- gopls/internal/lsp/testdata/summary.txt.golden | 2 +- .../lsp/testdata/summary_go1.18.txt.golden | 2 +- 5 files changed, 115 insertions(+), 39 deletions(-) ``` ### Editor and settings This is neovim. It can be reproduced with just gopls installed. Minimal reproducer in neovim: https://gist.github.com/fsouza/01bf91accbce744ae528bad2472c79f3 How to reproduce in neovim with the config file above, using some Go repo (I tested with [fake-gcs-server](https://github.com/fsouza/fake-gcs-server), but I suspect that any project/file will do): ``` nvim -u minimal_init.lua :e main.go :lua document_code_action() ``` ### Logs Logs from gopls: https://gist.github.com/fsouza/ecc217ae4f2bbdc4dbcf2033c6b34581 Logs from the editor (includes the process stderr with the crash at the very end): https://gist.github.com/fsouza/9700b8daa4658fb226440fbedf1dbff5",1,x tools gopls index out of range while trying to run textdocument codeaction on entire document please answer these questions before submitting your issue thanks gopls version output of gopls v version on the command line build info golang org x tools gopls master golang org x tools gopls devel github com burntsushi toml github com google go cmp github com sergi go diff golang org x exp ota golang org x exp typeparams bpmeczplbleptjve golang org x mod dev golang org x sync golang org x sys golang org x text golang org x tools golang org x vuln honnef co go tools mvdan cc gofumpt mvdan cc xurls tzxjvaj go devel wed sep go env output of go env on the command line in your workspace directory ％ go env goarch gobin users fsouza bin gocache users fsouza library caches go build goenv users fsouza library application support go env goexe goexperiment goflags modcacherw gohostarch gohostos darwin goinsecure gomodcache users fsouza cache go path pkg mod gonoproxy gonosumdb goos darwin gopath users fsouza cache go path goprivate goproxy goroot users fsouza cache go sdk gotip gosumdb sum golang org gotmpdir gotooldir users fsouza cache go sdk gotip pkg tool darwin govcs goversion devel wed sep gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users fsouza projects os p fake gcs server go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders rz t go tmp go build gno record gcc switches fno common what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is better a failing unit test is the best invoke textdocument codeaction passing a range that covers the entire file following the spec for range which means that the end position is exclusive here s what the range i m sending looks like in json ish json other fields range start line character end line n character where n number of lines in the file for full reproduction steps see editor settings below what did you expect to see the list of code actions available in the entire file what did you see instead gopls panics with an index out of range since this is a panic the stacktrace isn t available in the logs for gopls but i m able to get the process output from my editor s logs vim lsp rpc lua rpc users fsouza cache nvim langservers bin gopls stderr panic runtime error index out of range with length n ngoroutine ngolang org x tools gopls internal lsp source adjustrangeforcommentsandwhitespace n t users fsouza cache nvim langservers tools gopls internal lsp source extract go ngolang org x tools gopls internal lsp source canextractfunction vim lsp rpc lua rpc users fsouza cache nvim langservers bin gopls stderr n t users fsouza cache nvim langservers tools gopls internal lsp source extract go ngolang org x tools gopls internal lsp extractionfixes n t users fsouza cache nvim langservers tools gopls internal lsp code action go ngolang org x tools gopls internal lsp server codeaction n t users fsouza cache nvim langservers tools gopls internal lsp code action go ngolang org x tools gopls internal lsp server codeaction n t users fsouza cache nvim langservers tools gopls internal lsp server gen go ngolang org x tools gopls internal lsp protocol serverdispatch n t users fsouza cache nvim langservers tools gopls internal lsp protocol tsserver go ngolang org x tools gopls internal lsp protocol serverhandler n t users fsouza cache nvim langservers tools gopls internal lsp protocol protocol go ngolang org x tools gopls internal lsp lsprpc handshaker n t users fsouza cache nvim langservers tools gopls internal lsp lsprpc lsprpc go ngolang org x tools internal mustreplyhandler n t users fsouza cache nvim langservers tools internal handler go ngolang org x tools internal asynchandler n t users fsouza cache nvim langservers tools internal handler go ncreated by golang org x tools internal asynchandler n t users fsouza cache nvim langservers tools internal handler go n in order to make it easier to read i ve also expanded the two lines above this is the output from gopls panic runtime error index out of range with length goroutine golang org x tools gopls internal lsp source adjustrangeforcommentsandwhitespace users fsouza cache nvim langservers tools gopls internal lsp source extract go golang org x tools gopls internal lsp source canextractfunction users fsouza cache nvim langservers tools gopls internal lsp source extract go golang org x tools gopls internal lsp extractionfixes users fsouza cache nvim langservers tools gopls internal lsp code action go golang org x tools gopls internal lsp server codeaction users fsouza cache nvim langservers tools gopls internal lsp code action go golang org x tools gopls internal lsp server codeaction users fsouza cache nvim langservers tools gopls internal lsp server gen go golang org x tools gopls internal lsp protocol serverdispatch users fsouza cache nvim langservers tools gopls internal lsp protocol tsserver go golang org x tools gopls internal lsp protocol serverhandler users fsouza cache nvim langservers tools gopls internal lsp protocol protocol go golang org x tools gopls internal lsp lsprpc handshaker users fsouza cache nvim langservers tools gopls internal lsp lsprpc lsprpc go golang org x tools internal mustreplyhandler users fsouza cache nvim langservers tools internal handler go golang org x tools internal asynchandler users fsouza cache nvim langservers tools internal handler go created by golang org x tools internal asynchandler users fsouza cache nvim langservers tools internal handler go this is a regression and i was able to bisect it to this commit is the first bad commit commit author suzy mueller date thu sep internal lsp allow extract func ranges to begin end with comments canextract strips of the whitespace on either end of the range in order to get an exact range to extract to function we can do the same thing for comments by moving adjusting the range if the start or end positions contain the position updates golang go fixes golang go change id reviewed on reviewed by robert findley gopls ci kokoro run trybot suzy mueller trybot result gopher robot gopls internal lsp source extract go extract function extract basic comment go extract basic comment go golden gopls internal lsp testdata summary txt golden lsp testdata summary txt golden files changed insertions deletions editor and settings your editor and any settings you have configured for example your vscode settings json file this is neovim it can be reproduced with just gopls installed minimal reproducer in neovim how to reproduce in neovim with the config file above using some go repo i tested with but i suspect that any project file will do nvim u minimal init lua e main go lua document code action logs if possible please include gopls logs instructions for capturing them can be found here logs from gopls logs from the editor includes the process stderr with the crash at the very end ,1 46027,7229534937.0,IssuesEvent,2018-02-11 20:42:23,golang/go,https://api.github.com/repos/golang/go,closed,doc: An unnecessary comment exists in CONTRIBUTING.md,Documentation NeedsFix,"The following unnecessary comment exists in CONTRIBUTING.md. > We do not accept GitHub pull requests https://github.com/golang/go/blob/master/CONTRIBUTING.md It has been removed in README.md, but it still exists in CONTRIBUTING.md. https://go-review.googlesource.com/c/go/+/92995",1.0,"doc: An unnecessary comment exists in CONTRIBUTING.md - The following unnecessary comment exists in CONTRIBUTING.md. > We do not accept GitHub pull requests https://github.com/golang/go/blob/master/CONTRIBUTING.md It has been removed in README.md, but it still exists in CONTRIBUTING.md. https://go-review.googlesource.com/c/go/+/92995",1,doc an unnecessary comment exists in contributing md the following unnecessary comment exists in contributing md we do not accept github pull requests it has been removed in readme md but it still exists in contributing md ,1 3260,3870092069.0,IssuesEvent,2016-04-11 00:00:10,golang/go,https://api.github.com/repos/golang/go,closed,runtime: Go 1.6 regresses Windows performance due to timeBeginPeriod removal,OS-Windows Performance,"1. What version of Go are you using (`go version`)? go version go1.6 windows/amd64 2. What operating system and processor architecture are you using (`go env`)? set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH= set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GO15VENDOREXPERIMENT=1 set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 3. What did you do? Run a benchmark from my go-winio package, which uses completion ports to provide non-thread-blocking IO on top of named pipes. It regressed significantly between go 1.5.3 and go 1.6, but only when I don't call timeBeginPeriod(1000). It seems that some aspect of the go scheduler still depends on a fast timer. You can see this with: go get github.com/Microsoft/go-winio cd ; git checkout go_16_regression_test go test -bench . set gofasttick=1 go test -bench . 4. What did you expect to see? Same performance before and after setting gofasttick=1 (which makes go-winio call timeBeginPeriod(1000) before doing any IO). 5. What did you see instead? Z:\jostarks\go\src\github.com\Microsoft\go-winio>go test -bench . PASS BenchmarkPipeIo-8 2000 998036 ns/op ok _/Z_/jostarks/go/src/github.com/Microsoft/go-winio 2.304s Z:\jostarks\go\src\github.com\Microsoft\go-winio>set gofasttick=1 Z:\jostarks\go\src\github.com\Microsoft\go-winio>go test -bench . PASS BenchmarkPipeIo-8 3000 517709 ns/op ok _/Z_/jostarks/go/src/github.com/Microsoft/go-winio 1.797s I can try to get a more minimal repro if it would be helpful. This has regressed Docker client performance significantly in Windows when operating over named pipes.",True,"runtime: Go 1.6 regresses Windows performance due to timeBeginPeriod removal - 1. What version of Go are you using (`go version`)? go version go1.6 windows/amd64 2. What operating system and processor architecture are you using (`go env`)? set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH= set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GO15VENDOREXPERIMENT=1 set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 3. What did you do? Run a benchmark from my go-winio package, which uses completion ports to provide non-thread-blocking IO on top of named pipes. It regressed significantly between go 1.5.3 and go 1.6, but only when I don't call timeBeginPeriod(1000). It seems that some aspect of the go scheduler still depends on a fast timer. You can see this with: go get github.com/Microsoft/go-winio cd ; git checkout go_16_regression_test go test -bench . set gofasttick=1 go test -bench . 4. What did you expect to see? Same performance before and after setting gofasttick=1 (which makes go-winio call timeBeginPeriod(1000) before doing any IO). 5. What did you see instead? Z:\jostarks\go\src\github.com\Microsoft\go-winio>go test -bench . PASS BenchmarkPipeIo-8 2000 998036 ns/op ok _/Z_/jostarks/go/src/github.com/Microsoft/go-winio 2.304s Z:\jostarks\go\src\github.com\Microsoft\go-winio>set gofasttick=1 Z:\jostarks\go\src\github.com\Microsoft\go-winio>go test -bench . PASS BenchmarkPipeIo-8 3000 517709 ns/op ok _/Z_/jostarks/go/src/github.com/Microsoft/go-winio 1.797s I can try to get a more minimal repro if it would be helpful. This has regressed Docker client performance significantly in Windows when operating over named pipes.",0,runtime go regresses windows performance due to timebeginperiod removal what version of go are you using go version go version windows what operating system and processor architecture are you using go env set goarch set gobin set goexe exe set gohostarch set gohostos windows set goos windows set gopath set gorace set goroot c go set gotooldir c go pkg tool windows set set cc gcc set gogccflags mthreads fmessage length set cxx g set cgo enabled what did you do run a benchmark from my go winio package which uses completion ports to provide non thread blocking io on top of named pipes it regressed significantly between go and go but only when i don t call timebeginperiod it seems that some aspect of the go scheduler still depends on a fast timer you can see this with go get github com microsoft go winio cd git checkout go regression test go test bench set gofasttick go test bench what did you expect to see same performance before and after setting gofasttick which makes go winio call timebeginperiod before doing any io what did you see instead z jostarks go src github com microsoft go winio go test bench pass benchmarkpipeio ns op ok z jostarks go src github com microsoft go winio z jostarks go src github com microsoft go winio set gofasttick z jostarks go src github com microsoft go winio go test bench pass benchmarkpipeio ns op ok z jostarks go src github com microsoft go winio i can try to get a more minimal repro if it would be helpful this has regressed docker client performance significantly in windows when operating over named pipes ,0 7752,2930274434.0,IssuesEvent,2015-06-29 01:34:46,golang/go,https://api.github.com/repos/golang/go,opened,x/net/webdav: TestDir fails on Plan 9,OS-Plan9 Testing,"See http://build.golang.org/log/86c5f54b2e864b4a89f8756c4c069739fb314cc9 ``` --- FAIL: TestDir (0.00s) file_test.go:501: test case #7 ""mk-dir /a want errExist"": got ""ok"" (), want ""errExist"" FAIL FAIL golang.org/x/net/webdav 1.019s ```",1.0,"x/net/webdav: TestDir fails on Plan 9 - See http://build.golang.org/log/86c5f54b2e864b4a89f8756c4c069739fb314cc9 ``` --- FAIL: TestDir (0.00s) file_test.go:501: test case #7 ""mk-dir /a want errExist"": got ""ok"" (), want ""errExist"" FAIL FAIL golang.org/x/net/webdav 1.019s ```",0,x net webdav testdir fails on plan see fail testdir file test go test case mk dir a want errexist got ok want errexist fail fail golang org x net webdav ,0 162669,13894720421.0,IssuesEvent,2020-10-19 15:00:31,golang/go,https://api.github.com/repos/golang/go,closed,crypto/hmac: detect reuse of hash.Hash value,Documentation NeedsFix,"Good time of the day, with go 1.15 release it seems there is some regression issue introduced with respect to `crypto/hmac` package. Was troubleshooting https://github.com/dvsekhvalnov/jose2go/issues/26 and found that `hmac.Reset()` is no longer behave same way as it was before (at least when called first), crafted minimal test case: ```go package main import ( ""crypto/hmac"" ""crypto/sha256"" ""fmt"" ""hash"" ) func main() { sha := sha256.New() hmac := hmac.New(func() hash.Hash { return sha }, []byte(""anything"")) hmac.Reset() // if you try to comment / uncomment that line, go 1.15 will produce different results hmac.Write([]byte(""salt"")) test := hmac.Sum(nil) fmt.Printf(""test = %v\n"", test) } ``` Is it producing output: 1. `[169 238 50 31 23 163 57 12 228 112 77 219 51 95 12 6 185 17 156 244 116 243 186 227 89 79 64 19 227 242 86 186]` on go v1.15 2. `[213 21 105 177 57 151 62 247 23 137 16 75 59 26 241 187 229 148 88 219 30 222 223 77 186 120 81 74 247 237 232 66]` on go v.14 and below , more over toggling leading `hmac.Reset()` will produce different results with 1.15 vs. previous versions. It seems change was introduced by https://github.com/golang/go/commit/97240d546c3ae54871c7c196e504e4a0a06faf87 So will tag @magical and @FiloSottile here. Honestly i don't know may be calling `hmac.Reset` before everything else is not sane idea, but it's not documented anywhere and clearly was behaving differently before. Thank you.",1.0,"crypto/hmac: detect reuse of hash.Hash value - Good time of the day, with go 1.15 release it seems there is some regression issue introduced with respect to `crypto/hmac` package. Was troubleshooting https://github.com/dvsekhvalnov/jose2go/issues/26 and found that `hmac.Reset()` is no longer behave same way as it was before (at least when called first), crafted minimal test case: ```go package main import ( ""crypto/hmac"" ""crypto/sha256"" ""fmt"" ""hash"" ) func main() { sha := sha256.New() hmac := hmac.New(func() hash.Hash { return sha }, []byte(""anything"")) hmac.Reset() // if you try to comment / uncomment that line, go 1.15 will produce different results hmac.Write([]byte(""salt"")) test := hmac.Sum(nil) fmt.Printf(""test = %v\n"", test) } ``` Is it producing output: 1. `[169 238 50 31 23 163 57 12 228 112 77 219 51 95 12 6 185 17 156 244 116 243 186 227 89 79 64 19 227 242 86 186]` on go v1.15 2. `[213 21 105 177 57 151 62 247 23 137 16 75 59 26 241 187 229 148 88 219 30 222 223 77 186 120 81 74 247 237 232 66]` on go v.14 and below , more over toggling leading `hmac.Reset()` will produce different results with 1.15 vs. previous versions. It seems change was introduced by https://github.com/golang/go/commit/97240d546c3ae54871c7c196e504e4a0a06faf87 So will tag @magical and @FiloSottile here. Honestly i don't know may be calling `hmac.Reset` before everything else is not sane idea, but it's not documented anywhere and clearly was behaving differently before. Thank you.",1,crypto hmac detect reuse of hash hash value good time of the day with go release it seems there is some regression issue introduced with respect to crypto hmac package was troubleshooting and found that hmac reset is no longer behave same way as it was before at least when called first crafted minimal test case go package main import crypto hmac crypto fmt hash func main sha new hmac hmac new func hash hash return sha byte anything hmac reset if you try to comment uncomment that line go will produce different results hmac write byte salt test hmac sum nil fmt printf test v n test is it producing output on go on go v and below more over toggling leading hmac reset will produce different results with vs previous versions it seems change was introduced by so will tag magical and filosottile here honestly i don t know may be calling hmac reset before everything else is not sane idea but it s not documented anywhere and clearly was behaving differently before thank you ,1 16833,6289086592.0,IssuesEvent,2017-07-19 18:25:44,golang/go,https://api.github.com/repos/golang/go,opened,x/build/maintner: load tokens from XDG config dir,Builders,Right now we hardcode the file to get Github tokens from as `$HOME/.github-issue-token`. If a user has XDG_CONFIG_HOME specified we should try to load tokens from there too.,1.0,x/build/maintner: load tokens from XDG config dir - Right now we hardcode the file to get Github tokens from as `$HOME/.github-issue-token`. If a user has XDG_CONFIG_HOME specified we should try to load tokens from there too.,0,x build maintner load tokens from xdg config dir right now we hardcode the file to get github tokens from as home github issue token if a user has xdg config home specified we should try to load tokens from there too ,0 28402,13655445948.0,IssuesEvent,2020-09-27 22:24:30,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: missed opportunity to coalesce reads/writes,Performance,"```go package p import ""encoding/binary"" func f(b []byte, x *[8]byte) { _ = b[8] t := binary.LittleEndian.Uint64(x[:]) binary.LittleEndian.PutUint64(b, t) } ``` This should compile down to two MOVQs on amd64, one to load from x and one to write to b. Instead, it compiles to a series of smaller MOVxs. The coalescing rules may need more cases added. cc @randall77 @dr2chase @martisch ",True,"cmd/compile: missed opportunity to coalesce reads/writes - ```go package p import ""encoding/binary"" func f(b []byte, x *[8]byte) { _ = b[8] t := binary.LittleEndian.Uint64(x[:]) binary.LittleEndian.PutUint64(b, t) } ``` This should compile down to two MOVQs on amd64, one to load from x and one to write to b. Instead, it compiles to a series of smaller MOVxs. The coalescing rules may need more cases added. cc @randall77 @dr2chase @martisch ",0,cmd compile missed opportunity to coalesce reads writes go package p import encoding binary func f b byte x byte b t binary littleendian x binary littleendian b t this should compile down to two movqs on one to load from x and one to write to b instead it compiles to a series of smaller movxs the coalescing rules may need more cases added cc martisch ,0 43933,7086733444.0,IssuesEvent,2018-01-11 15:42:19,golang/go,https://api.github.com/repos/golang/go,closed,Typing error in Go spec documentation,Documentation,"First of all, I'm sorry if it's not a typing error, still learning Go. ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ubuntu amd64 ### What did you do? Reading Go specification. Section: Properties of types and values - Type Identities. Noticed a typing error (maybe?): > These types are identical: > `B0, B0, and C0` ### What did you expect to see? > These types are identical: > `A0, B0, and C0` ### What did you see instead? > These types are identical: > `B0, B0, and C0` ",1.0,"Typing error in Go spec documentation - First of all, I'm sorry if it's not a typing error, still learning Go. ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ubuntu amd64 ### What did you do? Reading Go specification. Section: Properties of types and values - Type Identities. Noticed a typing error (maybe?): > These types are identical: > `B0, B0, and C0` ### What did you expect to see? > These types are identical: > `A0, B0, and C0` ### What did you see instead? > These types are identical: > `B0, B0, and C0` ",1,typing error in go spec documentation first of all i m sorry if it s not a typing error still learning go what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env ubuntu what did you do reading go specification section properties of types and values type identities noticed a typing error maybe these types are identical and what did you expect to see these types are identical and what did you see instead these types are identical and ,1 49016,7469648806.0,IssuesEvent,2018-04-03 00:03:10,golang/go,https://api.github.com/repos/golang/go,closed,install: Windows: set GOPATH from installer and optionally add GOPATH\bin to PATH,Documentation NeedsFix OS-Windows help wanted,"I ran the Go 1.9.2 Windows installers 32 bit on Windows XP and 64 bit on Windows 7. The default `GOPATH` on Windows is now (starting with Go 1.8 I think) `%USERPROFILE%\go` but this is not set as an environment variable. It seems to just be assumed by the tools if the environment variable is not set. The problem with that is that I cannot open `cmd` and type `cd %GOPATH%\bin` for example. This is very inconvenient and confusing to new Go users who read about `GOPATH` everywhere in the docs. Similarly it would be a very user-friendly feature if the Windows installer asked you, after setting `GOPATH`, if it should add `%GOPATH%\bin` to your `PATH` to be able to run Go programs that they got with `go get` from `cmd` directly. This option and the explanation would be way better right there in the installer instead of having it appear on the download page as mentioned in #18583. New users might not notice the redirect (or have it disabled in the browser) or care to read it. Honestly, who reads the manual before trying things out? Having a Windows installer is all about convenience so I think we should provide the most common tasks right in it. This is not only for new users either. I have been using Go for years and installed it on a couple of Windows systems. After the second time I knew what I had to do but it is still tedious. Yesterday I wanted to try compiling my game on a fresh Windows, ideally I would just install Git, install Go (which would set `GOPATH` and add `%GOPATH%\bin` to `PATH`) and `go get` it. Instead I had to go through the arcane Windows menus to get through to the environment variables. (Linux is not better, every dekstop has a different hidden file and syntax to set this, but I expect Linux users to know this stuff better). In summary my proposal is to add - one page for setting `GOPATH`, along with a short explanation - one page for adding `%GOPATH%\bin` to `PATH`, again with a short explanation to the Windows installer.",1.0,"install: Windows: set GOPATH from installer and optionally add GOPATH\bin to PATH - I ran the Go 1.9.2 Windows installers 32 bit on Windows XP and 64 bit on Windows 7. The default `GOPATH` on Windows is now (starting with Go 1.8 I think) `%USERPROFILE%\go` but this is not set as an environment variable. It seems to just be assumed by the tools if the environment variable is not set. The problem with that is that I cannot open `cmd` and type `cd %GOPATH%\bin` for example. This is very inconvenient and confusing to new Go users who read about `GOPATH` everywhere in the docs. Similarly it would be a very user-friendly feature if the Windows installer asked you, after setting `GOPATH`, if it should add `%GOPATH%\bin` to your `PATH` to be able to run Go programs that they got with `go get` from `cmd` directly. This option and the explanation would be way better right there in the installer instead of having it appear on the download page as mentioned in #18583. New users might not notice the redirect (or have it disabled in the browser) or care to read it. Honestly, who reads the manual before trying things out? Having a Windows installer is all about convenience so I think we should provide the most common tasks right in it. This is not only for new users either. I have been using Go for years and installed it on a couple of Windows systems. After the second time I knew what I had to do but it is still tedious. Yesterday I wanted to try compiling my game on a fresh Windows, ideally I would just install Git, install Go (which would set `GOPATH` and add `%GOPATH%\bin` to `PATH`) and `go get` it. Instead I had to go through the arcane Windows menus to get through to the environment variables. (Linux is not better, every dekstop has a different hidden file and syntax to set this, but I expect Linux users to know this stuff better). In summary my proposal is to add - one page for setting `GOPATH`, along with a short explanation - one page for adding `%GOPATH%\bin` to `PATH`, again with a short explanation to the Windows installer.",1,install windows set gopath from installer and optionally add gopath bin to path i ran the go windows installers bit on windows xp and bit on windows the default gopath on windows is now starting with go i think userprofile go but this is not set as an environment variable it seems to just be assumed by the tools if the environment variable is not set the problem with that is that i cannot open cmd and type cd gopath bin for example this is very inconvenient and confusing to new go users who read about gopath everywhere in the docs similarly it would be a very user friendly feature if the windows installer asked you after setting gopath if it should add gopath bin to your path to be able to run go programs that they got with go get from cmd directly this option and the explanation would be way better right there in the installer instead of having it appear on the download page as mentioned in new users might not notice the redirect or have it disabled in the browser or care to read it honestly who reads the manual before trying things out having a windows installer is all about convenience so i think we should provide the most common tasks right in it this is not only for new users either i have been using go for years and installed it on a couple of windows systems after the second time i knew what i had to do but it is still tedious yesterday i wanted to try compiling my game on a fresh windows ideally i would just install git install go which would set gopath and add gopath bin to path and go get it instead i had to go through the arcane windows menus to get through to the environment variables linux is not better every dekstop has a different hidden file and syntax to set this but i expect linux users to know this stuff better in summary my proposal is to add one page for setting gopath along with a short explanation one page for adding gopath bin to path again with a short explanation to the windows installer ,1 87388,10544893764.0,IssuesEvent,2019-10-02 17:56:22,golang/go,https://api.github.com/repos/golang/go,closed,proposal: doc: more overview of Go repo for new contributors,Documentation Proposal,"Scenario: I want to contribute with a fix (or investigation) in an open issue and need directions to start. The contributor guidelines (https://golang.org/doc/contribute.html) are focused on describing the tooling and the overall approval process, but I'm feeling lack of orientation on the technical end. For instance, how is the project organised? What each directory is for? What are the tools available? How do we test? How do we track test coverage? How does the `/test/fixedbugs/` directory work? If I'm fixing a bug should I create a file on fixedbugs or a _test file? Or both? Those are a few things that come to my mind at the moment, but this is by far not an exhaustive list. I think having a ""walkthrough""-like kind of guide teaching the high level organisation of the code, architectural components and the standard contribution process for writing a fix it would be a great addition to the contribution guide. I offer myself to help writing it, as long as someone spend the time teaching me how it works. ",1.0,"proposal: doc: more overview of Go repo for new contributors - Scenario: I want to contribute with a fix (or investigation) in an open issue and need directions to start. The contributor guidelines (https://golang.org/doc/contribute.html) are focused on describing the tooling and the overall approval process, but I'm feeling lack of orientation on the technical end. For instance, how is the project organised? What each directory is for? What are the tools available? How do we test? How do we track test coverage? How does the `/test/fixedbugs/` directory work? If I'm fixing a bug should I create a file on fixedbugs or a _test file? Or both? Those are a few things that come to my mind at the moment, but this is by far not an exhaustive list. I think having a ""walkthrough""-like kind of guide teaching the high level organisation of the code, architectural components and the standard contribution process for writing a fix it would be a great addition to the contribution guide. I offer myself to help writing it, as long as someone spend the time teaching me how it works. ",1,proposal doc more overview of go repo for new contributors scenario i want to contribute with a fix or investigation in an open issue and need directions to start the contributor guidelines are focused on describing the tooling and the overall approval process but i m feeling lack of orientation on the technical end for instance how is the project organised what each directory is for what are the tools available how do we test how do we track test coverage how does the test fixedbugs directory work if i m fixing a bug should i create a file on fixedbugs or a test file or both those are a few things that come to my mind at the moment but this is by far not an exhaustive list i think having a walkthrough like kind of guide teaching the high level organisation of the code architectural components and the standard contribution process for writing a fix it would be a great addition to the contribution guide i offer myself to help writing it as long as someone spend the time teaching me how it works ,1 64107,15798138784.0,IssuesEvent,2021-04-02 18:05:49,golang/go,https://api.github.com/repos/golang/go,closed,x/build: linux-arm builder can't finish an all.bash run when test sharding isn't used,Builders NeedsInvestigation,"When I run a trybot on linux/arm, I get ""out of memory"" or ""no space left on device"" errors. ``` ok reflect 3.259s ok regexp 0.949s ok regexp/syntax 4.910s # cmd/compile/internal/ssa fatal error: runtime: out of memory runtime stack: runtime.throw(0x29ca71, 0x16) /workdir/go/src/runtime/panic.go:1116 +0x5c runtime.sysMap(0x11400000, 0x3000000, 0x42bc70) /workdir/go/src/runtime/mem_linux.go:169 +0xa8 runtime.(*linearAlloc).alloc(0x41d280, 0x3000000, 0x400000, 0x42bc70, 0x0) /workdir/go/src/runtime/malloc.go:1447 +0x94 ``` ```ok unicode/utf8 0.055s ok cmd/addr2line 28.924s ok cmd/api 113.949s ok cmd/asm/internal/asm 33.778s ok cmd/asm/internal/lex 0.233s # cmd/fix.test panic: no space left on device goroutine 1 [running]: cmd/link/internal/ld.Main(0x3f33c0, 0x4, 0x8, 0x1, 0xd, 0xe, 0x0, 0x0, 0x285316, 0x12, ...) /workdir/go/src/cmd/link/internal/ld/main.go:319 +0x1c08 main.main() /workdir/go/src/cmd/link/main.go:68 +0x12c /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory ``` Is there anything we can do to fix this? Can we get more memory and/or disk space on these builders? I could work on making cmd/compile/internal/ssa tests take less memory, perhaps. Not sure how much we could save. ",1.0,"x/build: linux-arm builder can't finish an all.bash run when test sharding isn't used - When I run a trybot on linux/arm, I get ""out of memory"" or ""no space left on device"" errors. ``` ok reflect 3.259s ok regexp 0.949s ok regexp/syntax 4.910s # cmd/compile/internal/ssa fatal error: runtime: out of memory runtime stack: runtime.throw(0x29ca71, 0x16) /workdir/go/src/runtime/panic.go:1116 +0x5c runtime.sysMap(0x11400000, 0x3000000, 0x42bc70) /workdir/go/src/runtime/mem_linux.go:169 +0xa8 runtime.(*linearAlloc).alloc(0x41d280, 0x3000000, 0x400000, 0x42bc70, 0x0) /workdir/go/src/runtime/malloc.go:1447 +0x94 ``` ```ok unicode/utf8 0.055s ok cmd/addr2line 28.924s ok cmd/api 113.949s ok cmd/asm/internal/asm 33.778s ok cmd/asm/internal/lex 0.233s # cmd/fix.test panic: no space left on device goroutine 1 [running]: cmd/link/internal/ld.Main(0x3f33c0, 0x4, 0x8, 0x1, 0xd, 0xe, 0x0, 0x0, 0x285316, 0x12, ...) /workdir/go/src/cmd/link/internal/ld/main.go:319 +0x1c08 main.main() /workdir/go/src/cmd/link/main.go:68 +0x12c /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory /workdir/go/pkg/tool/linux_arm/vet: fork/exec /workdir/go/pkg/tool/linux_arm/vet: cannot allocate memory ``` Is there anything we can do to fix this? Can we get more memory and/or disk space on these builders? I could work on making cmd/compile/internal/ssa tests take less memory, perhaps. Not sure how much we could save. ",0,x build linux arm builder can t finish an all bash run when test sharding isn t used when i run a trybot on linux arm i get out of memory or no space left on device errors ok reflect ok regexp ok regexp syntax cmd compile internal ssa fatal error runtime out of memory runtime stack runtime throw workdir go src runtime panic go runtime sysmap workdir go src runtime mem linux go runtime linearalloc alloc workdir go src runtime malloc go ok unicode ok cmd ok cmd api ok cmd asm internal asm ok cmd asm internal lex cmd fix test panic no space left on device goroutine cmd link internal ld main workdir go src cmd link internal ld main go main main workdir go src cmd link main go workdir go pkg tool linux arm vet fork exec workdir go pkg tool linux arm vet cannot allocate memory workdir go pkg tool linux arm vet fork exec workdir go pkg tool linux arm vet cannot allocate memory workdir go pkg tool linux arm vet fork exec workdir go pkg tool linux arm vet cannot allocate memory is there anything we can do to fix this can we get more memory and or disk space on these builders i could work on making cmd compile internal ssa tests take less memory perhaps not sure how much we could save ,0 36832,6552416210.0,IssuesEvent,2017-09-05 18:16:24,golang/go,https://api.github.com/repos/golang/go,reopened,"time: Round(0), Truncate(0) strip monotonic clock readings but documentation still says it returns t unchanged",Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9rc2 darwin/amd64 this does not happen, for contrast, with go1.8.3 darwin/amd64 This change is documented at the top of the new go1.9rc2 time/time.go file: ~~~ // For debugging, the result of t.String does include the monotonic // clock reading if present. If t != u because of different monotonic clock readings, // that difference will be visible when printing t.String() and u.String(). ~~~ This is actually a rather drastic proposed change. I refer not the use of the monotone clock, but the display of it in timestamps formated via String(). Many of us use String() for many purposes other than debugging. For debugging, a separate new StringWithMonotone() should be provided. ### What operating system and processor architecture are you using (`go env`)? go env: GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/jaten/go"" GORACE="""" GOROOT=""/usr/local/go1.9rc2"" GOTOOLDIR=""/usr/local/go1.9rc2/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build055854381=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? Here code to reproduce the issue, `serialize_time.go`. It is extracted from the time.Time serialization in a popular msgpack serialization package. e.g. getunix() and putunix() are here https://github.com/tinylib/msgp/blob/ad0ff2e232ad2e37faf67087fb24bf8d04a8ce20/msgp/integers.go#L113 ~~~ package main import ( ""fmt"" ""time"" ) func main() { // time to bytes t := time.Now() fmt.Printf(""original t='%s'\n"", t.String()) t = t.UTC() fmt.Printf(""original t='%s' in UTC\n"", t.String()) var b [12]byte putUnix(b[:], t.Unix(), int32(t.Nanosecond())) // bytes to time: sec, nsec := getUnix(b[:]) t2 := time.Unix(sec, int64(nsec)).Local() fmt.Printf(""restored t2='%s'\n"", t2.String()) } /* output of main: original t='2017-08-16 19:35:41.958759249 -0400 EDT m=+0.000241395' original t='2017-08-16 23:35:41.958759249 +0000 UTC' in UTC restored t2='2017-08-16 19:35:41.958759249 -0400 EDT' */ func getUnix(b []byte) (sec int64, nsec int32) { sec = (int64(b[0]) << 56) | (int64(b[1]) << 48) | (int64(b[2]) << 40) | (int64(b[3]) << 32) | (int64(b[4]) << 24) | (int64(b[5]) << 16) | (int64(b[6]) << 8) | (int64(b[7])) nsec = (int32(b[8]) << 24) | (int32(b[9]) << 16) | (int32(b[10]) << 8) | (int32(b[11])) return } func putUnix(b []byte, sec int64, nsec int32) { b[0] = byte(sec >> 56) b[1] = byte(sec >> 48) b[2] = byte(sec >> 40) b[3] = byte(sec >> 32) b[4] = byte(sec >> 24) b[5] = byte(sec >> 16) b[6] = byte(sec >> 8) b[7] = byte(sec) b[8] = byte(nsec >> 24) b[9] = byte(nsec >> 16) b[10] = byte(nsec >> 8) b[11] = byte(nsec) } ~~~ In summary, in go1.9rc2, time.Time.String() may produce: `2017-08-16 18:41:39.184829495 -0400 EDT m=+0.057013769` whereas in go1.83, the String() applied to the same value produces always: `2017-08-16 18:41:39.184829495 -0400 EDT` While not a language consistency issue, this is a backwards-compatibility issue for programs that expected one thing from their time.Time values. For example, my tests in a fork of the tinylib/msgp lib cited above are suddenly broken under go1.9rc2. So these changes may break many programs unexpectedly when moving from go1.8.3 to go1.9. I'm glad for the new monotonic time feature under the covers, as it solves bugs with walltime going through leap seconds, but does it have to surface itself into the string representation of time in a non-backcompatible way? For the new info, how about adding a separate stringification method if one needs both timestamps? Perhaps: StringWithMonotone() alongside the old fashioned String(). In summary, while useful, features meant for debugging the new time.Time values should not break backwards compatibility, when they can trivially be provided alongside in a separate new method.",1.0,"time: Round(0), Truncate(0) strip monotonic clock readings but documentation still says it returns t unchanged - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9rc2 darwin/amd64 this does not happen, for contrast, with go1.8.3 darwin/amd64 This change is documented at the top of the new go1.9rc2 time/time.go file: ~~~ // For debugging, the result of t.String does include the monotonic // clock reading if present. If t != u because of different monotonic clock readings, // that difference will be visible when printing t.String() and u.String(). ~~~ This is actually a rather drastic proposed change. I refer not the use of the monotone clock, but the display of it in timestamps formated via String(). Many of us use String() for many purposes other than debugging. For debugging, a separate new StringWithMonotone() should be provided. ### What operating system and processor architecture are you using (`go env`)? go env: GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/jaten/go"" GORACE="""" GOROOT=""/usr/local/go1.9rc2"" GOTOOLDIR=""/usr/local/go1.9rc2/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build055854381=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? Here code to reproduce the issue, `serialize_time.go`. It is extracted from the time.Time serialization in a popular msgpack serialization package. e.g. getunix() and putunix() are here https://github.com/tinylib/msgp/blob/ad0ff2e232ad2e37faf67087fb24bf8d04a8ce20/msgp/integers.go#L113 ~~~ package main import ( ""fmt"" ""time"" ) func main() { // time to bytes t := time.Now() fmt.Printf(""original t='%s'\n"", t.String()) t = t.UTC() fmt.Printf(""original t='%s' in UTC\n"", t.String()) var b [12]byte putUnix(b[:], t.Unix(), int32(t.Nanosecond())) // bytes to time: sec, nsec := getUnix(b[:]) t2 := time.Unix(sec, int64(nsec)).Local() fmt.Printf(""restored t2='%s'\n"", t2.String()) } /* output of main: original t='2017-08-16 19:35:41.958759249 -0400 EDT m=+0.000241395' original t='2017-08-16 23:35:41.958759249 +0000 UTC' in UTC restored t2='2017-08-16 19:35:41.958759249 -0400 EDT' */ func getUnix(b []byte) (sec int64, nsec int32) { sec = (int64(b[0]) << 56) | (int64(b[1]) << 48) | (int64(b[2]) << 40) | (int64(b[3]) << 32) | (int64(b[4]) << 24) | (int64(b[5]) << 16) | (int64(b[6]) << 8) | (int64(b[7])) nsec = (int32(b[8]) << 24) | (int32(b[9]) << 16) | (int32(b[10]) << 8) | (int32(b[11])) return } func putUnix(b []byte, sec int64, nsec int32) { b[0] = byte(sec >> 56) b[1] = byte(sec >> 48) b[2] = byte(sec >> 40) b[3] = byte(sec >> 32) b[4] = byte(sec >> 24) b[5] = byte(sec >> 16) b[6] = byte(sec >> 8) b[7] = byte(sec) b[8] = byte(nsec >> 24) b[9] = byte(nsec >> 16) b[10] = byte(nsec >> 8) b[11] = byte(nsec) } ~~~ In summary, in go1.9rc2, time.Time.String() may produce: `2017-08-16 18:41:39.184829495 -0400 EDT m=+0.057013769` whereas in go1.83, the String() applied to the same value produces always: `2017-08-16 18:41:39.184829495 -0400 EDT` While not a language consistency issue, this is a backwards-compatibility issue for programs that expected one thing from their time.Time values. For example, my tests in a fork of the tinylib/msgp lib cited above are suddenly broken under go1.9rc2. So these changes may break many programs unexpectedly when moving from go1.8.3 to go1.9. I'm glad for the new monotonic time feature under the covers, as it solves bugs with walltime going through leap seconds, but does it have to surface itself into the string representation of time in a non-backcompatible way? For the new info, how about adding a separate stringification method if one needs both timestamps? Perhaps: StringWithMonotone() alongside the old fashioned String(). In summary, while useful, features meant for debugging the new time.Time values should not break backwards compatibility, when they can trivially be provided alongside in a separate new method.",1,time round truncate strip monotonic clock readings but documentation still says it returns t unchanged please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin this does not happen for contrast with darwin this change is documented at the top of the new time time go file for debugging the result of t string does include the monotonic clock reading if present if t u because of different monotonic clock readings that difference will be visible when printing t string and u string this is actually a rather drastic proposed change i refer not the use of the monotone clock but the display of it in timestamps formated via string many of us use string for many purposes other than debugging for debugging a separate new stringwithmonotone should be provided what operating system and processor architecture are you using go env go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users jaten go gorace goroot usr local gotooldir usr local pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config what did you do here code to reproduce the issue serialize time go it is extracted from the time time serialization in a popular msgpack serialization package e g getunix and putunix are here package main import fmt time func main time to bytes t time now fmt printf original t s n t string t t utc fmt printf original t s in utc n t string var b byte putunix b t unix t nanosecond bytes to time sec nsec getunix b time unix sec nsec local fmt printf restored s n string output of main original t edt m original t utc in utc restored edt func getunix b byte sec nsec sec b b b b b b b b nsec b b b b return func putunix b byte sec nsec b byte sec b byte sec b byte sec b byte sec b byte sec b byte sec b byte sec b byte sec b byte nsec b byte nsec b byte nsec b byte nsec in summary in time time string may produce edt m whereas in the string applied to the same value produces always edt while not a language consistency issue this is a backwards compatibility issue for programs that expected one thing from their time time values for example my tests in a fork of the tinylib msgp lib cited above are suddenly broken under so these changes may break many programs unexpectedly when moving from to i m glad for the new monotonic time feature under the covers as it solves bugs with walltime going through leap seconds but does it have to surface itself into the string representation of time in a non backcompatible way for the new info how about adding a separate stringification method if one needs both timestamps perhaps stringwithmonotone alongside the old fashioned string in summary while useful features meant for debugging the new time time values should not break backwards compatibility when they can trivially be provided alongside in a separate new method ,1 10342,3377540970.0,IssuesEvent,2015-11-25 04:25:01,golang/go,https://api.github.com/repos/golang/go,reopened,spec: docs for iota could give an example of incrementing over non-iota definitions,Documentation,"i.e. demonstrate the latter half of ""It is reset to 0 whenever the reserved word const appears in the source and increments after each ConstSpec."" with something like ``` const ( s = ""a"" // increments iota c0 = iota // c0 == 1 t = 5 c1 = iota // c1 == 3 ) ``` as this behaviour wasn't obvious to me (as a lazy reader who prefers looking at examples).",1.0,"spec: docs for iota could give an example of incrementing over non-iota definitions - i.e. demonstrate the latter half of ""It is reset to 0 whenever the reserved word const appears in the source and increments after each ConstSpec."" with something like ``` const ( s = ""a"" // increments iota c0 = iota // c0 == 1 t = 5 c1 = iota // c1 == 3 ) ``` as this behaviour wasn't obvious to me (as a lazy reader who prefers looking at examples).",1,spec docs for iota could give an example of incrementing over non iota definitions i e demonstrate the latter half of it is reset to whenever the reserved word const appears in the source and increments after each constspec with something like const s a increments iota iota t iota as this behaviour wasn t obvious to me as a lazy reader who prefers looking at examples ,1 42571,11019771497.0,IssuesEvent,2019-12-05 13:23:59,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gopherbot: document gopherbot actions and commands,Builders Documentation,"As the @gopherbot skills grow more interactive, we need somewhere to document how the commands work.",1.0,"x/build/cmd/gopherbot: document gopherbot actions and commands - As the @gopherbot skills grow more interactive, we need somewhere to document how the commands work.",0,x build cmd gopherbot document gopherbot actions and commands as the gopherbot skills grow more interactive we need somewhere to document how the commands work ,0 6531,3028401317.0,IssuesEvent,2015-08-04 04:50:19,golang/go,https://api.github.com/repos/golang/go,closed,"doc: for -buildmode=c-shared, document that //export requires import ""C""",Documentation,"This may just be a misunderstanding of how this is supposed to work - if so I'd appreciate some guidance. *What version of Go are you using (go version)?* `go version go1.5beta3 darwin/amd64` *What operating system and processor architecture are you using?* `Mac OS X 10.10.4 Intel Core i7` *What did you do?* I'm trying to build a C archive to link to a C++ app. I read the release notes and the **Go Execution Modes** doc. The second document states: > The only callable symbols will be those functions marked as exported (by any package), as described in the cgo documentation. I wrote a small test: ```go package main import ""log"" //export Foo func Foo() { log.Println(""Foo"") } func main() { // unused } ``` `go build -buildmode=c-archive` *What did you expect to see?* I expected it to create **foo.a** and a header file with *Foo* exported. *What did you see instead?* It generated **foo.a**, but no header file. *nm* also doesn't show my function being exported: ``` $ nm -g foo.a foo.a(000000.o): U ___stack_chk_fail U ___stack_chk_guard U ___stderrp 00000000000001f0 T __cgo_sys_thread_start 0000000000000360 T __cgo_wait_runtime_init_done U _abort 00000000000004e1 T _crosscall_amd64 U _fprintf U _fputc U _free U _fwrite U _malloc U _pthread_attr_destroy U _pthread_attr_getstacksize U _pthread_attr_init U _pthread_cond_broadcast U _pthread_cond_wait U _pthread_create U _pthread_key_create U _pthread_key_delete U _pthread_mutex_lock U _pthread_mutex_unlock U _pthread_setspecific U _pthread_sigmask U _setenv U _strerror U _unsetenv 0000000000000470 T _x_cgo_free 0000000000000000 T _x_cgo_init 0000000000000430 T _x_cgo_malloc 00000000000003c0 T _x_cgo_notify_runtime_init_done 0000000000000400 T _x_cgo_setenv 0000000000000300 T _x_cgo_sys_thread_create 0000000000000480 T _x_cgo_thread_start 0000000000000420 T _x_cgo_unsetenv foo.a(go.o): 00000000000b49f0 T __cgo_panic 0000000000054fe0 T __cgo_topofstack 00000000000b4a20 T _crosscall2 U _x_cgo_free U _x_cgo_init U _x_cgo_malloc U _x_cgo_notify_runtime_init_done U _x_cgo_setenv U _x_cgo_sys_thread_create U _x_cgo_thread_start U _x_cgo_unsetenv ```",1.0,"doc: for -buildmode=c-shared, document that //export requires import ""C"" - This may just be a misunderstanding of how this is supposed to work - if so I'd appreciate some guidance. *What version of Go are you using (go version)?* `go version go1.5beta3 darwin/amd64` *What operating system and processor architecture are you using?* `Mac OS X 10.10.4 Intel Core i7` *What did you do?* I'm trying to build a C archive to link to a C++ app. I read the release notes and the **Go Execution Modes** doc. The second document states: > The only callable symbols will be those functions marked as exported (by any package), as described in the cgo documentation. I wrote a small test: ```go package main import ""log"" //export Foo func Foo() { log.Println(""Foo"") } func main() { // unused } ``` `go build -buildmode=c-archive` *What did you expect to see?* I expected it to create **foo.a** and a header file with *Foo* exported. *What did you see instead?* It generated **foo.a**, but no header file. *nm* also doesn't show my function being exported: ``` $ nm -g foo.a foo.a(000000.o): U ___stack_chk_fail U ___stack_chk_guard U ___stderrp 00000000000001f0 T __cgo_sys_thread_start 0000000000000360 T __cgo_wait_runtime_init_done U _abort 00000000000004e1 T _crosscall_amd64 U _fprintf U _fputc U _free U _fwrite U _malloc U _pthread_attr_destroy U _pthread_attr_getstacksize U _pthread_attr_init U _pthread_cond_broadcast U _pthread_cond_wait U _pthread_create U _pthread_key_create U _pthread_key_delete U _pthread_mutex_lock U _pthread_mutex_unlock U _pthread_setspecific U _pthread_sigmask U _setenv U _strerror U _unsetenv 0000000000000470 T _x_cgo_free 0000000000000000 T _x_cgo_init 0000000000000430 T _x_cgo_malloc 00000000000003c0 T _x_cgo_notify_runtime_init_done 0000000000000400 T _x_cgo_setenv 0000000000000300 T _x_cgo_sys_thread_create 0000000000000480 T _x_cgo_thread_start 0000000000000420 T _x_cgo_unsetenv foo.a(go.o): 00000000000b49f0 T __cgo_panic 0000000000054fe0 T __cgo_topofstack 00000000000b4a20 T _crosscall2 U _x_cgo_free U _x_cgo_init U _x_cgo_malloc U _x_cgo_notify_runtime_init_done U _x_cgo_setenv U _x_cgo_sys_thread_create U _x_cgo_thread_start U _x_cgo_unsetenv ```",1,doc for buildmode c shared document that export requires import c this may just be a misunderstanding of how this is supposed to work if so i d appreciate some guidance what version of go are you using go version go version darwin what operating system and processor architecture are you using mac os x intel core what did you do i m trying to build a c archive to link to a c app i read the release notes and the go execution modes doc the second document states the only callable symbols will be those functions marked as exported by any package as described in the cgo documentation i wrote a small test go package main import log export foo func foo log println foo func main unused go build buildmode c archive what did you expect to see i expected it to create foo a and a header file with foo exported what did you see instead it generated foo a but no header file nm also doesn t show my function being exported nm g foo a foo a o u stack chk fail u stack chk guard u stderrp t cgo sys thread start t cgo wait runtime init done u abort t crosscall u fprintf u fputc u free u fwrite u malloc u pthread attr destroy u pthread attr getstacksize u pthread attr init u pthread cond broadcast u pthread cond wait u pthread create u pthread key create u pthread key delete u pthread mutex lock u pthread mutex unlock u pthread setspecific u pthread sigmask u setenv u strerror u unsetenv t x cgo free t x cgo init t x cgo malloc t x cgo notify runtime init done t x cgo setenv t x cgo sys thread create t x cgo thread start t x cgo unsetenv foo a go o t cgo panic t cgo topofstack t u x cgo free u x cgo init u x cgo malloc u x cgo notify runtime init done u x cgo setenv u x cgo sys thread create u x cgo thread start u x cgo unsetenv ,1 217161,16681008807.0,IssuesEvent,2021-06-07 23:45:02,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document changes to the language for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:

Changes to the language

TODO: https://golang.org/cl/216424: allow conversion from slice to array ptr

TODO: complete this section

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46020."" in the body.",1.0,"doc/go1.17: document changes to the language for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:

Changes to the language

TODO: https://golang.org/cl/216424: allow conversion from slice to array ptr

TODO: complete this section

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46020."" in the body.",1,doc document changes to the language for go as of filing this issue the contained the following html changes to the language todo a href allow conversion from slice to array ptr todo complete this section this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 83684,24120418559.0,IssuesEvent,2022-09-20 18:10:55,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/relui: TestSecurity failures,Builders NeedsInvestigation,"``` #!watchflakes post <- pkg == ""golang.org/x/build/internal/relui"" && test == ""TestSecurity"" ``` Bug automatically created to collect these failures. Example [log](https://build.golang.org/log/a28a274442b2a0ce03a2dc460a6ae6a36ed6b58c): 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-amd64-goamd64v3/1: 7 files, 2 dirs (1.027ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-ppc64le-buildlet/4: 7 files, 2 dirs (1.38375ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/freebsd-386-13_0/10: 7 files, 2 dirs (1.946625ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-amd64-race/9: 7 files, 2 dirs (3.469917ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-386-2008-newcc/3: 7 files, 2 dirs (1.095334ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-amd64-stretch/6: 7 files, 2 dirs (17.58825ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-ppc64le-buildlet/4/go1.4: 1 files, 1 dirs (209.583µs) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-amd64-newcc-race/23: 7 files, 2 dirs (1.339875ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/android-amd64-emu/7: 7 files, 2 dirs (18.910209ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/freebsd-amd64-12_3/22: 7 files, 2 dirs (2.683375ms) ... 2022/09/07 17:07:40 extracted tarball into /tmp/buildlet/tmp/TestSecuritysuccess1625173706/001/freebsd-amd64-12_3/71/go1.4: 1 files, 1 dirs (4.1065ms) panic: test timed out after 10m0s golang.org/x/build/internal/workflow.(*Workflow).Run(0x140005d5fc0, {0x10573d6d0?, 0x140005d5440}, {0x105737cc8, 0x140000b9060}) /tmp/buildlet/gopath/src/golang.org/x/build/internal/workflow/workflow.go:767 +0x244 golang.org/x/build/internal/relui.testSecurity(0x14001a2b1e0, 0x1) /tmp/buildlet/gopath/src/golang.org/x/build/internal/relui/buildrelease_test.go:304 +0x508 golang.org/x/build/internal/relui.TestSecurity.func1(0x14000243980?) /tmp/buildlet/gopath/src/golang.org/x/build/internal/relui/buildrelease_test.go:53 +0x20 testing.tRunner(0x14001a2b1e0, 0x105727f28) — [watchflakes](https://go.dev/wiki/Watchflakes) ",1.0,"x/build/internal/relui: TestSecurity failures - ``` #!watchflakes post <- pkg == ""golang.org/x/build/internal/relui"" && test == ""TestSecurity"" ``` Bug automatically created to collect these failures. Example [log](https://build.golang.org/log/a28a274442b2a0ce03a2dc460a6ae6a36ed6b58c): 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-amd64-goamd64v3/1: 7 files, 2 dirs (1.027ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-ppc64le-buildlet/4: 7 files, 2 dirs (1.38375ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/freebsd-386-13_0/10: 7 files, 2 dirs (1.946625ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-amd64-race/9: 7 files, 2 dirs (3.469917ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-386-2008-newcc/3: 7 files, 2 dirs (1.095334ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-amd64-stretch/6: 7 files, 2 dirs (17.58825ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/linux-ppc64le-buildlet/4/go1.4: 1 files, 1 dirs (209.583µs) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/windows-amd64-newcc-race/23: 7 files, 2 dirs (1.339875ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/android-amd64-emu/7: 7 files, 2 dirs (18.910209ms) 2022/09/07 17:07:32 extracted tarball into /tmp/buildlet/tmp/TestReleasebeta1870346664/001/freebsd-amd64-12_3/22: 7 files, 2 dirs (2.683375ms) ... 2022/09/07 17:07:40 extracted tarball into /tmp/buildlet/tmp/TestSecuritysuccess1625173706/001/freebsd-amd64-12_3/71/go1.4: 1 files, 1 dirs (4.1065ms) panic: test timed out after 10m0s golang.org/x/build/internal/workflow.(*Workflow).Run(0x140005d5fc0, {0x10573d6d0?, 0x140005d5440}, {0x105737cc8, 0x140000b9060}) /tmp/buildlet/gopath/src/golang.org/x/build/internal/workflow/workflow.go:767 +0x244 golang.org/x/build/internal/relui.testSecurity(0x14001a2b1e0, 0x1) /tmp/buildlet/gopath/src/golang.org/x/build/internal/relui/buildrelease_test.go:304 +0x508 golang.org/x/build/internal/relui.TestSecurity.func1(0x14000243980?) /tmp/buildlet/gopath/src/golang.org/x/build/internal/relui/buildrelease_test.go:53 +0x20 testing.tRunner(0x14001a2b1e0, 0x105727f28) — [watchflakes](https://go.dev/wiki/Watchflakes) ",0,x build internal relui testsecurity failures watchflakes post pkg golang org x build internal relui test testsecurity bug automatically created to collect these failures example extracted tarball into tmp buildlet tmp linux files dirs extracted tarball into tmp buildlet tmp linux buildlet files dirs extracted tarball into tmp buildlet tmp freebsd files dirs extracted tarball into tmp buildlet tmp windows race files dirs extracted tarball into tmp buildlet tmp windows newcc files dirs extracted tarball into tmp buildlet tmp linux stretch files dirs extracted tarball into tmp buildlet tmp linux buildlet files dirs extracted tarball into tmp buildlet tmp windows newcc race files dirs extracted tarball into tmp buildlet tmp android emu files dirs extracted tarball into tmp buildlet tmp freebsd files dirs extracted tarball into tmp buildlet tmp freebsd files dirs panic test timed out after golang org x build internal workflow workflow run tmp buildlet gopath src golang org x build internal workflow workflow go golang org x build internal relui testsecurity tmp buildlet gopath src golang org x build internal relui buildrelease test go golang org x build internal relui testsecurity tmp buildlet gopath src golang org x build internal relui buildrelease test go testing trunner — ,0 41707,6927746650.0,IssuesEvent,2017-12-01 00:25:54,golang/go,https://api.github.com/repos/golang/go,closed,testing: are T.Run and B.Run safe for concurrent use?,Documentation NeedsFix release-blocker,"I do not see any documentation specifying if T.Run is safe for concurrent use. I see the following doc for [testing.T](https://tip.golang.org/pkg/testing/#T), which does not mention T.Run: > A test ends when its Test function returns or calls any of the methods FailNow, Fatal, Fatalf, SkipNow, Skip, or Skipf. Those methods, as well as the Parallel method, must be called only from the goroutine running the Test function. > > The other reporting methods, such as the variations of Log and Error, may be called simultaneously from multiple goroutines. There is a similar doc for [testing.B](https://tip.golang.org/pkg/testing/#B). I ask because I believe T.Run was safe for concurrent use in go 1.7. Then, [this line](https://github.com/golang/go/blob/7fb16406139e934d84f7ec66ba440a772747270a/src/testing/testing.go#L663) was added in go 1.8, which made T.Run no longer safe for concurrent use. I don't particularly care whether T.Run is safe for concurrent use, but I think the semantics should be clarified. Optimistically labeling this go1.8. /cc @dsnet ",1.0,"testing: are T.Run and B.Run safe for concurrent use? - I do not see any documentation specifying if T.Run is safe for concurrent use. I see the following doc for [testing.T](https://tip.golang.org/pkg/testing/#T), which does not mention T.Run: > A test ends when its Test function returns or calls any of the methods FailNow, Fatal, Fatalf, SkipNow, Skip, or Skipf. Those methods, as well as the Parallel method, must be called only from the goroutine running the Test function. > > The other reporting methods, such as the variations of Log and Error, may be called simultaneously from multiple goroutines. There is a similar doc for [testing.B](https://tip.golang.org/pkg/testing/#B). I ask because I believe T.Run was safe for concurrent use in go 1.7. Then, [this line](https://github.com/golang/go/blob/7fb16406139e934d84f7ec66ba440a772747270a/src/testing/testing.go#L663) was added in go 1.8, which made T.Run no longer safe for concurrent use. I don't particularly care whether T.Run is safe for concurrent use, but I think the semantics should be clarified. Optimistically labeling this go1.8. /cc @dsnet ",1,testing are t run and b run safe for concurrent use i do not see any documentation specifying if t run is safe for concurrent use i see the following doc for which does not mention t run a test ends when its test function returns or calls any of the methods failnow fatal fatalf skipnow skip or skipf those methods as well as the parallel method must be called only from the goroutine running the test function the other reporting methods such as the variations of log and error may be called simultaneously from multiple goroutines there is a similar doc for i ask because i believe t run was safe for concurrent use in go then was added in go which made t run no longer safe for concurrent use i don t particularly care whether t run is safe for concurrent use but i think the semantics should be clarified optimistically labeling this cc dsnet ,1 277221,21033186189.0,IssuesEvent,2022-03-31 04:12:11,golang/go,https://api.github.com/repos/golang/go,closed,cmd/link: -X requires the full import path for vendored packages,Documentation help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.1 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/root/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build528112336=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? ``` $ find main.go vendor/github.com/ckeyer/commons/version/version.go $ go build -a -v -ldflags=""-X github.com/ckeyer/commons/version.version=v0.1.0"" main.go version ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? I want to see print the `version v0.1.0` ### What did you see instead? none I use `go build -a -v -ldflags=""-X github.com/ckeyer/frog/vendor/github.com/ckeyer/commons/version.version=v0.1.0"" main.go version` ,it works. ",1.0,"cmd/link: -X requires the full import path for vendored packages - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.1 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/root/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build528112336=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? ``` $ find main.go vendor/github.com/ckeyer/commons/version/version.go $ go build -a -v -ldflags=""-X github.com/ckeyer/commons/version.version=v0.1.0"" main.go version ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? I want to see print the `version v0.1.0` ### What did you see instead? none I use `go build -a -v -ldflags=""-X github.com/ckeyer/frog/vendor/github.com/ckeyer/commons/version.version=v0.1.0"" main.go version` ,it works. ",1,cmd link x requires the full import path for vendored packages please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache root cache go build goexe gohostarch gohostos linux goos linux gopath go gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do find main go vendor github com ckeyer commons version version go go build a v ldflags x github com ckeyer commons version version main go version if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see i want to see print the version what did you see instead none i use go build a v ldflags x github com ckeyer frog vendor github com ckeyer commons version version main go version it works ,1 40812,6849208247.0,IssuesEvent,2017-11-13 21:15:21,golang/go,https://api.github.com/repos/golang/go,opened,"cmd/gofmt: document that tools must invoke gofmt, not use go/format",Documentation,"We've had reports of skew where people are using one tool that links against go/printer (or go/format, which wraps it) and writes code, and then some other tool runs gofmt and sees that the formatting is different, because gofmt has a newer/older/different version of go/printer. We should document that tools that write code files that will be checked in should run gofmt (the program) over their output, not assume that their copy of go/printer matches. One such tool is goimports. The alternative is that we somehow never ever again change the output of gofmt on existing code, which seems too restrictive. See: - https://github.com/golang/go/issues/18782 (cmd/gofmt: comment lines broken at new position) - https://github.com/golang/go/issues/18790 (proposal: cmd/gofmt: write official spec for gofmt) - https://github.com/golang/go/issues/22607 (cmd/gofmt: formatting improvements may break existing presubmit checks) ",1.0,"cmd/gofmt: document that tools must invoke gofmt, not use go/format - We've had reports of skew where people are using one tool that links against go/printer (or go/format, which wraps it) and writes code, and then some other tool runs gofmt and sees that the formatting is different, because gofmt has a newer/older/different version of go/printer. We should document that tools that write code files that will be checked in should run gofmt (the program) over their output, not assume that their copy of go/printer matches. One such tool is goimports. The alternative is that we somehow never ever again change the output of gofmt on existing code, which seems too restrictive. See: - https://github.com/golang/go/issues/18782 (cmd/gofmt: comment lines broken at new position) - https://github.com/golang/go/issues/18790 (proposal: cmd/gofmt: write official spec for gofmt) - https://github.com/golang/go/issues/22607 (cmd/gofmt: formatting improvements may break existing presubmit checks) ",1,cmd gofmt document that tools must invoke gofmt not use go format we ve had reports of skew where people are using one tool that links against go printer or go format which wraps it and writes code and then some other tool runs gofmt and sees that the formatting is different because gofmt has a newer older different version of go printer we should document that tools that write code files that will be checked in should run gofmt the program over their output not assume that their copy of go printer matches one such tool is goimports the alternative is that we somehow never ever again change the output of gofmt on existing code which seems too restrictive see cmd gofmt comment lines broken at new position proposal cmd gofmt write official spec for gofmt cmd gofmt formatting improvements may break existing presubmit checks ,1 48722,7451765286.0,IssuesEvent,2018-03-29 05:09:23,golang/go,https://api.github.com/repos/golang/go,closed,testing: document cap the number of concurrent goroutines with -race,Documentation NeedsFix,"### What version of Go are you using (`go version`)? 1.9.2 GOOS=linux GOARCH=amd64 ### What did you do? ``` package main import ( ""math/rand"" ""strconv"" ""testing"" ""time"" ) func TestGoRoutines(t *testing.T) { for i := 0; i < 1<<15; i++ { t.Run(strconv.Itoa(i), func(t *testing.T) { t.Parallel() time.Sleep(time.Duration(rand.Intn(500000000))) }) } } ``` saved as `x_test.go` and run with `go test -race` ### What did you expect to see? The tests to pass. Instead, ``` race: limit on 8192 simultaneously alive goroutines is exceeded, dying ``` As I understand it, this is likely a technical limitation on Go's race detector. However, it would be nice for the `testing` package to be aware of this and, if raceenabled, cap the number of parallel tests at something below the 8192 limit (say, 7000?). Perhaps a better way would be a warning, but I know Go doesn't really like warnings. ",1.0,"testing: document cap the number of concurrent goroutines with -race - ### What version of Go are you using (`go version`)? 1.9.2 GOOS=linux GOARCH=amd64 ### What did you do? ``` package main import ( ""math/rand"" ""strconv"" ""testing"" ""time"" ) func TestGoRoutines(t *testing.T) { for i := 0; i < 1<<15; i++ { t.Run(strconv.Itoa(i), func(t *testing.T) { t.Parallel() time.Sleep(time.Duration(rand.Intn(500000000))) }) } } ``` saved as `x_test.go` and run with `go test -race` ### What did you expect to see? The tests to pass. Instead, ``` race: limit on 8192 simultaneously alive goroutines is exceeded, dying ``` As I understand it, this is likely a technical limitation on Go's race detector. However, it would be nice for the `testing` package to be aware of this and, if raceenabled, cap the number of parallel tests at something below the 8192 limit (say, 7000?). Perhaps a better way would be a warning, but I know Go doesn't really like warnings. ",1,testing document cap the number of concurrent goroutines with race what version of go are you using go version goos linux goarch what did you do package main import math rand strconv testing time func testgoroutines t testing t for i i i t run strconv itoa i func t testing t t parallel time sleep time duration rand intn saved as x test go and run with go test race what did you expect to see the tests to pass instead race limit on simultaneously alive goroutines is exceeded dying as i understand it this is likely a technical limitation on go s race detector however it would be nice for the testing package to be aware of this and if raceenabled cap the number of parallel tests at something below the limit say perhaps a better way would be a warning but i know go doesn t really like warnings ,1 211839,16460094382.0,IssuesEvent,2021-05-21 17:35:40,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document archive/zip changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
archive/zip

TODO: https://golang.org/cl/312310: add File.OpenRaw, Writer.CreateRaw, Writer.Copy

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46000."" in the body.",1.0,"doc/go1.17: document archive/zip changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
archive/zip

TODO: https://golang.org/cl/312310: add File.OpenRaw, Writer.CreateRaw, Writer.Copy

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46000."" in the body.",1,doc document archive zip changes for go as of filing this issue the contained the following html archive zip todo a href add file openraw writer createraw writer copy this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 50465,26655490164.0,IssuesEvent,2023-01-25 16:33:01,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/gopls: incremental gopls scaling,gopls/performance,"# Incremental gopls This is an umbrella issue to track the work we've been doing to change the way gopls scales (and significantly reduce memory usage and CPU on large codebases). We've been working off an internal design, but I wanted to share some of that here and have a public issue to track the work. The main goal of this project is to use on-disk export data and indexing to allow gopls to persist data across sessions, reloading on-demand, thereby reducing its overall memory footprint and startup time. As a result of this change, gopls memory usage (at least related to package information) will be O(open packages), rather than O(workspace). Furthermore, we will break global relationships between elements of gopls' cache, simplifying gopls' execution model and eliminating multiple categories of bugs. ## Background Gopls, as it very recently existed, was a monolithic build system. Certain algorithms relied on a global package graph containing the full set of workspace packages. For example, to find references to a given identifier, gopls simply walked all packages in the reverse transitive cone of the declaring package(s), and checked types.Info.Uses for references to the declared object. In order for this algorithm to be correct and sufficiently fast, gopls must hold all packages in memory (including many potentially redundant intermediate test variants!). We can't solve gopls' scaling problems until we rewrite these algorithms and fix all the places where gopls makes assumptions of global identity. This is what we've been working on. ## High level plan 1. [x] Design a shallow export data format that does not bundle its transitive closure. 2. [x] Add a mechanism for on-disk caching. 3. [ ] Rewrite workspace-wide queries to use indexes that are independent of `types.Package` or `types.Object` identity. - [x] workspace symbols - [x] references - [x] call hierarchy - [x] implementations - [ ] rename (may require re-implementing `types.Identical` and `types.AssignableTo` with a new notion of object identity, c.f. #57497) 4. [ ] Separate the concept of a ""syntax package"" (something containing AST and types.Info) from an ""export package"" (a `types.Package` with type information for exported symbols). Syntax packages are used to fully understand the syntax a user is working on. Export packages are used for type checking. Currently, gopls has a concept of ""exported parse mode"", which produces a syntax package on a truncated AST. This exists to reduce memory, but means that syntax packages may be partial, a source of many historical and current bugs. All current uses of partial packages in the package graph can (and must) be eliminated or replaced with a judicious use of parsing or type-checking on-demand. 5. [ ] Create a control plane to manage package information that must be preserved in memory vs re-computed on demand or transiently cached. 6. [ ] When importing during type-checking, use export packages for packages outside the workspace. For now, continue to produce syntax packages for all packages inside the workspace. 7. [ ] Persist and load export packages to disk. 8. [ ] Load xrefs and implements indexes from disk, rather than hanging them off of syntax packages. 9. [ ] Drop all syntax packages, except those with open files. 10. [ ] Improve the UX around indexing (better progress notifications, partial results, etc).",True,"x/tools/gopls: incremental gopls scaling - # Incremental gopls This is an umbrella issue to track the work we've been doing to change the way gopls scales (and significantly reduce memory usage and CPU on large codebases). We've been working off an internal design, but I wanted to share some of that here and have a public issue to track the work. The main goal of this project is to use on-disk export data and indexing to allow gopls to persist data across sessions, reloading on-demand, thereby reducing its overall memory footprint and startup time. As a result of this change, gopls memory usage (at least related to package information) will be O(open packages), rather than O(workspace). Furthermore, we will break global relationships between elements of gopls' cache, simplifying gopls' execution model and eliminating multiple categories of bugs. ## Background Gopls, as it very recently existed, was a monolithic build system. Certain algorithms relied on a global package graph containing the full set of workspace packages. For example, to find references to a given identifier, gopls simply walked all packages in the reverse transitive cone of the declaring package(s), and checked types.Info.Uses for references to the declared object. In order for this algorithm to be correct and sufficiently fast, gopls must hold all packages in memory (including many potentially redundant intermediate test variants!). We can't solve gopls' scaling problems until we rewrite these algorithms and fix all the places where gopls makes assumptions of global identity. This is what we've been working on. ## High level plan 1. [x] Design a shallow export data format that does not bundle its transitive closure. 2. [x] Add a mechanism for on-disk caching. 3. [ ] Rewrite workspace-wide queries to use indexes that are independent of `types.Package` or `types.Object` identity. - [x] workspace symbols - [x] references - [x] call hierarchy - [x] implementations - [ ] rename (may require re-implementing `types.Identical` and `types.AssignableTo` with a new notion of object identity, c.f. #57497) 4. [ ] Separate the concept of a ""syntax package"" (something containing AST and types.Info) from an ""export package"" (a `types.Package` with type information for exported symbols). Syntax packages are used to fully understand the syntax a user is working on. Export packages are used for type checking. Currently, gopls has a concept of ""exported parse mode"", which produces a syntax package on a truncated AST. This exists to reduce memory, but means that syntax packages may be partial, a source of many historical and current bugs. All current uses of partial packages in the package graph can (and must) be eliminated or replaced with a judicious use of parsing or type-checking on-demand. 5. [ ] Create a control plane to manage package information that must be preserved in memory vs re-computed on demand or transiently cached. 6. [ ] When importing during type-checking, use export packages for packages outside the workspace. For now, continue to produce syntax packages for all packages inside the workspace. 7. [ ] Persist and load export packages to disk. 8. [ ] Load xrefs and implements indexes from disk, rather than hanging them off of syntax packages. 9. [ ] Drop all syntax packages, except those with open files. 10. [ ] Improve the UX around indexing (better progress notifications, partial results, etc).",0,x tools gopls incremental gopls scaling incremental gopls this is an umbrella issue to track the work we ve been doing to change the way gopls scales and significantly reduce memory usage and cpu on large codebases we ve been working off an internal design but i wanted to share some of that here and have a public issue to track the work the main goal of this project is to use on disk export data and indexing to allow gopls to persist data across sessions reloading on demand thereby reducing its overall memory footprint and startup time as a result of this change gopls memory usage at least related to package information will be o open packages rather than o workspace furthermore we will break global relationships between elements of gopls cache simplifying gopls execution model and eliminating multiple categories of bugs background gopls as it very recently existed was a monolithic build system certain algorithms relied on a global package graph containing the full set of workspace packages for example to find references to a given identifier gopls simply walked all packages in the reverse transitive cone of the declaring package s and checked types info uses for references to the declared object in order for this algorithm to be correct and sufficiently fast gopls must hold all packages in memory including many potentially redundant intermediate test variants we can t solve gopls scaling problems until we rewrite these algorithms and fix all the places where gopls makes assumptions of global identity this is what we ve been working on high level plan design a shallow export data format that does not bundle its transitive closure add a mechanism for on disk caching rewrite workspace wide queries to use indexes that are independent of types package or types object identity workspace symbols references call hierarchy implementations rename may require re implementing types identical and types assignableto with a new notion of object identity c f separate the concept of a syntax package something containing ast and types info from an export package a types package with type information for exported symbols syntax packages are used to fully understand the syntax a user is working on export packages are used for type checking currently gopls has a concept of exported parse mode which produces a syntax package on a truncated ast this exists to reduce memory but means that syntax packages may be partial a source of many historical and current bugs all current uses of partial packages in the package graph can and must be eliminated or replaced with a judicious use of parsing or type checking on demand create a control plane to manage package information that must be preserved in memory vs re computed on demand or transiently cached when importing during type checking use export packages for packages outside the workspace for now continue to produce syntax packages for all packages inside the workspace persist and load export packages to disk load xrefs and implements indexes from disk rather than hanging them off of syntax packages drop all syntax packages except those with open files improve the ux around indexing better progress notifications partial results etc ,0 129835,12419529005.0,IssuesEvent,2020-05-23 06:47:41,golang/go,https://api.github.com/repos/golang/go,closed,encoding/asn1: extra elements at the end of a sequence are completely ignored,Documentation NeedsInvestigation," ### Does this issue reproduce with the latest release? Yes ### What did you do? Appended garbage data (such as zeros, null, etc) to a hex encoded asn1 SEQUENCE type. For example, rather than: `302d021500aa6a258fbf7d90e15614676d377df8b10e38db4a0214496d5220b5f67d3532d1f991203bc3523b964c3b` I provided: `302f021500aa6a258fbf7d90e15614676d377df8b10e38db4a0214496d5220b5f67d3532d1f991203bc3523b964c3b0000` which has a slightly larger length, and some trailing zeros. https://play.golang.org/p/TrwfRC31i1m ### What did you expect to see? The dropped/ignored data should be provided in `rest`, or documented otherwise, so users know that some of the data provided to `asn1.Unmarshal` was not included in the resulting struct. Since this is often used alongside `ecdsa.Verify`, the best long term solution would be implement an API similar to the one described in https://github.com/golang/go/issues/20544 that can except an asn1 encoded string and verify it directly, returning 'false' if there is either a parsing issue (ie. some trailing garbage) or if the verification failed. ### What did you see instead? The garbage at the end is simply dropped off and ignored, but not provided in `rest` when returned from `asn1.Unmarshal`. Both of the encoded strings above produce the same struct value without an error or anything in `rest`. This is surprising, as I would expect DER encoding to have a 1:1 relationship between input and output, but also that data is dropped off without being included in rest (as many users likely expect)",1.0,"encoding/asn1: extra elements at the end of a sequence are completely ignored - ### Does this issue reproduce with the latest release? Yes ### What did you do? Appended garbage data (such as zeros, null, etc) to a hex encoded asn1 SEQUENCE type. For example, rather than: `302d021500aa6a258fbf7d90e15614676d377df8b10e38db4a0214496d5220b5f67d3532d1f991203bc3523b964c3b` I provided: `302f021500aa6a258fbf7d90e15614676d377df8b10e38db4a0214496d5220b5f67d3532d1f991203bc3523b964c3b0000` which has a slightly larger length, and some trailing zeros. https://play.golang.org/p/TrwfRC31i1m ### What did you expect to see? The dropped/ignored data should be provided in `rest`, or documented otherwise, so users know that some of the data provided to `asn1.Unmarshal` was not included in the resulting struct. Since this is often used alongside `ecdsa.Verify`, the best long term solution would be implement an API similar to the one described in https://github.com/golang/go/issues/20544 that can except an asn1 encoded string and verify it directly, returning 'false' if there is either a parsing issue (ie. some trailing garbage) or if the verification failed. ### What did you see instead? The garbage at the end is simply dropped off and ignored, but not provided in `rest` when returned from `asn1.Unmarshal`. Both of the encoded strings above produce the same struct value without an error or anything in `rest`. This is surprising, as I would expect DER encoding to have a 1:1 relationship between input and output, but also that data is dropped off without being included in rest (as many users likely expect)",1,encoding extra elements at the end of a sequence are completely ignored does this issue reproduce with the latest release yes what did you do appended garbage data such as zeros null etc to a hex encoded sequence type for example rather than i provided which has a slightly larger length and some trailing zeros what did you expect to see the dropped ignored data should be provided in rest or documented otherwise so users know that some of the data provided to unmarshal was not included in the resulting struct since this is often used alongside ecdsa verify the best long term solution would be implement an api similar to the one described in that can except an encoded string and verify it directly returning false if there is either a parsing issue ie some trailing garbage or if the verification failed what did you see instead the garbage at the end is simply dropped off and ignored but not provided in rest when returned from unmarshal both of the encoded strings above produce the same struct value without an error or anything in rest this is surprising as i would expect der encoding to have a relationship between input and output but also that data is dropped off without being included in rest as many users likely expect ,1 104731,11421061493.0,IssuesEvent,2020-02-03 11:21:17,golang/go,https://api.github.com/repos/golang/go,closed,tour: clarify Buffered Channels,Documentation,"Context: http://127.0.0.1:3999/concurrency/3 Please provide a better explanation. Even after getting it to break I was puzzled. ",1.0,"tour: clarify Buffered Channels - Context: http://127.0.0.1:3999/concurrency/3 Please provide a better explanation. Even after getting it to break I was puzzled. ",1,tour clarify buffered channels context please provide a better explanation even after getting it to break i was puzzled ,1 41021,6887769722.0,IssuesEvent,2017-11-22 01:24:33,golang/go,https://api.github.com/repos/golang/go,closed,"doc: GoLand is misspelled (""Gogland"") at /doc/editors.html",Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? N/A (documentation issue) ### Does this issue reproduce with the latest release? N/A (documentation issue) ### What operating system and processor architecture are you using (`go env`)? N/A (documentation issue) ### 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. ### What did you expect to see? ""GoLand"" ### What did you see instead? ""Gogland"" ",1.0,"doc: GoLand is misspelled (""Gogland"") at /doc/editors.html - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? N/A (documentation issue) ### Does this issue reproduce with the latest release? N/A (documentation issue) ### What operating system and processor architecture are you using (`go env`)? N/A (documentation issue) ### 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. ### What did you expect to see? ""GoLand"" ### What did you see instead? ""Gogland"" ",1,doc goland is misspelled gogland at doc editors html please answer these questions before submitting your issue thanks what version of go are you using go version n a documentation issue does this issue reproduce with the latest release n a documentation issue what operating system and processor architecture are you using go env n a documentation issue 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 what did you expect to see goland what did you see instead gogland ,1 55813,8031414585.0,IssuesEvent,2018-07-28 01:16:06,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: GOMOD env var is not documented,Documentation NeedsFix modules,"### What version of Go are you using (`go version`)? ``` go version devel +4f1f503373 Fri Jul 20 03:30:04 2018 +0000 darwin/amd64 ``` ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN=""/Users/pierre/code/bin"" GOCACHE=""/Users/pierre/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/pierre/go"" GOPROXY="""" GORACE="""" GOROOT=""/usr/local/Cellar/go/HEAD-4f1f503/libexec"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/HEAD-4f1f503/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD="""" 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/7g/98rjcknd3tg687h6z8shgtmr0000gn/T/go-build873031824=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? ``` go help environment ``` ### What did you expect to see? I expected to see some information about the `GOMOD` enviroment variable, which is listed in the output of `go env`. ### What did you see instead? Documentation on many environment variables, but no mention of `GOMOD`: ``` The go command, and the tools it invokes, examine a few different environment variables. For many of these, you can see the default value of on your system by running 'go env NAME', where NAME is the name of the variable. General-purpose environment variables: GCCGO The gccgo command to run for 'go build -compiler=gccgo'. GOARCH The architecture, or processor, for which to compile code. Examples are amd64, 386, arm, ppc64. GOBIN The directory where 'go install' will install a command. GOCACHE The directory where the go command will store cached information for reuse in future builds. GOOS The operating system for which to compile code. Examples are linux, darwin, windows, netbsd. GOPATH For more details see: 'go help gopath'. GOPROXY URL of Go module proxy. See 'go help goproxy'. GORACE Options for the race detector. See https://golang.org/doc/articles/race_detector.html. GOROOT The root of the go tree. GOTMPDIR The directory where the go command will write temporary source files, packages, and binaries. GOTOOLDIR The directory where the go tools (compile, cover, doc, etc...) are installed. This is printed by go env, but setting the environment variable has no effect. Environment variables for use with cgo: CC The command to use to compile C code. CGO_ENABLED Whether the cgo command is supported. Either 0 or 1. CGO_CFLAGS Flags that cgo will pass to the compiler when compiling C code. CGO_CFLAGS_ALLOW A regular expression specifying additional flags to allow to appear in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CFLAGS_DISALLOW A regular expression specifying flags that must be disallowed from appearing in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CPPFLAGS, CGO_CPPFLAGS_ALLOW, CGO_CPPFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C preprocessor. CGO_CXXFLAGS, CGO_CXXFLAGS_ALLOW, CGO_CXXFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C++ compiler. CGO_FFLAGS, CGO_FFLAGS_ALLOW, CGO_FFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the Fortran compiler. CGO_LDFLAGS, CGO_LDFLAGS_ALLOW, CGO_LDFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the linker. CXX The command to use to compile C++ code. PKG_CONFIG Path to pkg-config tool. Architecture-specific environment variables: GOARM For GOARCH=arm, the ARM architecture for which to compile. Valid values are 5, 6, 7. GO386 For GOARCH=386, the floating point instruction set. Valid values are 387, sse2. GOMIPS For GOARCH=mips{,le}, whether to use floating point instructions. Valid values are hardfloat (default), softfloat. GOMIPS64 For GOARCH=mips64{,le}, whether to use floating point instructions. Valid values are hardfloat (default), softfloat. Special-purpose environment variables: GCCGOTOOLDIR If set, where to find gccgo tools, such as cgo. The default is based on how gccgo was configured. GOROOT_FINAL The root of the installed Go tree, when it is installed in a location other than where it is built. File names in stack traces are rewritten from GOROOT to GOROOT_FINAL. GO_EXTLINK_ENABLED Whether the linker should use external linking mode when using -linkmode=auto with code that uses cgo. Set to 0 to disable external linking mode, 1 to enable it. GIT_ALLOW_PROTOCOL Defined by Git. A colon-separated list of schemes that are allowed to be used with git fetch/clone. If set, any scheme not explicitly mentioned will be considered insecure by 'go get'. ``` Thank you!",1.0,"cmd/go: GOMOD env var is not documented - ### What version of Go are you using (`go version`)? ``` go version devel +4f1f503373 Fri Jul 20 03:30:04 2018 +0000 darwin/amd64 ``` ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN=""/Users/pierre/code/bin"" GOCACHE=""/Users/pierre/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/pierre/go"" GOPROXY="""" GORACE="""" GOROOT=""/usr/local/Cellar/go/HEAD-4f1f503/libexec"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/HEAD-4f1f503/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD="""" 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/7g/98rjcknd3tg687h6z8shgtmr0000gn/T/go-build873031824=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? ``` go help environment ``` ### What did you expect to see? I expected to see some information about the `GOMOD` enviroment variable, which is listed in the output of `go env`. ### What did you see instead? Documentation on many environment variables, but no mention of `GOMOD`: ``` The go command, and the tools it invokes, examine a few different environment variables. For many of these, you can see the default value of on your system by running 'go env NAME', where NAME is the name of the variable. General-purpose environment variables: GCCGO The gccgo command to run for 'go build -compiler=gccgo'. GOARCH The architecture, or processor, for which to compile code. Examples are amd64, 386, arm, ppc64. GOBIN The directory where 'go install' will install a command. GOCACHE The directory where the go command will store cached information for reuse in future builds. GOOS The operating system for which to compile code. Examples are linux, darwin, windows, netbsd. GOPATH For more details see: 'go help gopath'. GOPROXY URL of Go module proxy. See 'go help goproxy'. GORACE Options for the race detector. See https://golang.org/doc/articles/race_detector.html. GOROOT The root of the go tree. GOTMPDIR The directory where the go command will write temporary source files, packages, and binaries. GOTOOLDIR The directory where the go tools (compile, cover, doc, etc...) are installed. This is printed by go env, but setting the environment variable has no effect. Environment variables for use with cgo: CC The command to use to compile C code. CGO_ENABLED Whether the cgo command is supported. Either 0 or 1. CGO_CFLAGS Flags that cgo will pass to the compiler when compiling C code. CGO_CFLAGS_ALLOW A regular expression specifying additional flags to allow to appear in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CFLAGS_DISALLOW A regular expression specifying flags that must be disallowed from appearing in #cgo CFLAGS source code directives. Does not apply to the CGO_CFLAGS environment variable. CGO_CPPFLAGS, CGO_CPPFLAGS_ALLOW, CGO_CPPFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C preprocessor. CGO_CXXFLAGS, CGO_CXXFLAGS_ALLOW, CGO_CXXFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the C++ compiler. CGO_FFLAGS, CGO_FFLAGS_ALLOW, CGO_FFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the Fortran compiler. CGO_LDFLAGS, CGO_LDFLAGS_ALLOW, CGO_LDFLAGS_DISALLOW Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW, but for the linker. CXX The command to use to compile C++ code. PKG_CONFIG Path to pkg-config tool. Architecture-specific environment variables: GOARM For GOARCH=arm, the ARM architecture for which to compile. Valid values are 5, 6, 7. GO386 For GOARCH=386, the floating point instruction set. Valid values are 387, sse2. GOMIPS For GOARCH=mips{,le}, whether to use floating point instructions. Valid values are hardfloat (default), softfloat. GOMIPS64 For GOARCH=mips64{,le}, whether to use floating point instructions. Valid values are hardfloat (default), softfloat. Special-purpose environment variables: GCCGOTOOLDIR If set, where to find gccgo tools, such as cgo. The default is based on how gccgo was configured. GOROOT_FINAL The root of the installed Go tree, when it is installed in a location other than where it is built. File names in stack traces are rewritten from GOROOT to GOROOT_FINAL. GO_EXTLINK_ENABLED Whether the linker should use external linking mode when using -linkmode=auto with code that uses cgo. Set to 0 to disable external linking mode, 1 to enable it. GIT_ALLOW_PROTOCOL Defined by Git. A colon-separated list of schemes that are allowed to be used with git fetch/clone. If set, any scheme not explicitly mentioned will be considered insecure by 'go get'. ``` Thank you!",1,cmd go gomod env var is not documented what version of go are you using go version go version devel fri jul darwin does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env goarch gobin users pierre code bin gocache users pierre library caches go build goexe gohostarch gohostos darwin goos darwin gopath users pierre go goproxy gorace goroot usr local cellar go head libexec gotmpdir gotooldir usr local cellar go head libexec pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do go help environment what did you expect to see i expected to see some information about the gomod enviroment variable which is listed in the output of go env what did you see instead documentation on many environment variables but no mention of gomod the go command and the tools it invokes examine a few different environment variables for many of these you can see the default value of on your system by running go env name where name is the name of the variable general purpose environment variables gccgo the gccgo command to run for go build compiler gccgo goarch the architecture or processor for which to compile code examples are arm gobin the directory where go install will install a command gocache the directory where the go command will store cached information for reuse in future builds goos the operating system for which to compile code examples are linux darwin windows netbsd gopath for more details see go help gopath goproxy url of go module proxy see go help goproxy gorace options for the race detector see goroot the root of the go tree gotmpdir the directory where the go command will write temporary source files packages and binaries gotooldir the directory where the go tools compile cover doc etc are installed this is printed by go env but setting the environment variable has no effect environment variables for use with cgo cc the command to use to compile c code cgo enabled whether the cgo command is supported either or cgo cflags flags that cgo will pass to the compiler when compiling c code cgo cflags allow a regular expression specifying additional flags to allow to appear in cgo cflags source code directives does not apply to the cgo cflags environment variable cgo cflags disallow a regular expression specifying flags that must be disallowed from appearing in cgo cflags source code directives does not apply to the cgo cflags environment variable cgo cppflags cgo cppflags allow cgo cppflags disallow like cgo cflags cgo cflags allow and cgo cflags disallow but for the c preprocessor cgo cxxflags cgo cxxflags allow cgo cxxflags disallow like cgo cflags cgo cflags allow and cgo cflags disallow but for the c compiler cgo fflags cgo fflags allow cgo fflags disallow like cgo cflags cgo cflags allow and cgo cflags disallow but for the fortran compiler cgo ldflags cgo ldflags allow cgo ldflags disallow like cgo cflags cgo cflags allow and cgo cflags disallow but for the linker cxx the command to use to compile c code pkg config path to pkg config tool architecture specific environment variables goarm for goarch arm the arm architecture for which to compile valid values are for goarch the floating point instruction set valid values are gomips for goarch mips le whether to use floating point instructions valid values are hardfloat default softfloat for goarch le whether to use floating point instructions valid values are hardfloat default softfloat special purpose environment variables gccgotooldir if set where to find gccgo tools such as cgo the default is based on how gccgo was configured goroot final the root of the installed go tree when it is installed in a location other than where it is built file names in stack traces are rewritten from goroot to goroot final go extlink enabled whether the linker should use external linking mode when using linkmode auto with code that uses cgo set to to disable external linking mode to enable it git allow protocol defined by git a colon separated list of schemes that are allowed to be used with git fetch clone if set any scheme not explicitly mentioned will be considered insecure by go get thank you ,1 361577,25344101415.0,IssuesEvent,2022-11-19 02:32:39,golang/go,https://api.github.com/repos/golang/go,closed,net/http: Server.Serve returns an error when the Listener is closed,Documentation,"net/http.Server.Serve returns an error when the Listener argument is closed, which means you cannot gracefully stop the server (no error returned). It should instead check if the Listener is closed and return nil if so. ",1.0,"net/http: Server.Serve returns an error when the Listener is closed - net/http.Server.Serve returns an error when the Listener argument is closed, which means you cannot gracefully stop the server (no error returned). It should instead check if the Listener is closed and return nil if so. ",1,net http server serve returns an error when the listener is closed net http server serve returns an error when the listener argument is closed which means you cannot gracefully stop the server no error returned it should instead check if the listener is closed and return nil if so ,1 29393,4500340280.0,IssuesEvent,2016-09-01 03:59:25,golang/go,https://api.github.com/repos/golang/go,closed,net/http: flaky TestH12_RequestContentLength_Known_NonZero,Testing,"Just noticed: https://build.golang.org/log/31bace9ed1c8e96d66019498ea7538fe78cddedd ``` ... --- FAIL: TestH12_RequestContentLength_Known_NonZero (0.00s) clientserver_test.go:185: HTTP/2 request: Post https://127.0.0.1:56615: http2: stream closed FAIL FAIL net/http 9.285s ... ``` Maybe it's another case of #16029 in which case this test could just be made more robust. ",1.0,"net/http: flaky TestH12_RequestContentLength_Known_NonZero - Just noticed: https://build.golang.org/log/31bace9ed1c8e96d66019498ea7538fe78cddedd ``` ... --- FAIL: TestH12_RequestContentLength_Known_NonZero (0.00s) clientserver_test.go:185: HTTP/2 request: Post https://127.0.0.1:56615: http2: stream closed FAIL FAIL net/http 9.285s ... ``` Maybe it's another case of #16029 in which case this test could just be made more robust. ",0,net http flaky requestcontentlength known nonzero just noticed fail requestcontentlength known nonzero clientserver test go http request post stream closed fail fail net http maybe it s another case of in which case this test could just be made more robust ,0 154191,13540661399.0,IssuesEvent,2020-09-16 14:55:42,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: revise 'go help' documentation for modules and module-aware commands,Documentation NeedsFix modules,"`go help modules` (and equivalently https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) is the original reference page for modules. It's fairly long for an introduction, but at the same time, it doesn't go into enough detail or provide enough examples to be a thorough reference. https://golang.org/ref/mod is intended to replace `go help modules` as a detailed reference. In Go 1.16, we should change `go help modules` to point to that. A few other help pages have this problem, in particular, `go help module-get` (https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them). The help page for each command should provide a brief synopsis of its arguments and flags, then should point to reference documentation like https://golang.org/ref/mod#go-get for more detail.",1.0,"cmd/go: revise 'go help' documentation for modules and module-aware commands - `go help modules` (and equivalently https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) is the original reference page for modules. It's fairly long for an introduction, but at the same time, it doesn't go into enough detail or provide enough examples to be a thorough reference. https://golang.org/ref/mod is intended to replace `go help modules` as a detailed reference. In Go 1.16, we should change `go help modules` to point to that. A few other help pages have this problem, in particular, `go help module-get` (https://golang.org/cmd/go/#hdr-Add_dependencies_to_current_module_and_install_them). The help page for each command should provide a brief synopsis of its arguments and flags, then should point to reference documentation like https://golang.org/ref/mod#go-get for more detail.",1,cmd go revise go help documentation for modules and module aware commands go help modules and equivalently is the original reference page for modules it s fairly long for an introduction but at the same time it doesn t go into enough detail or provide enough examples to be a thorough reference is intended to replace go help modules as a detailed reference in go we should change go help modules to point to that a few other help pages have this problem in particular go help module get the help page for each command should provide a brief synopsis of its arguments and flags then should point to reference documentation like for more detail ,1 317007,23660113774.0,IssuesEvent,2022-08-26 14:48:31,golang/go,https://api.github.com/repos/golang/go,closed,all: function documentation rendering error,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/shuang/Library/Caches/go-build""
GOENV=""/Users/shuang/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/shuang/.go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/shuang/.go""
GOPRIVATE=""""
GOPROXY=""https://goproxy.cn,direct""
GOROOT=""/usr/local/Cellar/go/1.19/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.19/libexec/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.19""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1y/2t35nccn4tg5pzrjyx6bgjhw0000gn/T/go-build1994239392=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://github.com/golang/vscode-go/issues/2423 ### What did you expect to see? Function documentation should be displayed normally, without red characters. ### What did you see instead? All characters after 's are red. ",1.0,"all: function documentation rendering error - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/shuang/Library/Caches/go-build""
GOENV=""/Users/shuang/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/shuang/.go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/shuang/.go""
GOPRIVATE=""""
GOPROXY=""https://goproxy.cn,direct""
GOROOT=""/usr/local/Cellar/go/1.19/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.19/libexec/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.19""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1y/2t35nccn4tg5pzrjyx6bgjhw0000gn/T/go-build1994239392=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://github.com/golang/vscode-go/issues/2423 ### What did you expect to see? Function documentation should be displayed normally, without red characters. ### What did you see instead? All characters after 's are red. ",1,all function documentation rendering error please answer these questions before submitting your issue thanks what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users shuang library caches go build goenv users shuang library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users shuang go pkg mod gonoproxy gonosumdb goos darwin gopath users shuang go goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best what did you expect to see function documentation should be displayed normally without red characters what did you see instead all characters after s are red ,1 310453,26717765501.0,IssuesEvent,2023-01-28 18:51:46,golang/go,https://api.github.com/repos/golang/go,closed,os: TestOneDrive fails on Windows if OneDrive PATH needs expansion,Testing OS-Windows NeedsFix,"I'm setting up a new development environment on a Windows machine. After initial setup I ran `all.bat` and the compilation succeeded, but the tests failed with: ``` --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 28.760s ``` For the sake of time saving, the same test can be run with `go tool dist test`: ``` > go tool dist test -run=^go_test:os$ ##### Test execution environment. # GOARCH: amd64 # CPU: Intel(R) Xeon(R) CPU E3-1565L v5 @ 2.50GHz # GOOS: windows # OS Version: 10.0.14393 ##### Testing packages. --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 9.265s FAIL go tool dist: Failed: exit status 1 ``` I traced the problem to the `findOneDriveDir` helper function: https://github.com/golang/go/blob/9955a7e9bb40d28502fbb8fd6ef1f2f10e18a519/src/os/os_windows_test.go#L877-L881 In line 877 we get the value of the registry key and return it in 881, but if the registry value is of type EXPAND_SZ it needs further expansion as documented in https://pkg.go.dev/golang.org/x/sys/windows/registry#ExpandString. In my case, `%UserProfile%` needs expansion. The fix is simply calling registry.ExpandString on the resulting path. I'm preparing a PR for submission later today. ### What version of Go are you using (`go version`)? ``` > go version go version go1.19.2 windows/amd64 ``` ### Does this issue reproduce with the latest release? Yes, considering this is a test bug and I'm running the latest version of the tests. ### What operating system and processor architecture are you using (`go env`)? ``` GOOS=windows GOARCH=amd64 ``` ### What did you do? ``` $ git clone https://go.googlesource.com/go $ cd go\src $ all.bat ``` ### What did you expect to see? ``` ALL TESTS PASSED ``` ### What did you see instead? (other text omitted for brevity) ``` --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 28.760s ``` ",1.0,"os: TestOneDrive fails on Windows if OneDrive PATH needs expansion - I'm setting up a new development environment on a Windows machine. After initial setup I ran `all.bat` and the compilation succeeded, but the tests failed with: ``` --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 28.760s ``` For the sake of time saving, the same test can be run with `go tool dist test`: ``` > go tool dist test -run=^go_test:os$ ##### Test execution environment. # GOARCH: amd64 # CPU: Intel(R) Xeon(R) CPU E3-1565L v5 @ 2.50GHz # GOOS: windows # OS Version: 10.0.14393 ##### Testing packages. --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 9.265s FAIL go tool dist: Failed: exit status 1 ``` I traced the problem to the `findOneDriveDir` helper function: https://github.com/golang/go/blob/9955a7e9bb40d28502fbb8fd6ef1f2f10e18a519/src/os/os_windows_test.go#L877-L881 In line 877 we get the value of the registry key and return it in 881, but if the registry value is of type EXPAND_SZ it needs further expansion as documented in https://pkg.go.dev/golang.org/x/sys/windows/registry#ExpandString. In my case, `%UserProfile%` needs expansion. The fix is simply calling registry.ExpandString on the resulting path. I'm preparing a PR for submission later today. ### What version of Go are you using (`go version`)? ``` > go version go version go1.19.2 windows/amd64 ``` ### Does this issue reproduce with the latest release? Yes, considering this is a test bug and I'm running the latest version of the tests. ### What operating system and processor architecture are you using (`go env`)? ``` GOOS=windows GOARCH=amd64 ``` ### What did you do? ``` $ git clone https://go.googlesource.com/go $ cd go\src $ all.bat ``` ### What did you expect to see? ``` ALL TESTS PASSED ``` ### What did you see instead? (other text omitted for brevity) ``` --- FAIL: TestOneDrive (0.00s) stat_test.go:21: CreateFile %UserProfile%\OneDrive: The system cannot find the path specified. FAIL FAIL os 28.760s ``` ",0,os testonedrive fails on windows if onedrive path needs expansion i m setting up a new development environment on a windows machine after initial setup i ran all bat and the compilation succeeded but the tests failed with fail testonedrive stat test go createfile userprofile onedrive the system cannot find the path specified fail fail os for the sake of time saving the same test can be run with go tool dist test go tool dist test run go test os test execution environment goarch cpu intel r xeon r cpu goos windows os version testing packages fail testonedrive stat test go createfile userprofile onedrive the system cannot find the path specified fail fail os fail go tool dist failed exit status i traced the problem to the findonedrivedir helper function in line we get the value of the registry key and return it in but if the registry value is of type expand sz it needs further expansion as documented in in my case userprofile needs expansion the fix is simply calling registry expandstring on the resulting path i m preparing a pr for submission later today what version of go are you using go version go version go version windows does this issue reproduce with the latest release yes considering this is a test bug and i m running the latest version of the tests what operating system and processor architecture are you using go env goos windows goarch what did you do git clone cd go src all bat what did you expect to see all tests passed what did you see instead other text omitted for brevity fail testonedrive stat test go createfile userprofile onedrive the system cannot find the path specified fail fail os ,0 6158,3004573822.0,IssuesEvent,2015-07-26 02:57:27,golang/go,https://api.github.com/repos/golang/go,closed,crypto/rand: Reader docs say /dev/urandom but really uses getrandom(2) on Linux when available,Documentation,"> On Unix-like systems, Reader reads from /dev/urandom. It has been improved since, and is better than that. The docs should reflect this. ",1.0,"crypto/rand: Reader docs say /dev/urandom but really uses getrandom(2) on Linux when available - > On Unix-like systems, Reader reads from /dev/urandom. It has been improved since, and is better than that. The docs should reflect this. ",1,crypto rand reader docs say dev urandom but really uses getrandom on linux when available on unix like systems reader reads from dev urandom it has been improved since and is better than that the docs should reflect this ,1 312305,23422910514.0,IssuesEvent,2022-08-14 00:42:38,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Installing Go from source page does not mention loong instruction set,Documentation NeedsFix website,"At https://go.dev/doc/install/source ``` The Go compilers support the following instruction sets: amd64, 386 The x86 instruction set, 64- and 32-bit. arm64, arm The ARM instruction set, 64-bit (AArch64) and 32-bit. mips64, mips64le, mips, mipsle The MIPS instruction set, big- and little-endian, 64- and 32-bit. ppc64, ppc64le The 64-bit PowerPC instruction set, big- and little-endian. riscv64 The 64-bit RISC-V instruction set. s390x The IBM z/Architecture. wasm WebAssembly. ``` Is missing a mention of `loong64`. Also it says ""the Go compiler**s**"" but the plural seems wrong, the page is about `gc` which is usually called ""the Go compiler"".",1.0,"x/website: Installing Go from source page does not mention loong instruction set - At https://go.dev/doc/install/source ``` The Go compilers support the following instruction sets: amd64, 386 The x86 instruction set, 64- and 32-bit. arm64, arm The ARM instruction set, 64-bit (AArch64) and 32-bit. mips64, mips64le, mips, mipsle The MIPS instruction set, big- and little-endian, 64- and 32-bit. ppc64, ppc64le The 64-bit PowerPC instruction set, big- and little-endian. riscv64 The 64-bit RISC-V instruction set. s390x The IBM z/Architecture. wasm WebAssembly. ``` Is missing a mention of `loong64`. Also it says ""the Go compiler**s**"" but the plural seems wrong, the page is about `gc` which is usually called ""the Go compiler"".",1,x website installing go from source page does not mention loong instruction set at the go compilers support the following instruction sets the instruction set and bit arm the arm instruction set bit and bit mips mipsle the mips instruction set big and little endian and bit the bit powerpc instruction set big and little endian the bit risc v instruction set the ibm z architecture wasm webassembly is missing a mention of also it says the go compiler s but the plural seems wrong the page is about gc which is usually called the go compiler ,1 11551,7603592552.0,IssuesEvent,2018-04-29 16:06:13,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile : detect bounded shifts of the form (bits-var) in prove,Performance,"This is a reminder issue for a suggestion in the review of CL 109776: https://go-review.googlesource.com/c/go/+/109776/1/src/cmd/compile/internal/ssa/prove.go#797. ",True,"cmd/compile : detect bounded shifts of the form (bits-var) in prove - This is a reminder issue for a suggestion in the review of CL 109776: https://go-review.googlesource.com/c/go/+/109776/1/src/cmd/compile/internal/ssa/prove.go#797. ",0,cmd compile detect bounded shifts of the form bits var in prove this is a reminder issue for a suggestion in the review of cl ,0 7151,3081299435.0,IssuesEvent,2015-08-22 15:39:45,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: compile tool identifies itself as 6g,Documentation,"``` % go tool compile -XXX | head -n2 flag provided but not defined: -XXX usage: 6g [options] file.go... -% debug non-static initializers ```",1.0,"cmd/compile: compile tool identifies itself as 6g - ``` % go tool compile -XXX | head -n2 flag provided but not defined: -XXX usage: 6g [options] file.go... -% debug non-static initializers ```",1,cmd compile compile tool identifies itself as go tool compile xxx head flag provided but not defined xxx usage file go debug non static initializers ,1 161536,13851987200.0,IssuesEvent,2020-10-15 05:30:59,golang/go,https://api.github.com/repos/golang/go,closed,"reflect: documentation about ""Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer"" is misleading",Documentation NeedsInvestigation WaitingForInfo,"The document about ""Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer"" is misleading. ``` var s string hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)) // case 1 hdr.Data = uintptr(unsafe.Pointer(p)) // case 6 (this case) hdr.Len = n ``` It would be great if the doc specifies one more time the risk of the code below: ``` hdr.Data = uintptr(unsafe.Pointer(p)) ``` When p point to a temporary memory, we will have problem. For example, ``` func demo(val_copy int64) *reflect.StringHeader { var s string hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)) // case 1 hdr.Data = uintptr(unsafe.Pointer(&val_copy)) // case 6 (this case) hdr.Len = 8 return hdr } func main() { val := int64(0xab) hdr := demo(val) s := *(*string)(unsafe.Pointer(hdr)) fmt.Printf(""%x"", s) } ``` The tricky thing is, it's often that the output is the same as expectation. But this is a bug because &val_copy is not referenced by others except uintptr, hence the content of the memory pointed by &val_copy is undefined after the demo function returned.",1.0,"reflect: documentation about ""Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer"" is misleading - The document about ""Conversion of a reflect.SliceHeader or reflect.StringHeader Data field to or from Pointer"" is misleading. ``` var s string hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)) // case 1 hdr.Data = uintptr(unsafe.Pointer(p)) // case 6 (this case) hdr.Len = n ``` It would be great if the doc specifies one more time the risk of the code below: ``` hdr.Data = uintptr(unsafe.Pointer(p)) ``` When p point to a temporary memory, we will have problem. For example, ``` func demo(val_copy int64) *reflect.StringHeader { var s string hdr := (*reflect.StringHeader)(unsafe.Pointer(&s)) // case 1 hdr.Data = uintptr(unsafe.Pointer(&val_copy)) // case 6 (this case) hdr.Len = 8 return hdr } func main() { val := int64(0xab) hdr := demo(val) s := *(*string)(unsafe.Pointer(hdr)) fmt.Printf(""%x"", s) } ``` The tricky thing is, it's often that the output is the same as expectation. But this is a bug because &val_copy is not referenced by others except uintptr, hence the content of the memory pointed by &val_copy is undefined after the demo function returned.",1,reflect documentation about conversion of a reflect sliceheader or reflect stringheader data field to or from pointer is misleading the document about conversion of a reflect sliceheader or reflect stringheader data field to or from pointer is misleading var s string hdr reflect stringheader unsafe pointer s case hdr data uintptr unsafe pointer p case this case hdr len n it would be great if the doc specifies one more time the risk of the code below hdr data uintptr unsafe pointer p when p point to a temporary memory we will have problem for example func demo val copy reflect stringheader var s string hdr reflect stringheader unsafe pointer s case hdr data uintptr unsafe pointer val copy case this case hdr len return hdr func main val hdr demo val s string unsafe pointer hdr fmt printf x s the tricky thing is it s often that the output is the same as expectation but this is a bug because val copy is not referenced by others except uintptr hence the content of the memory pointed by val copy is undefined after the demo function returned ,1 28530,5512073658.0,IssuesEvent,2017-03-17 08:10:02,golang/go,https://api.github.com/repos/golang/go,closed,doc: Golang FAQ on go get versioning needs updating,Documentation,It should be updated to reflect that the behaviour exposed via GO15VENDOREXPERIMENT=1 is now the default behaviour of the go command. Perhaps also include something about future plans (`dep`)?,1.0,doc: Golang FAQ on go get versioning needs updating - It should be updated to reflect that the behaviour exposed via GO15VENDOREXPERIMENT=1 is now the default behaviour of the go command. Perhaps also include something about future plans (`dep`)?,1,doc golang faq on go get versioning needs updating it should be updated to reflect that the behaviour exposed via is now the default behaviour of the go command perhaps also include something about future plans dep ,1 36174,6517982771.0,IssuesEvent,2017-08-28 05:12:23,golang/go,https://api.github.com/repos/golang/go,closed,fmt: improve documentation about how verbs work when printing pointers,Documentation NeedsDecision,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.9rc2 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" ### What did you do? https://play.golang.org/p/k89vjAT5Kt package main import ( ""fmt"" ) func main() { i := 37 p := &i fmt.Printf(""Why: %d"", p) } ### What did you expect to see? I expected to see some sort of error / warning about the implicit conversion of a pointer type into an integer format verb %d. I expected the computer to help me catch the mistake of not derefrencing p to get the expected integer. ### What did you see instead? No error or warning, and the output contains the address of the pointer printed in base10. ",1.0,"fmt: improve documentation about how verbs work when printing pointers - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.9rc2 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" ### What did you do? https://play.golang.org/p/k89vjAT5Kt package main import ( ""fmt"" ) func main() { i := 37 p := &i fmt.Printf(""Why: %d"", p) } ### What did you expect to see? I expected to see some sort of error / warning about the implicit conversion of a pointer type into an integer format verb %d. I expected the computer to help me catch the mistake of not derefrencing p to get the expected integer. ### What did you see instead? No error or warning, and the output contains the address of the pointer printed in base10. ",1,fmt improve documentation about how verbs work when printing pointers please answer these questions before submitting your issue thanks what version of go are you using go version linux what operating system and processor architecture are you using go env gohostarch gohostos linux what did you do package main import fmt func main i p i fmt printf why d p what did you expect to see i expected to see some sort of error warning about the implicit conversion of a pointer type into an integer format verb d i expected the computer to help me catch the mistake of not derefrencing p to get the expected integer what did you see instead no error or warning and the output contains the address of the pointer printed in ,1 25814,5200586468.0,IssuesEvent,2017-01-24 00:28:54,golang/go,https://api.github.com/repos/golang/go,closed,testing: document MainStart signature change in release notes,Documentation NeedsFix,"c56cc9b3b5727647c2afb3d57f5793151558a0a7 (https://golang.org/cl/32455) changed the signature of testing.MainStart from: https://golang.org/pkg/testing/#MainStart ``` func MainStart(matchString func(pat, str string) (bool, error), tests []InternalTest, benchmarks []InternalBenchmark, examples []InternalExample) *M ``` To: https://beta.golang.org/pkg/testing/#MainStart ``` func MainStart(deps testDeps, tests []InternalTest, benchmarks []InternalBenchmark, examples []InternalExample) *M ``` This is not in our release notes, and just bit Kubernetes in https://github.com/kubernetes/kubernetes/pull/38926#issuecomment-274627297 For the record, this does say: > It is not meant to be called directly and is not subject to the Go 1 compatibility document. It may change signature from release to release. /cc @rsc ",1.0,"testing: document MainStart signature change in release notes - c56cc9b3b5727647c2afb3d57f5793151558a0a7 (https://golang.org/cl/32455) changed the signature of testing.MainStart from: https://golang.org/pkg/testing/#MainStart ``` func MainStart(matchString func(pat, str string) (bool, error), tests []InternalTest, benchmarks []InternalBenchmark, examples []InternalExample) *M ``` To: https://beta.golang.org/pkg/testing/#MainStart ``` func MainStart(deps testDeps, tests []InternalTest, benchmarks []InternalBenchmark, examples []InternalExample) *M ``` This is not in our release notes, and just bit Kubernetes in https://github.com/kubernetes/kubernetes/pull/38926#issuecomment-274627297 For the record, this does say: > It is not meant to be called directly and is not subject to the Go 1 compatibility document. It may change signature from release to release. /cc @rsc ",1,testing document mainstart signature change in release notes changed the signature of testing mainstart from func mainstart matchstring func pat str string bool error tests internaltest benchmarks internalbenchmark examples internalexample m to func mainstart deps testdeps tests internaltest benchmarks internalbenchmark examples internalexample m this is not in our release notes and just bit kubernetes in for the record this does say it is not meant to be called directly and is not subject to the go compatibility document it may change signature from release to release cc rsc ,1 38802,6705554891.0,IssuesEvent,2017-10-12 01:03:48,golang/go,https://api.github.com/repos/golang/go,closed,all: can't build go1.4,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? n/a ### What operating system and processor architecture are you using (`go env`)? Arch Linux 64bit ``` ➤ gcc --version gcc (GCC) 7.1.1 20170630 ➤ clang --version clang version 4.0.1 (tags/RELEASE_401/final) ``` ### What did you do? ``` ➤ git clone https://github.com/golang/go ➤ git checkout release-branch.go1.4 ➤ cd src && ./make.bash ➤ env CC=clang ./make.bash ``` ### What did you expect to see? Working go1.4 ### What did you see instead? Can't compile it with neither clang nor gcc. With clang: ``` /usr/bin/ld: -r and -pie may not be used together clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation) ``` And with gcc: ``` os/user # net cannot load DWARF output from $WORK/net/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0 # os/user cannot load DWARF output from $WORK/os/user/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0 ``` https://gist.github.com/OneOfOne/a9116d4c85c32141282fcf9a2973fbd2 Discovered while trying to diagnose #21042 ",1.0,"all: can't build go1.4 - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? n/a ### What operating system and processor architecture are you using (`go env`)? Arch Linux 64bit ``` ➤ gcc --version gcc (GCC) 7.1.1 20170630 ➤ clang --version clang version 4.0.1 (tags/RELEASE_401/final) ``` ### What did you do? ``` ➤ git clone https://github.com/golang/go ➤ git checkout release-branch.go1.4 ➤ cd src && ./make.bash ➤ env CC=clang ./make.bash ``` ### What did you expect to see? Working go1.4 ### What did you see instead? Can't compile it with neither clang nor gcc. With clang: ``` /usr/bin/ld: -r and -pie may not be used together clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation) ``` And with gcc: ``` os/user # net cannot load DWARF output from $WORK/net/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0 # os/user cannot load DWARF output from $WORK/os/user/_obj//_cgo_.o: decoding dwarf section info at offset 0x4: unsupported version 0 ``` https://gist.github.com/OneOfOne/a9116d4c85c32141282fcf9a2973fbd2 Discovered while trying to diagnose #21042 ",1,all can t build please answer these questions before submitting your issue thanks what version of go are you using go version n a what operating system and processor architecture are you using go env arch linux ➤ gcc version gcc gcc ➤ clang version clang version tags release final what did you do ➤ git clone ➤ git checkout release branch ➤ cd src make bash ➤ env cc clang make bash what did you expect to see working what did you see instead can t compile it with neither clang nor gcc with clang usr bin ld r and pie may not be used together clang error linker command failed with exit code use v to see invocation and with gcc os user net cannot load dwarf output from work net obj cgo o decoding dwarf section info at offset unsupported version os user cannot load dwarf output from work os user obj cgo o decoding dwarf section info at offset unsupported version discovered while trying to diagnose ,1 48578,7444787440.0,IssuesEvent,2018-03-28 00:31:51,golang/go,https://api.github.com/repos/golang/go,closed,regexp: document that in *All if n < 0 means return all matches,Documentation help wanted,"I was just working on a simple login router and while examining regexp.FindAllString, I had to use the common knowledge that usually when you ask for n<0, that means return all the matches. However, this isn't intuitive to everyone. Perhaps let's document it. Sharing this with my other team members who might not be experienced would definitely lead to confusion as in https://play.golang.org/p/5J4Me7dgNML",1.0,"regexp: document that in *All if n < 0 means return all matches - I was just working on a simple login router and while examining regexp.FindAllString, I had to use the common knowledge that usually when you ask for n<0, that means return all the matches. However, this isn't intuitive to everyone. Perhaps let's document it. Sharing this with my other team members who might not be experienced would definitely lead to confusion as in https://play.golang.org/p/5J4Me7dgNML",1,regexp document that in all if n means return all matches i was just working on a simple login router and while examining regexp findallstring i had to use the common knowledge that usually when you ask for n that means return all the matches however this isn t intuitive to everyone perhaps let s document it img width alt screen shot at pm src sharing this with my other team members who might not be experienced would definitely lead to confusion as in ,1 148764,11864198350.0,IssuesEvent,2020-03-25 21:11:14,golang/go,https://api.github.com/repos/golang/go,closed,cmd/internal/obj: failed TestPCALIGN at read only GOROOT,NeedsInvestigation Testing,"The linux-mengzhuo-mips64le builder has set goroot as read-only after build completed. https://build.golang.org/log/97aac799817dbca76dda86e7df6fb044cf1a92fa git bisect that [CL 207117](https://go-review.googlesource.com/c/go/+/207117) runs `go tool asm -S test.s` without clarified the outfile to tmp path.",1.0,"cmd/internal/obj: failed TestPCALIGN at read only GOROOT - The linux-mengzhuo-mips64le builder has set goroot as read-only after build completed. https://build.golang.org/log/97aac799817dbca76dda86e7df6fb044cf1a92fa git bisect that [CL 207117](https://go-review.googlesource.com/c/go/+/207117) runs `go tool asm -S test.s` without clarified the outfile to tmp path.",0,cmd internal obj failed testpcalign at read only goroot the linux mengzhuo builder has set goroot as read only after build completed git bisect that runs go tool asm s test s without clarified the outfile to tmp path ,0 264425,20020124049.0,IssuesEvent,2022-02-01 15:41:11,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: spelling error,Documentation NeedsFix release-blocker," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18beta2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
### What did you do? run `go1.18beta2 work` and it shows help: ``` Go workspace provides access to operations on workspaces. Note that support for workspaces is built into many other commands, not just 'go work'. See 'go help modules' for information about Go's module system of which workspaces are a part. A workspace is specified by a go.work file that specifies a set of module directories with the ""use"" directive. These modules are used as root modules by the go command for builds and related operations. A workspace that does not specify modules to be used cannot be used to do builds from local modules. go.work files are line-oriented. Each line holds a single directive, made up of a keyword followed by aruments. For example: ... ``` In the last line of the above, `aruments` is spelled wrong https://github.com/golang/go/blob/master/src/cmd/go/internal/workcmd/work.go#L30 ### What did you expect to see? `aruments` should be `arguments` ",1.0,"cmd/go: spelling error - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18beta2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
### What did you do? run `go1.18beta2 work` and it shows help: ``` Go workspace provides access to operations on workspaces. Note that support for workspaces is built into many other commands, not just 'go work'. See 'go help modules' for information about Go's module system of which workspaces are a part. A workspace is specified by a go.work file that specifies a set of module directories with the ""use"" directive. These modules are used as root modules by the go command for builds and related operations. A workspace that does not specify modules to be used cannot be used to do builds from local modules. go.work files are line-oriented. Each line holds a single directive, made up of a keyword followed by aruments. For example: ... ``` In the last line of the above, `aruments` is spelled wrong https://github.com/golang/go/blob/master/src/cmd/go/internal/workcmd/work.go#L30 ### What did you expect to see? `aruments` should be `arguments` ",1,cmd go spelling error please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best run work and it shows help go workspace provides access to operations on workspaces note that support for workspaces is built into many other commands not just go work see go help modules for information about go s module system of which workspaces are a part a workspace is specified by a go work file that specifies a set of module directories with the use directive these modules are used as root modules by the go command for builds and related operations a workspace that does not specify modules to be used cannot be used to do builds from local modules go work files are line oriented each line holds a single directive made up of a keyword followed by aruments for example in the last line of the above aruments is spelled wrong what did you expect to see aruments should be arguments ,1 229855,25384364485.0,IssuesEvent,2022-11-21 20:27:18,golang/go,https://api.github.com/repos/golang/go,reopened,"archive/tar, archive/zip: add ErrInsecurePath",Security Proposal Proposal-Accepted Proposal-FinalCommentPeriod,"This is an alternative fix for #25849, as proposed by @dsnet in https://github.com/golang/go/issues/25849#issuecomment-396685881. The `archive/tar` and `archive/zip` readers return unsanitized paths from archives. Careless use of these paths leads to path traversal attacks. * [CVE-2018-25046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25046) * [CVE-2020-36560](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36560) * [CVE-2020-36561](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36561) * [CVE-2021-21272](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21272) * [CVE-2020-36566](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36566) * Probably a bunch more. Proposal: An insecure filename is an absolute path, or a path containing a relative path component (`../`). When `tar.Reader.Next` reads a file with an insecure filename, it returns `tar.ErrInsecurePath`. When `zip.NewReader` opens an archive containing an insecure filename, it returns `zip.ErrInsecurePath`. In both cases, the function also returns a usable object (a `*tar.Header` or `*zip.Reader`). In the case where the caller wants to handle archives with insecure filenames, they may ignore the `ErrInsecurePath` error and perform whatever sanitization they find appropriate. If the caller takes no action, they get an error when processing an unsafe archive. The advantage over automatically sanitizing filenames is that we don't silently change the semantics of archives. A tar archive may legitimately contain absolute path names; silently converting these to relative names seems more surprising than reporting an error. In addition, there isn't always an obvious sanitized name--we probably want to reject the name `COM1` on Windows, but what would we rewrite it into?",True,"archive/tar, archive/zip: add ErrInsecurePath - This is an alternative fix for #25849, as proposed by @dsnet in https://github.com/golang/go/issues/25849#issuecomment-396685881. The `archive/tar` and `archive/zip` readers return unsanitized paths from archives. Careless use of these paths leads to path traversal attacks. * [CVE-2018-25046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-25046) * [CVE-2020-36560](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36560) * [CVE-2020-36561](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36561) * [CVE-2021-21272](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21272) * [CVE-2020-36566](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-36566) * Probably a bunch more. Proposal: An insecure filename is an absolute path, or a path containing a relative path component (`../`). When `tar.Reader.Next` reads a file with an insecure filename, it returns `tar.ErrInsecurePath`. When `zip.NewReader` opens an archive containing an insecure filename, it returns `zip.ErrInsecurePath`. In both cases, the function also returns a usable object (a `*tar.Header` or `*zip.Reader`). In the case where the caller wants to handle archives with insecure filenames, they may ignore the `ErrInsecurePath` error and perform whatever sanitization they find appropriate. If the caller takes no action, they get an error when processing an unsafe archive. The advantage over automatically sanitizing filenames is that we don't silently change the semantics of archives. A tar archive may legitimately contain absolute path names; silently converting these to relative names seems more surprising than reporting an error. In addition, there isn't always an obvious sanitized name--we probably want to reject the name `COM1` on Windows, but what would we rewrite it into?",0,archive tar archive zip add errinsecurepath this is an alternative fix for as proposed by dsnet in the archive tar and archive zip readers return unsanitized paths from archives careless use of these paths leads to path traversal attacks probably a bunch more proposal an insecure filename is an absolute path or a path containing a relative path component when tar reader next reads a file with an insecure filename it returns tar errinsecurepath when zip newreader opens an archive containing an insecure filename it returns zip errinsecurepath in both cases the function also returns a usable object a tar header or zip reader in the case where the caller wants to handle archives with insecure filenames they may ignore the errinsecurepath error and perform whatever sanitization they find appropriate if the caller takes no action they get an error when processing an unsafe archive the advantage over automatically sanitizing filenames is that we don t silently change the semantics of archives a tar archive may legitimately contain absolute path names silently converting these to relative names seems more surprising than reporting an error in addition there isn t always an obvious sanitized name we probably want to reject the name on windows but what would we rewrite it into ,0 298167,22466745453.0,IssuesEvent,2022-06-22 02:57:18,golang/go,https://api.github.com/repos/golang/go,closed,cmd/trace: document event trace viewer [freeze exception],Documentation NeedsFix,"https://go-review.googlesource.com/c/go/+/412876 adds documentation to the main page of the cmd/trace event viewer. This issue is a request that it be granted a freeze exception, since it is essentially an addition of missing user documentation, and has no real impact on the program behavior. @prattmic @golang/release",1.0,"cmd/trace: document event trace viewer [freeze exception] - https://go-review.googlesource.com/c/go/+/412876 adds documentation to the main page of the cmd/trace event viewer. This issue is a request that it be granted a freeze exception, since it is essentially an addition of missing user documentation, and has no real impact on the program behavior. @prattmic @golang/release",1,cmd trace document event trace viewer adds documentation to the main page of the cmd trace event viewer this issue is a request that it be granted a freeze exception since it is essentially an addition of missing user documentation and has no real impact on the program behavior prattmic golang release,1 75528,20862163204.0,IssuesEvent,2022-03-22 00:37:26,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/releasebot: pushing issues and closing milestone didn't work for major release,Builders NeedsInvestigation,"There seems to be a problem in `pushIssues` for major releases. It's documented to move issues for major releases: ```Go // pushIssues moves open issues to the milestone of the next release of the same kind. // For major releases, it's the milestone of the next major release (e.g., 1.14 → 1.15). // For minor releases, it's the milestone of the next minor release (e.g., 1.14.1 → 1.14.2). // For other release types, it does nothing. func (w *Work) pushIssues() ``` Yet it didn't move issues for the Go 1.17 release, issue #47719. The milestone wasn't closed either, despite the log message: ``` 2021/08/16 17:01:07 closing milestone go1.17 ``` ~~From a quick look, a hypothesis is that gopherbot may have incorrectly thought milestone was ""go1.17"" (lower-case 'g'), but it's actually ""Go1.17"", and maybe GitHub is case sensitive (or has become).~~ Edit: This hypothesis wasn't right. CC @golang/release, @mknyszek.",1.0,"x/build/cmd/releasebot: pushing issues and closing milestone didn't work for major release - There seems to be a problem in `pushIssues` for major releases. It's documented to move issues for major releases: ```Go // pushIssues moves open issues to the milestone of the next release of the same kind. // For major releases, it's the milestone of the next major release (e.g., 1.14 → 1.15). // For minor releases, it's the milestone of the next minor release (e.g., 1.14.1 → 1.14.2). // For other release types, it does nothing. func (w *Work) pushIssues() ``` Yet it didn't move issues for the Go 1.17 release, issue #47719. The milestone wasn't closed either, despite the log message: ``` 2021/08/16 17:01:07 closing milestone go1.17 ``` ~~From a quick look, a hypothesis is that gopherbot may have incorrectly thought milestone was ""go1.17"" (lower-case 'g'), but it's actually ""Go1.17"", and maybe GitHub is case sensitive (or has become).~~ Edit: This hypothesis wasn't right. CC @golang/release, @mknyszek.",0,x build cmd releasebot pushing issues and closing milestone didn t work for major release there seems to be a problem in pushissues for major releases it s documented to move issues for major releases go pushissues moves open issues to the milestone of the next release of the same kind for major releases it s the milestone of the next major release e g → for minor releases it s the milestone of the next minor release e g → for other release types it does nothing func w work pushissues yet it didn t move issues for the go release issue the milestone wasn t closed either despite the log message closing milestone from a quick look a hypothesis is that gopherbot may have incorrectly thought milestone was lower case g but it s actually and maybe github is case sensitive or has become edit this hypothesis wasn t right cc golang release mknyszek ,0 41540,10732185266.0,IssuesEvent,2019-10-28 21:14:59,golang/go,https://api.github.com/repos/golang/go,closed,x/build: windows-amd64-longtest failing on x/mobile,Builders NeedsInvestigation OS-Windows mobile,"https://build.golang.org/log/2c7d5ffd37cce526cbf896b708d104b98a7f21f9 shows the `windows-amd64-longtest` running (and failing on) the `x/mobile` repo. Should this builder be running x/moble at all? CC @bradfitz @dmitshur @toothrot ",1.0,"x/build: windows-amd64-longtest failing on x/mobile - https://build.golang.org/log/2c7d5ffd37cce526cbf896b708d104b98a7f21f9 shows the `windows-amd64-longtest` running (and failing on) the `x/mobile` repo. Should this builder be running x/moble at all? CC @bradfitz @dmitshur @toothrot ",0,x build windows longtest failing on x mobile shows the windows longtest running and failing on the x mobile repo should this builder be running x moble at all cc bradfitz dmitshur toothrot ,0 192131,15339717270.0,IssuesEvent,2021-02-27 03:14:01,golang/go,https://api.github.com/repos/golang/go,closed,doc: Go 1.16 Release Notes has a broken golang.org link,Documentation,"In https://golang.org/doc/go1.16 where it says > `ReadDir` => `os.ReadDir` (note: returns a slice of `os.DirEntry` rather than a slice of `fs.FileInfo`) the hyperlink on `fs.FileInfo` goes to https://golang.org/pkg/fs/#FileInfo rather than to https://golang.org/pkg/io/fs/#FileInfo (the `io/` is missing).",1.0,"doc: Go 1.16 Release Notes has a broken golang.org link - In https://golang.org/doc/go1.16 where it says > `ReadDir` => `os.ReadDir` (note: returns a slice of `os.DirEntry` rather than a slice of `fs.FileInfo`) the hyperlink on `fs.FileInfo` goes to https://golang.org/pkg/fs/#FileInfo rather than to https://golang.org/pkg/io/fs/#FileInfo (the `io/` is missing).",1,doc go release notes has a broken golang org link in where it says readdir os readdir note returns a slice of os direntry rather than a slice of fs fileinfo the hyperlink on fs fileinfo goes to rather than to the io is missing ,1 92323,26655851440.0,IssuesEvent,2023-01-25 16:48:06,golang/go,https://api.github.com/repos/golang/go,opened,x/build: add NetBSD 10_BETA builders,OS-NetBSD Builders new-builder,"Context: NetBSD 10 is currently in beta state. There are no official releases yet, though there are daily builds from the branch. https://go.dev/cl/463123 is the first change that has a different code path on NetBSD 10 than on earlier versions. Perhaps we should have some NetBSD 10 builders, at the very least for amd64. Creating the image would be a simple change on top of the existing `x/build/env/netbsd_amd64` etc. Maybe we could have a parameter in there that specifies whether to build a -9 or -10 image. /cc @bcmills @cagedmantis @golang/netbsd ",2.0,"x/build: add NetBSD 10_BETA builders - Context: NetBSD 10 is currently in beta state. There are no official releases yet, though there are daily builds from the branch. https://go.dev/cl/463123 is the first change that has a different code path on NetBSD 10 than on earlier versions. Perhaps we should have some NetBSD 10 builders, at the very least for amd64. Creating the image would be a simple change on top of the existing `x/build/env/netbsd_amd64` etc. Maybe we could have a parameter in there that specifies whether to build a -9 or -10 image. /cc @bcmills @cagedmantis @golang/netbsd ",0,x build add netbsd beta builders context netbsd is currently in beta state there are no official releases yet though there are daily builds from the branch is the first change that has a different code path on netbsd than on earlier versions perhaps we should have some netbsd builders at the very least for creating the image would be a simple change on top of the existing x build env netbsd etc maybe we could have a parameter in there that specifies whether to build a or image cc bcmills cagedmantis golang netbsd ,0 54514,30222390380.0,IssuesEvent,2023-07-05 20:33:21,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/ssh: MAC orders,Performance NeedsFix,"This [commit](https://github.com/golang/crypto/commit/16222386f4de802a3c27c1714b0bcc28c0fd5397) added support for `hmac-sha2-512-etm@openssh.com` which is a good addition. But the mac order is relevant, now `hmac-sha2-512-etm@openssh.com` is the preferred MAC. Since sha256 is more optimized than sha512 in Go and is secure enough, I think we should prefer sha256 based MAC algorithms.",True,"x/crypto/ssh: MAC orders - This [commit](https://github.com/golang/crypto/commit/16222386f4de802a3c27c1714b0bcc28c0fd5397) added support for `hmac-sha2-512-etm@openssh.com` which is a good addition. But the mac order is relevant, now `hmac-sha2-512-etm@openssh.com` is the preferred MAC. Since sha256 is more optimized than sha512 in Go and is secure enough, I think we should prefer sha256 based MAC algorithms.",0,x crypto ssh mac orders this added support for hmac etm openssh com which is a good addition but the mac order is relevant now hmac etm openssh com is the preferred mac since is more optimized than in go and is secure enough i think we should prefer based mac algorithms ,0 54166,13261022551.0,IssuesEvent,2020-08-20 19:13:28,golang/go,https://api.github.com/repos/golang/go,closed,x/build: add openbsd/arm builder,Builders FeatureRequest new-builder,"@4a6f656c used to maintain one but it doesn't seem to be running anymore. Cloud arm32 is hard to find, so this might end up being a Raspberry Pi on my desk.",2.0,"x/build: add openbsd/arm builder - @4a6f656c used to maintain one but it doesn't seem to be running anymore. Cloud arm32 is hard to find, so this might end up being a Raspberry Pi on my desk.",0,x build add openbsd arm builder used to maintain one but it doesn t seem to be running anymore cloud is hard to find so this might end up being a raspberry pi on my desk ,0 165206,13994423052.0,IssuesEvent,2020-10-28 00:38:47,golang/go,https://api.github.com/repos/golang/go,opened,testing: document -test.benchmem and ReportAllocs output format,Documentation NeedsFix help wanted,"Filing this bug on behalf of someone who prefers not to do it directly: The `⁠(*testing.B).ReportAllocs` function's documentation says that its output is the same as setting -test.benchmem. However, there is as far as I can tell no explanation anywhere of what, exactly, -test.benchmem is or what it does. There is also no explanation as to what the output format is. For instance, in an output line like BenchmarkF-34 9718 672043 ns/op 34474 B/op 508 allocs/op I can see the lines with four numbers, but one of them is completely dimensionless and the others aren't entirely clear.",1.0,"testing: document -test.benchmem and ReportAllocs output format - Filing this bug on behalf of someone who prefers not to do it directly: The `⁠(*testing.B).ReportAllocs` function's documentation says that its output is the same as setting -test.benchmem. However, there is as far as I can tell no explanation anywhere of what, exactly, -test.benchmem is or what it does. There is also no explanation as to what the output format is. For instance, in an output line like BenchmarkF-34 9718 672043 ns/op 34474 B/op 508 allocs/op I can see the lines with four numbers, but one of them is completely dimensionless and the others aren't entirely clear.",1,testing document test benchmem and reportallocs output format filing this bug on behalf of someone who prefers not to do it directly the ⁠ testing b reportallocs function s documentation says that its output is the same as setting test benchmem however there is as far as i can tell no explanation anywhere of what exactly test benchmem is or what it does there is also no explanation as to what the output format is for instance in an output line like benchmarkf ns op b op allocs op i can see the lines with four numbers but one of them is completely dimensionless and the others aren t entirely clear ,1 36444,6534882099.0,IssuesEvent,2017-08-31 12:43:09,golang/go,https://api.github.com/repos/golang/go,opened,strconv: incorrect rounding to nearest even,Documentation NeedsDecision,"The following statements ``` fmt.Printf(""x = %.1f\n"", 0.35) fmt.Printf(""x = %.1f\n"", 0.45) fmt.Printf(""x = %.1f\n"", 0.55) fmt.Printf(""x = %.1f\n"", 0.65) ``` produce ``` x = 0.3 x = 0.5 x = 0.6 x = 0.7 ``` (https://play.golang.org/p/kLC7Ap0cpP). However, assuming rounding to nearest even, one would expect the result to be ``` x = 0.4 x = 0.4 x = 0.6 x = 0.6 ``` (The examples use fmt.Printf but the culprit is in the underlying strconv code. The documentation doesn't explicitly state that it rounds to nearest even, but that is definitively the intent of the implementation which contains code and comments to that effect.). The problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision, what should be `.5` is sometimes below or above that value. That said, the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number, that is if rounding where done on the output of using the ""%g"" format (or `strconv.FormatFloat` with precision -1). Unfortunately, computing that representation is much more expensive that what happens now. We can probably not fix this. For one, it's been like this forever. Also, a corresponding C program ``` #include int main() { printf(""x = %.1f\n"", 0.35); printf(""x = %.1f\n"", 0.45); printf(""x = %.1f\n"", 0.55); printf(""x = %.1f\n"", 0.65); return 0; } ``` produces the same (incorrect) result. And so does `math/big.Float` formatting with the same arguments (since the code mirrors the strconv code). But we should probably document it and perhaps even provide a ""correct"" routine for cases where this truly matters. ",1.0,"strconv: incorrect rounding to nearest even - The following statements ``` fmt.Printf(""x = %.1f\n"", 0.35) fmt.Printf(""x = %.1f\n"", 0.45) fmt.Printf(""x = %.1f\n"", 0.55) fmt.Printf(""x = %.1f\n"", 0.65) ``` produce ``` x = 0.3 x = 0.5 x = 0.6 x = 0.7 ``` (https://play.golang.org/p/kLC7Ap0cpP). However, assuming rounding to nearest even, one would expect the result to be ``` x = 0.4 x = 0.4 x = 0.6 x = 0.6 ``` (The examples use fmt.Printf but the culprit is in the underlying strconv code. The documentation doesn't explicitly state that it rounds to nearest even, but that is definitively the intent of the implementation which contains code and comments to that effect.). The problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision, what should be `.5` is sometimes below or above that value. That said, the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number, that is if rounding where done on the output of using the ""%g"" format (or `strconv.FormatFloat` with precision -1). Unfortunately, computing that representation is much more expensive that what happens now. We can probably not fix this. For one, it's been like this forever. Also, a corresponding C program ``` #include int main() { printf(""x = %.1f\n"", 0.35); printf(""x = %.1f\n"", 0.45); printf(""x = %.1f\n"", 0.55); printf(""x = %.1f\n"", 0.65); return 0; } ``` produces the same (incorrect) result. And so does `math/big.Float` formatting with the same arguments (since the code mirrors the strconv code). But we should probably document it and perhaps even provide a ""correct"" routine for cases where this truly matters. ",1,strconv incorrect rounding to nearest even the following statements fmt printf x n fmt printf x n fmt printf x n fmt printf x n produce x x x x however assuming rounding to nearest even one would expect the result to be x x x x the examples use fmt printf but the culprit is in the underlying strconv code the documentation doesn t explicitly state that it rounds to nearest even but that is definitively the intent of the implementation which contains code and comments to that effect the problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision what should be is sometimes below or above that value that said the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number that is if rounding where done on the output of using the g format or strconv formatfloat with precision unfortunately computing that representation is much more expensive that what happens now we can probably not fix this for one it s been like this forever also a corresponding c program include int main printf x n printf x n printf x n printf x n return produces the same incorrect result and so does math big float formatting with the same arguments since the code mirrors the strconv code but we should probably document it and perhaps even provide a correct routine for cases where this truly matters ,1 7510,3992738016.0,IssuesEvent,2016-05-10 03:56:21,golang/go,https://api.github.com/repos/golang/go,closed,io: add test to verify that ReadAt doesn't affect seek offset (for Plan 9 kernel bug),Builders OS-Plan9,"Running `go tool nm` on object files doesn't work anymore on Plan 9: ``` % go tool nm file.o open file.o: unrecognized object file ``` This error is returned by [rd.parseObject](https://github.com/golang/go/blob/c2d3e1123c/src/cmd/internal/goobj/read.go#L475) in goobj.Parse. It reads the ""386 deve"" string which doesn't match the expected ""go objec"" string. It happens because [objfile.Open](https://github.com/golang/go/blob/c2d3e1123c/src/cmd/internal/objfile/objfile.go#L53) calls [debug/elf.NewFile](https://github.com/golang/go/blob/c2d3e1123c/src/debug/elf/file.go#L228) before, which does a ReadAt of 16 bytes. However, the implementation of [pread](https://9p.io/magic/man2html/2/read) in the Plan 9 kernel contains a bug where it updates the channel offset while it shouldn't. Hence, the first 16 bytes of the files are already read before calling goobj.Parse. This is related to #11265 This can be fixed by [fixing the pread system call](http://9legacy.org/9legacy/patch/9-pread-offset.diff) in the Plan 9 kernel. A workaround is to add `Seek(0, 0)` after calling ReadAt: ``` --- a/src/cmd/internal/objfile/objfile.go +++ b/src/cmd/internal/objfile/objfile.go @@ -50,6 +50,10 @@ func Open(name string) (*File, error) { return nil, err } for _, try := range openers { + _, err = r.Seek(0, 0) + if err != nil { + return nil, err + } if raw, err := try(r); err == nil { return &File{r, raw}, nil } ```",1.0,"io: add test to verify that ReadAt doesn't affect seek offset (for Plan 9 kernel bug) - Running `go tool nm` on object files doesn't work anymore on Plan 9: ``` % go tool nm file.o open file.o: unrecognized object file ``` This error is returned by [rd.parseObject](https://github.com/golang/go/blob/c2d3e1123c/src/cmd/internal/goobj/read.go#L475) in goobj.Parse. It reads the ""386 deve"" string which doesn't match the expected ""go objec"" string. It happens because [objfile.Open](https://github.com/golang/go/blob/c2d3e1123c/src/cmd/internal/objfile/objfile.go#L53) calls [debug/elf.NewFile](https://github.com/golang/go/blob/c2d3e1123c/src/debug/elf/file.go#L228) before, which does a ReadAt of 16 bytes. However, the implementation of [pread](https://9p.io/magic/man2html/2/read) in the Plan 9 kernel contains a bug where it updates the channel offset while it shouldn't. Hence, the first 16 bytes of the files are already read before calling goobj.Parse. This is related to #11265 This can be fixed by [fixing the pread system call](http://9legacy.org/9legacy/patch/9-pread-offset.diff) in the Plan 9 kernel. A workaround is to add `Seek(0, 0)` after calling ReadAt: ``` --- a/src/cmd/internal/objfile/objfile.go +++ b/src/cmd/internal/objfile/objfile.go @@ -50,6 +50,10 @@ func Open(name string) (*File, error) { return nil, err } for _, try := range openers { + _, err = r.Seek(0, 0) + if err != nil { + return nil, err + } if raw, err := try(r); err == nil { return &File{r, raw}, nil } ```",0,io add test to verify that readat doesn t affect seek offset for plan kernel bug running go tool nm on object files doesn t work anymore on plan go tool nm file o open file o unrecognized object file this error is returned by in goobj parse it reads the deve string which doesn t match the expected go objec string it happens because calls before which does a readat of bytes however the implementation of in the plan kernel contains a bug where it updates the channel offset while it shouldn t hence the first bytes of the files are already read before calling goobj parse this is related to this can be fixed by in the plan kernel a workaround is to add seek after calling readat a src cmd internal objfile objfile go b src cmd internal objfile objfile go func open name string file error return nil err for try range openers err r seek if err nil return nil err if raw err try r err nil return file r raw nil ,0 47619,7334300307.0,IssuesEvent,2018-03-05 22:17:16,golang/go,https://api.github.com/repos/golang/go,closed,x/playground: link to the playground source code in the help page,Documentation NeedsFix,"I can never remember where it is. It's pretty standard nowadays to link back to the implementation of any open source website. IIRC, there are actually multiple playground moving parts. It'd be nice to link to all of them. I'd send a CL, but, um, I can't remember where the code is. cc @andybons ",1.0,"x/playground: link to the playground source code in the help page - I can never remember where it is. It's pretty standard nowadays to link back to the implementation of any open source website. IIRC, there are actually multiple playground moving parts. It'd be nice to link to all of them. I'd send a CL, but, um, I can't remember where the code is. cc @andybons ",1,x playground link to the playground source code in the help page i can never remember where it is it s pretty standard nowadays to link back to the implementation of any open source website iirc there are actually multiple playground moving parts it d be nice to link to all of them i d send a cl but um i can t remember where the code is cc andybons ,1 33468,6206523444.0,IssuesEvent,2017-07-06 18:37:28,golang/go,https://api.github.com/repos/golang/go,opened,doc: document that FreeBSD 9 support will be removed in Go 1.10,Documentation,"Maybe I missed a decision, but I thought we needed to document in Go 1.9 release notes that Go 1.10 will remove support for FreeBSD 9. I don't see that there.",1.0,"doc: document that FreeBSD 9 support will be removed in Go 1.10 - Maybe I missed a decision, but I thought we needed to document in Go 1.9 release notes that Go 1.10 will remove support for FreeBSD 9. I don't see that there.",1,doc document that freebsd support will be removed in go maybe i missed a decision but i thought we needed to document in go release notes that go will remove support for freebsd i don t see that there ,1 63922,6888135602.0,IssuesEvent,2017-11-22 03:44:43,golang/go,https://api.github.com/repos/golang/go,closed,log/syslog: TestWithSimulated flake on openbsd,HelpWanted OS-OpenBSD Testing,"Seen on trybot run for CL 40857: https://storage.googleapis.com/go-build-log/257f2b63/openbsd-amd64-60_5e3c8050.log ``` --- FAIL: TestWithSimulated (4.13s) syslog_test.go:260: Got """", does not match template ""<14>%s %s syslog_test[%d]: Test 123\n"" (0 unexpected EOF) FAIL FAIL log/syslog 4.750s ``` ",1.0,"log/syslog: TestWithSimulated flake on openbsd - Seen on trybot run for CL 40857: https://storage.googleapis.com/go-build-log/257f2b63/openbsd-amd64-60_5e3c8050.log ``` --- FAIL: TestWithSimulated (4.13s) syslog_test.go:260: Got """", does not match template ""<14>%s %s syslog_test[%d]: Test 123\n"" (0 unexpected EOF) FAIL FAIL log/syslog 4.750s ``` ",0,log syslog testwithsimulated flake on openbsd seen on trybot run for cl fail testwithsimulated syslog test go got does not match template s s syslog test test n unexpected eof fail fail log syslog ,0 8345,6521280429.0,IssuesEvent,2017-08-28 19:56:24,golang/go,https://api.github.com/repos/golang/go,closed,"runtime: specialize memhash32, memhash64",Performance Suggested,"memhash32 and memhash64 are defined as: ```go func memhash32(p unsafe.Pointer, h uintptr) uintptr { return memhash(p, h, 4) } func memhash64(p unsafe.Pointer, h uintptr) uintptr { return memhash(p, h, 8) } ``` The generic memhash implementation contains a lot of mechanism that can be skipped when the size is known. A quick hack up of a specialized memhash64 on amd64, with aeshash manually disabled, shows nice gains: ``` name old time/op new time/op delta MapPopulate/1-8 76.7ns ± 4% 75.1ns ± 4% ~ (p=0.055 n=10+10) MapPopulate/10-8 613ns ± 3% 570ns ± 3% -6.94% (p=0.000 n=10+9) MapPopulate/100-8 7.93µs ± 2% 7.31µs ± 3% -7.85% (p=0.000 n=9+10) MapPopulate/1000-8 97.0µs ± 3% 89.1µs ± 2% -8.20% (p=0.000 n=10+9) MapPopulate/10000-8 843µs ± 3% 759µs ± 2% -10.02% (p=0.000 n=10+9) MapPopulate/100000-8 9.19ms ± 4% 8.69ms ± 2% -5.38% (p=0.000 n=10+9) ``` The specialized code is small, both in terms of lines of code and machine code. For non-aeshash architectures, this seems like an easy, significant win. Leaving for someone else to implement all the way through and benchmark on a non-aeshash architecture, due to my limited cycles. cc @martisch @philhofer @randall77 ",True,"runtime: specialize memhash32, memhash64 - memhash32 and memhash64 are defined as: ```go func memhash32(p unsafe.Pointer, h uintptr) uintptr { return memhash(p, h, 4) } func memhash64(p unsafe.Pointer, h uintptr) uintptr { return memhash(p, h, 8) } ``` The generic memhash implementation contains a lot of mechanism that can be skipped when the size is known. A quick hack up of a specialized memhash64 on amd64, with aeshash manually disabled, shows nice gains: ``` name old time/op new time/op delta MapPopulate/1-8 76.7ns ± 4% 75.1ns ± 4% ~ (p=0.055 n=10+10) MapPopulate/10-8 613ns ± 3% 570ns ± 3% -6.94% (p=0.000 n=10+9) MapPopulate/100-8 7.93µs ± 2% 7.31µs ± 3% -7.85% (p=0.000 n=9+10) MapPopulate/1000-8 97.0µs ± 3% 89.1µs ± 2% -8.20% (p=0.000 n=10+9) MapPopulate/10000-8 843µs ± 3% 759µs ± 2% -10.02% (p=0.000 n=10+9) MapPopulate/100000-8 9.19ms ± 4% 8.69ms ± 2% -5.38% (p=0.000 n=10+9) ``` The specialized code is small, both in terms of lines of code and machine code. For non-aeshash architectures, this seems like an easy, significant win. Leaving for someone else to implement all the way through and benchmark on a non-aeshash architecture, due to my limited cycles. cc @martisch @philhofer @randall77 ",0,runtime specialize and are defined as go func p unsafe pointer h uintptr uintptr return memhash p h func p unsafe pointer h uintptr uintptr return memhash p h the generic memhash implementation contains a lot of mechanism that can be skipped when the size is known a quick hack up of a specialized on with aeshash manually disabled shows nice gains name old time op new time op delta mappopulate ± ± p n mappopulate ± ± p n mappopulate ± ± p n mappopulate ± ± p n mappopulate ± ± p n mappopulate ± ± p n the specialized code is small both in terms of lines of code and machine code for non aeshash architectures this seems like an easy significant win leaving for someone else to implement all the way through and benchmark on a non aeshash architecture due to my limited cycles cc martisch philhofer ,0 32753,8948305296.0,IssuesEvent,2019-01-25 01:45:27,golang/go,https://api.github.com/repos/golang/go,closed,x/build: disable openbsd-amd64-64 and freebsd-amd64-12_0 on release-branch.go1.10,Builders NeedsFix,"Those builders are too new for Go 1.10, and they always fail the TryBots. > Failed on openbsd-amd64-64: https://storage.googleapis.com/go-build-log/74878a24/openbsd-amd64-64_3fe0d458.log > Failed on freebsd-amd64-12_0: https://storage.googleapis.com/go-build-log/74878a24/freebsd-amd64-12_0_5ecb9125.log Source: https://go-review.googlesource.com/c/go/+/151343. /cc @bradfitz @dmitshur ",1.0,"x/build: disable openbsd-amd64-64 and freebsd-amd64-12_0 on release-branch.go1.10 - Those builders are too new for Go 1.10, and they always fail the TryBots. > Failed on openbsd-amd64-64: https://storage.googleapis.com/go-build-log/74878a24/openbsd-amd64-64_3fe0d458.log > Failed on freebsd-amd64-12_0: https://storage.googleapis.com/go-build-log/74878a24/freebsd-amd64-12_0_5ecb9125.log Source: https://go-review.googlesource.com/c/go/+/151343. /cc @bradfitz @dmitshur ",0,x build disable openbsd and freebsd on release branch those builders are too new for go and they always fail the trybots failed on openbsd failed on freebsd source cc bradfitz dmitshur ,0 19027,10293603825.0,IssuesEvent,2019-08-27 16:46:56,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: prove pass disabled on int32/int64,NeedsInvestigation Performance,"Consider this program: ``` package p func f(x []int, j int) int { if x[j] != 0 { return 1 } if j > 0 && x[j-1] != 0 { return 1 } return 0 } ``` The bounds check for x[j-1] can be eliminated: at that point, x[j] did not panic, so j \< len(x), and the if statement has also tested j > 0, so 0 \<= j-1 \< len(x). The compiler _does_ eliminate this check: ``` $ go tool compile -S x.go |grep panicindex 0x006e 00110 (x.go:4) CALL runtime.panicindex(SB) rel 111+4 t=8 runtime.panicindex+0 $ ``` But if I change j to be int32 then the check is not eliminated: ``` package p func f(x []int, j int32) int { if x[j] != 0 { return 1 } if j > 0 && x[j-1] != 0 { return 1 } return 0 } ``` ``` $ go tool compile -S x.go |grep panicindex 0x0078 00120 (x.go:7) CALL runtime.panicindex(SB) 0x007f 00127 (x.go:4) CALL runtime.panicindex(SB) rel 121+4 t=8 runtime.panicindex+0 rel 128+4 t=8 runtime.panicindex+0 $ ``` Is this necessary? /cc @aclements ",True,"cmd/compile: prove pass disabled on int32/int64 - Consider this program: ``` package p func f(x []int, j int) int { if x[j] != 0 { return 1 } if j > 0 && x[j-1] != 0 { return 1 } return 0 } ``` The bounds check for x[j-1] can be eliminated: at that point, x[j] did not panic, so j \< len(x), and the if statement has also tested j > 0, so 0 \<= j-1 \< len(x). The compiler _does_ eliminate this check: ``` $ go tool compile -S x.go |grep panicindex 0x006e 00110 (x.go:4) CALL runtime.panicindex(SB) rel 111+4 t=8 runtime.panicindex+0 $ ``` But if I change j to be int32 then the check is not eliminated: ``` package p func f(x []int, j int32) int { if x[j] != 0 { return 1 } if j > 0 && x[j-1] != 0 { return 1 } return 0 } ``` ``` $ go tool compile -S x.go |grep panicindex 0x0078 00120 (x.go:7) CALL runtime.panicindex(SB) 0x007f 00127 (x.go:4) CALL runtime.panicindex(SB) rel 121+4 t=8 runtime.panicindex+0 rel 128+4 t=8 runtime.panicindex+0 $ ``` Is this necessary? /cc @aclements ",0,cmd compile prove pass disabled on consider this program package p func f x int j int int if x return if j x return return the bounds check for x can be eliminated at that point x did not panic so j so j len x the compiler does eliminate this check go tool compile s x go grep panicindex x go call runtime panicindex sb rel t runtime panicindex but if i change j to be then the check is not eliminated package p func f x int j int if x return if j x return return go tool compile s x go grep panicindex x go call runtime panicindex sb x go call runtime panicindex sb rel t runtime panicindex rel t runtime panicindex is this necessary cc aclements ,0 52720,7781498348.0,IssuesEvent,2018-06-06 00:38:02,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/acme/autocert: Document key generation with a non-nil acme.Client,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ### What did you do? Read documentation at https://godoc.org/golang.org/x/crypto/acme/autocert#Manager. ### What did you expect to see? Regarding the Client field, I expected the behaviour [here](https://github.com/golang/crypto/blob/847319b7fc94cab682988f93da778204da164588/acme/autocert/autocert.go#L635): ``` client := m.Client if client == nil { client = &acme.Client{DirectoryURL: acme.LetsEncryptURL} } if client.Key == nil { var err error client.Key, err = m.accountKey(ctx) if err != nil { return nil, err } } ``` To be documented, with something along the lines of: ``` // If Client is nil, a zero-value acme.Client is used with acme.LetsEncryptURL // directory endpoint. // Then, if Client.Key is nil, a newly-generated ECDSA P-256 key is used. ``` ### What did you see instead? ``` // If Client is nil, a zero-value acme.Client is used with acme.LetsEncryptURL // directory endpoint and a newly-generated ECDSA P-256 key. ``` Note that the current documentation implies that: ``` m := autocert.Manager{ Client: &acme.Client{DirectoryURL: ""http://example.com""}, } ``` Is incorrect as the documentation for acme.Client states: > Client is an ACME client. The only required field is Key. The autocert package helpfully generates a key for you and fills in the Key field, allowing you to specify an alternative DirectoryURL without having to generate a key yourself.",1.0,"x/crypto/acme/autocert: Document key generation with a non-nil acme.Client - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ### What did you do? Read documentation at https://godoc.org/golang.org/x/crypto/acme/autocert#Manager. ### What did you expect to see? Regarding the Client field, I expected the behaviour [here](https://github.com/golang/crypto/blob/847319b7fc94cab682988f93da778204da164588/acme/autocert/autocert.go#L635): ``` client := m.Client if client == nil { client = &acme.Client{DirectoryURL: acme.LetsEncryptURL} } if client.Key == nil { var err error client.Key, err = m.accountKey(ctx) if err != nil { return nil, err } } ``` To be documented, with something along the lines of: ``` // If Client is nil, a zero-value acme.Client is used with acme.LetsEncryptURL // directory endpoint. // Then, if Client.Key is nil, a newly-generated ECDSA P-256 key is used. ``` ### What did you see instead? ``` // If Client is nil, a zero-value acme.Client is used with acme.LetsEncryptURL // directory endpoint and a newly-generated ECDSA P-256 key. ``` Note that the current documentation implies that: ``` m := autocert.Manager{ Client: &acme.Client{DirectoryURL: ""http://example.com""}, } ``` Is incorrect as the documentation for acme.Client states: > Client is an ACME client. The only required field is Key. The autocert package helpfully generates a key for you and fills in the Key field, allowing you to specify an alternative DirectoryURL without having to generate a key yourself.",1,x crypto acme autocert document key generation with a non nil acme client please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env what did you do read documentation at what did you expect to see regarding the client field i expected the behaviour client m client if client nil client acme client directoryurl acme letsencrypturl if client key nil var err error client key err m accountkey ctx if err nil return nil err to be documented with something along the lines of if client is nil a zero value acme client is used with acme letsencrypturl directory endpoint then if client key is nil a newly generated ecdsa p key is used what did you see instead if client is nil a zero value acme client is used with acme letsencrypturl directory endpoint and a newly generated ecdsa p key note that the current documentation implies that m autocert manager client acme client directoryurl is incorrect as the documentation for acme client states client is an acme client the only required field is key the autocert package helpfully generates a key for you and fills in the key field allowing you to specify an alternative directoryurl without having to generate a key yourself ,1 72911,9631932239.0,IssuesEvent,2019-05-15 15:09:43,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: GONOPROXY is undocumented,Documentation NeedsFix modules release-blocker,"`GOSUMDB`, `GONOSUMDB`, and `GONOPROXY` variables were added in [CL 173951](https://golang.org/cl/173951). Documentation for `GOSUMDB` and `GONOSUMDB` was added to https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures, but I don't see any mention of `GONOPROXY` in the `cmd/go` docs at all. CC @jayconrod @rsc ",1.0,"cmd/go: GONOPROXY is undocumented - `GOSUMDB`, `GONOSUMDB`, and `GONOPROXY` variables were added in [CL 173951](https://golang.org/cl/173951). Documentation for `GOSUMDB` and `GONOSUMDB` was added to https://tip.golang.org/cmd/go/#hdr-Module_authentication_failures, but I don't see any mention of `GONOPROXY` in the `cmd/go` docs at all. CC @jayconrod @rsc ",1,cmd go gonoproxy is undocumented gosumdb gonosumdb and gonoproxy variables were added in documentation for gosumdb and gonosumdb was added to but i don t see any mention of gonoproxy in the cmd go docs at all cc jayconrod rsc ,1 152570,13461104866.0,IssuesEvent,2020-09-09 14:25:20,golang/go,https://api.github.com/repos/golang/go,closed,x/website: ref/mod go.mod section has broken ids,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? current website ### Does this issue reproduce with the latest release? repros with https://tip.golang.org/ref/mod ### What operating system and processor architecture are you using (`go env`)? Google Chrome | 85.0.4183.83 ### What did you do? visit https://golang.org/ref/mod and click on the `require directive` link in table of contents ### What did you expect to see? link/jump to ""require directive"" section `

require directive

` ### What did you see instead? link/jump to ""go.mod files"" section `

require directive

` ### additional info it appears that the entire ""go.mod files"" section has their ids truncated to just `go`",1.0,"x/website: ref/mod go.mod section has broken ids - ### What version of Go are you using (`go version`)? current website ### Does this issue reproduce with the latest release? repros with https://tip.golang.org/ref/mod ### What operating system and processor architecture are you using (`go env`)? Google Chrome | 85.0.4183.83 ### What did you do? visit https://golang.org/ref/mod and click on the `require directive` link in table of contents ### What did you expect to see? link/jump to ""require directive"" section `

require directive

` ### What did you see instead? link/jump to ""go.mod files"" section `

require directive

` ### additional info it appears that the entire ""go.mod files"" section has their ids truncated to just `go`",1,x website ref mod go mod section has broken ids what version of go are you using go version current website does this issue reproduce with the latest release repros with what operating system and processor architecture are you using go env google chrome what did you do visit and click on the require directive link in table of contents what did you expect to see link jump to require directive section require directive what did you see instead link jump to go mod files section require directive additional info it appears that the entire go mod files section has their ids truncated to just go ,1 45892,24259991736.0,IssuesEvent,2022-09-27 21:31:08,golang/go,https://api.github.com/repos/golang/go,closed,x/net/http2: handle servers that delay sending END_STREAM in HEAD responses,Performance NeedsInvestigation,"### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.19-47f806ce81 Sat Jun 4 21:18:25 2022 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/ncw/.cache/go-build""
GOENV=""/home/ncw/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/ncw/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/ncw/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/go-tip""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/go-tip/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.19-47f806ce81 Sat Jun 4 21:18:25 2022 +0000""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/ncw/go/src/github.com/rclone/rclone/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2093186880=/tmp/go-build -gno-record-gcc-switches""
### What did you do? A user reported [a performance regression between rclone v1.57 and v1.58](https://forum.rclone.org/t/scaleway-s3-speed-reduce-between-1-57-and-1-58-1/31128/2) in the forum. I ascertained that this wasn't a regression in rclone, but turned out to be a regression in the go standard library from `go1.17` to `go1.18`. I managed to bisect the problem to this commit: 7109323af5a8c7e076fa2af7185caa6185df97cd is the first bad commit from #48564 and #23559 ``` commit 7109323af5a8c7e076fa2af7185caa6185df97cd Author: Damien Neil Date: Mon Oct 4 10:50:02 2021 -0700 all: update golang.org/x/net to pull in CL 353390 Fixes #48564. Fixes #23559. Change-Id: I8e0b646c4791d3a6fb17df1af0a7175b68ce8983 Reviewed-on: https://go-review.googlesource.com/c/go/+/353870 Trust: Damien Neil Run-TryBot: Damien Neil TryBot-Result: Go Bot Reviewed-by: Brad Fitzpatrick src/go.mod | 2 +- src/go.sum | 6 + src/net/http/h2_bundle.go | 1397 ++++++++++++++++++++++++++------------------- src/vendor/modules.txt | 2 +- 4 files changed, 807 insertions(+), 600 deletions(-) ``` It turns out that this http2 upgrade tanked the performance of rclone with this HTTP2 server. I haven't measured exactly the performance but it seems at least 10 times slower per file uploaded by rclone. (**Edit** it seems to add 5 seconds of latency to each HTTP roundtrip - see later). I'm not really sure why though, and I need some help investigating further. I tried turning on `GODEBUG=http2debug=2` and I couldn't see anything obvious (no error messages). I can post these, but I need to sanitize tokens out of them first. I could bisect the `golang.org/x/net` bundle commit further, but I don't know how to glue `x/net` into the go source - a hint here would be appreciated too! ",True,"x/net/http2: handle servers that delay sending END_STREAM in HEAD responses - ### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.19-47f806ce81 Sat Jun 4 21:18:25 2022 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/ncw/.cache/go-build""
GOENV=""/home/ncw/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/ncw/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/ncw/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/go-tip""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/go-tip/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.19-47f806ce81 Sat Jun 4 21:18:25 2022 +0000""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/ncw/go/src/github.com/rclone/rclone/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2093186880=/tmp/go-build -gno-record-gcc-switches""
### What did you do? A user reported [a performance regression between rclone v1.57 and v1.58](https://forum.rclone.org/t/scaleway-s3-speed-reduce-between-1-57-and-1-58-1/31128/2) in the forum. I ascertained that this wasn't a regression in rclone, but turned out to be a regression in the go standard library from `go1.17` to `go1.18`. I managed to bisect the problem to this commit: 7109323af5a8c7e076fa2af7185caa6185df97cd is the first bad commit from #48564 and #23559 ``` commit 7109323af5a8c7e076fa2af7185caa6185df97cd Author: Damien Neil Date: Mon Oct 4 10:50:02 2021 -0700 all: update golang.org/x/net to pull in CL 353390 Fixes #48564. Fixes #23559. Change-Id: I8e0b646c4791d3a6fb17df1af0a7175b68ce8983 Reviewed-on: https://go-review.googlesource.com/c/go/+/353870 Trust: Damien Neil Run-TryBot: Damien Neil TryBot-Result: Go Bot Reviewed-by: Brad Fitzpatrick src/go.mod | 2 +- src/go.sum | 6 + src/net/http/h2_bundle.go | 1397 ++++++++++++++++++++++++++------------------- src/vendor/modules.txt | 2 +- 4 files changed, 807 insertions(+), 600 deletions(-) ``` It turns out that this http2 upgrade tanked the performance of rclone with this HTTP2 server. I haven't measured exactly the performance but it seems at least 10 times slower per file uploaded by rclone. (**Edit** it seems to add 5 seconds of latency to each HTTP roundtrip - see later). I'm not really sure why though, and I need some help investigating further. I tried turning on `GODEBUG=http2debug=2` and I couldn't see anything obvious (no error messages). I can post these, but I need to sanitize tokens out of them first. I could bisect the `golang.org/x/net` bundle commit further, but I don't know how to glue `x/net` into the go source - a hint here would be appreciated too! ",0,x net handle servers that delay sending end stream in head responses what version of go are you using go version go version go version devel sat jun linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home ncw cache go build goenv home ncw config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home ncw go pkg mod gonoproxy gonosumdb goos linux gopath home ncw go goprivate goproxy goroot opt go go tip gosumdb sum golang org gotmpdir gotooldir opt go go tip pkg tool linux govcs goversion devel sat jun gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home ncw go src github com rclone rclone go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread wl no gc sections fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do a user reported in the forum i ascertained that this wasn t a regression in rclone but turned out to be a regression in the go standard library from to i managed to bisect the problem to this commit is the first bad commit from and commit author damien neil date mon oct all update golang org x net to pull in cl fixes fixes change id reviewed on trust damien neil run trybot damien neil trybot result go bot reviewed by brad fitzpatrick src go mod src go sum src net http bundle go src vendor modules txt files changed insertions deletions it turns out that this upgrade tanked the performance of rclone with this server i haven t measured exactly the performance but it seems at least times slower per file uploaded by rclone edit it seems to add seconds of latency to each http roundtrip see later i m not really sure why though and i need some help investigating further i tried turning on godebug and i couldn t see anything obvious no error messages i can post these but i need to sanitize tokens out of them first i could bisect the golang org x net bundle commit further but i don t know how to glue x net into the go source a hint here would be appreciated too ,0 6107,2583144221.0,IssuesEvent,2015-02-16 00:27:12,golang/go,https://api.github.com/repos/golang/go,closed,image/jpeg: support for CMYK images,accepted priority-later release-none repo-main,"by **samuel.stauffer**: 
To reproduce:

1. Decode CMYK jpeg (attached)

What is the expected output?

A successfully decoded image. Works in Preview.app and ImageMagick.

What do you see instead?

Error "unsupported JPEG feature: SOF has wrong length"

Which version are you using?  (run 'go version')

go version devel +a5efcd1675eb Thu Dec 06 09:47:12 2012 -0800

Please provide any additional information below.

I'm seeing this error for all CMYK jpegs I've tried.
Attachments: 1. err1.jpeg (902176 bytes)",1.0,"image/jpeg: support for CMYK images - by **samuel.stauffer**: 
To reproduce:

1. Decode CMYK jpeg (attached)

What is the expected output?

A successfully decoded image. Works in Preview.app and ImageMagick.

What do you see instead?

Error "unsupported JPEG feature: SOF has wrong length"

Which version are you using?  (run 'go version')

go version devel +a5efcd1675eb Thu Dec 06 09:47:12 2012 -0800

Please provide any additional information below.

I'm seeing this error for all CMYK jpegs I've tried.
Attachments: 1. err1.jpeg (902176 bytes)",0,image jpeg support for cmyk images by samuel stauffer to reproduce decode cmyk jpeg attached what is the expected output a successfully decoded image works in preview app and imagemagick what do you see instead error quot unsupported jpeg feature sof has wrong length quot which version are you using run go version go version devel thu dec please provide any additional information below i m seeing this error for all cmyk jpegs i ve tried attachments a href bytes ,0 317544,27244072978.0,IssuesEvent,2023-02-21 23:33:54,golang/go,https://api.github.com/repos/golang/go,closed,syscall: introduce IoctlPtr for exec_unix tests,Testing NeedsFix compiler/runtime,"This is a followup for https://github.com/golang/go/issues/44834. Similar issue [is](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L180) [present](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L217) [in](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L231) `exec_unix_test.go`, which calls [sysctl.Ioctl()](https://github.com/golang/go/blob/master/src/syscall/export_unix_test.go#L9) and passes Go pointers as uintptr, violating unsafe.Pointer safety rules. As sysctl.Ioctl() is exported solely for tests (and called only by exec_unix_test.go), replace it with sysctl.IoctlPtr() that accepts arg argument as unsafe.Pointer.",1.0,"syscall: introduce IoctlPtr for exec_unix tests - This is a followup for https://github.com/golang/go/issues/44834. Similar issue [is](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L180) [present](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L217) [in](https://github.com/golang/go/blob/master/src/syscall/exec_unix_test.go#L231) `exec_unix_test.go`, which calls [sysctl.Ioctl()](https://github.com/golang/go/blob/master/src/syscall/export_unix_test.go#L9) and passes Go pointers as uintptr, violating unsafe.Pointer safety rules. As sysctl.Ioctl() is exported solely for tests (and called only by exec_unix_test.go), replace it with sysctl.IoctlPtr() that accepts arg argument as unsafe.Pointer.",0,syscall introduce ioctlptr for exec unix tests this is a followup for similar issue exec unix test go which calls and passes go pointers as uintptr violating unsafe pointer safety rules as sysctl ioctl is exported solely for tests and called only by exec unix test go replace it with sysctl ioctlptr that accepts arg argument as unsafe pointer ,0 49873,7544489717.0,IssuesEvent,2018-04-17 18:35:51,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/acme/autocert: clarify usage of (*Manager).GetCertificate,Documentation,"Would be nice to have a example of `cert, err := m.GetCertificate(...)` so the certificates can be used in GRPC. I fail to come up with a solution. ```go m := &autocert.Manager{ Cache: autocert.DirCache(""tls""), Prompt: autocert.AcceptTOS, HostPolicy: autocert.HostWhitelist(""example.com""), } go http.ListenAndServe("":http"", m.HTTPHandler(nil)) cert, err := m.GetCertificate(...) if err != nil { t.Fatalf(""Failed to generate certificates %s"", err) } creds := credentials.NewServerTLSFromCert(cert) srv := grpc.NewServer(grpc.Creds(creds)) reflection.Register(srv) ``` https://godoc.org/golang.org/x/crypto/acme/autocert https://stackoverflow.com/questions/49874945/acme-certificate-for-grpc",1.0,"x/crypto/acme/autocert: clarify usage of (*Manager).GetCertificate - Would be nice to have a example of `cert, err := m.GetCertificate(...)` so the certificates can be used in GRPC. I fail to come up with a solution. ```go m := &autocert.Manager{ Cache: autocert.DirCache(""tls""), Prompt: autocert.AcceptTOS, HostPolicy: autocert.HostWhitelist(""example.com""), } go http.ListenAndServe("":http"", m.HTTPHandler(nil)) cert, err := m.GetCertificate(...) if err != nil { t.Fatalf(""Failed to generate certificates %s"", err) } creds := credentials.NewServerTLSFromCert(cert) srv := grpc.NewServer(grpc.Creds(creds)) reflection.Register(srv) ``` https://godoc.org/golang.org/x/crypto/acme/autocert https://stackoverflow.com/questions/49874945/acme-certificate-for-grpc",1,x crypto acme autocert clarify usage of manager getcertificate would be nice to have a example of cert err m getcertificate so the certificates can be used in grpc i fail to come up with a solution go m autocert manager cache autocert dircache tls prompt autocert accepttos hostpolicy autocert hostwhitelist example com go http listenandserve http m httphandler nil cert err m getcertificate if err nil t fatalf failed to generate certificates s err creds credentials newservertlsfromcert cert srv grpc newserver grpc creds creds reflection register srv ,1 56436,8072944437.0,IssuesEvent,2018-08-06 17:36:51,golang/go,https://api.github.com/repos/golang/go,closed,cmd/cgo: CoreFoundation go-keychain compile failure on tip,Documentation NeedsFix OS-Darwin release-blocker,"Please answer these questions before submitting your issue. Thanks! #### What did you do? Check out tip of github.com/keybase/go-keychain (commit https://github.com/keybase/go-keychain/commit/70b98e9c8d754db775c5bd3b2de3670cc76f1825) and run `go build github.com/keybase/go-keychain` #### What did you expect to see? I expected the program to compile. #### What did you see instead? ``` $ go build . # github.com/keybase/go-keychain ./corefoundation_1.10.go:55: cannot use nil as type _Ctype_CFAllocatorRef in argument to _Cfunc_CFDataCreate ./corefoundation_1.10.go:81: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal ./corefoundation_1.10.go:118: cannot use nil as type _Ctype_CFAllocatorRef in argument to _Cfunc_CFStringCreateWithBytes ./corefoundation_1.10.go:153: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal ``` #### Does this issue reproduce with the latest release (go1.10.3)? No. I can reproduce it using tip though, which suggests that this code will break in the upcoming Go 1.11 release. A git bisect revealed that commit 94076feef53c41c0c558a8686d6f2650b1614414 is the first commit to break; versions of Go compiled with commits earlier than this commit successfully compile the go-keychain library, newer ones don't. #### System details ``` go version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/kevin.burke/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/kevin.burke"" GOPROXY="""" GORACE="""" GOROOT=""/Users/kevin.burke/go"" GOTMPDIR="""" GOTOOLDIR=""/Users/kevin.burke/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/bs/n3zm0wvn7j14n9gm_ybk4klsg6mgyh/T/go-build618247201=/tmp/go-build -gno-record-gcc-switches -fno-common"" VGOMODROOT="""" GOROOT/bin/go version: go version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 darwin/amd64 GOROOT/bin/go tool compile -V: compile version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G65 lldb --version: lldb-902.0.79.7 Swift-4.1 ``` ",1.0,"cmd/cgo: CoreFoundation go-keychain compile failure on tip - Please answer these questions before submitting your issue. Thanks! #### What did you do? Check out tip of github.com/keybase/go-keychain (commit https://github.com/keybase/go-keychain/commit/70b98e9c8d754db775c5bd3b2de3670cc76f1825) and run `go build github.com/keybase/go-keychain` #### What did you expect to see? I expected the program to compile. #### What did you see instead? ``` $ go build . # github.com/keybase/go-keychain ./corefoundation_1.10.go:55: cannot use nil as type _Ctype_CFAllocatorRef in argument to _Cfunc_CFDataCreate ./corefoundation_1.10.go:81: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal ./corefoundation_1.10.go:118: cannot use nil as type _Ctype_CFAllocatorRef in argument to _Cfunc_CFStringCreateWithBytes ./corefoundation_1.10.go:153: cannot use nil as type _Ctype_CFAllocatorRef in argument to func literal ``` #### Does this issue reproduce with the latest release (go1.10.3)? No. I can reproduce it using tip though, which suggests that this code will break in the upcoming Go 1.11 release. A git bisect revealed that commit 94076feef53c41c0c558a8686d6f2650b1614414 is the first commit to break; versions of Go compiled with commits earlier than this commit successfully compile the go-keychain library, newer ones don't. #### System details ``` go version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/kevin.burke/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/kevin.burke"" GOPROXY="""" GORACE="""" GOROOT=""/Users/kevin.burke/go"" GOTMPDIR="""" GOTOOLDIR=""/Users/kevin.burke/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/bs/n3zm0wvn7j14n9gm_ybk4klsg6mgyh/T/go-build618247201=/tmp/go-build -gno-record-gcc-switches -fno-common"" VGOMODROOT="""" GOROOT/bin/go version: go version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 darwin/amd64 GOROOT/bin/go tool compile -V: compile version devel +94076feef5 Mon Jul 9 22:19:21 2018 +0000 uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G65 lldb --version: lldb-902.0.79.7 Swift-4.1 ``` ",1,cmd cgo corefoundation go keychain compile failure on tip please answer these questions before submitting your issue thanks what did you do check out tip of github com keybase go keychain commit and run go build github com keybase go keychain what did you expect to see i expected the program to compile what did you see instead go build github com keybase go keychain corefoundation go cannot use nil as type ctype cfallocatorref in argument to cfunc cfdatacreate corefoundation go cannot use nil as type ctype cfallocatorref in argument to func literal corefoundation go cannot use nil as type ctype cfallocatorref in argument to cfunc cfstringcreatewithbytes corefoundation go cannot use nil as type ctype cfallocatorref in argument to func literal does this issue reproduce with the latest release no i can reproduce it using tip though which suggests that this code will break in the upcoming go release a git bisect revealed that commit is the first commit to break versions of go compiled with commits earlier than this commit successfully compile the go keychain library newer ones don t system details go version devel mon jul darwin goarch gobin gocache users kevin burke library caches go build goexe gohostarch gohostos darwin goos darwin gopath users kevin burke goproxy gorace goroot users kevin burke go gotmpdir gotooldir users kevin burke go pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders bs t go tmp go build gno record gcc switches fno common vgomodroot goroot bin go version go version devel mon jul darwin goroot bin go tool compile v compile version devel mon jul uname v darwin kernel version thu jun pdt root xnu release productname mac os x productversion buildversion lldb version lldb swift ,1 152015,13441559559.0,IssuesEvent,2020-09-08 04:31:42,golang/go,https://api.github.com/repos/golang/go,opened,testing: document rules for using TB,Documentation,"There's rules about what a `TestFoo` may do with the `*testing.T` it is given. Some are documented (e.g. https://golang.org/pkg/testing/#T puts restrictions on invoking `Fatalf` and friends), but some are not (e.g. `Logf` and probably most other methods should not be called after `TestFoo` returns). Same applies to `*testing.B` and any future such values/types. I came across this while trying to diagnose a problem that seems to be due to #40908, but realised I couldn't find the rules written down anywhere.",1.0,"testing: document rules for using TB - There's rules about what a `TestFoo` may do with the `*testing.T` it is given. Some are documented (e.g. https://golang.org/pkg/testing/#T puts restrictions on invoking `Fatalf` and friends), but some are not (e.g. `Logf` and probably most other methods should not be called after `TestFoo` returns). Same applies to `*testing.B` and any future such values/types. I came across this while trying to diagnose a problem that seems to be due to #40908, but realised I couldn't find the rules written down anywhere.",1,testing document rules for using tb there s rules about what a testfoo may do with the testing t it is given some are documented e g puts restrictions on invoking fatalf and friends but some are not e g logf and probably most other methods should not be called after testfoo returns same applies to testing b and any future such values types i came across this while trying to diagnose a problem that seems to be due to but realised i couldn t find the rules written down anywhere ,1 23773,4974258524.0,IssuesEvent,2016-12-06 05:31:25,golang/go,https://api.github.com/repos/golang/go,opened,doc: installation docs don't list all OS architectures,Documentation,"https://beta.golang.org/doc/install says: Operating System: ""Linux 2.6.23 or later with glibc"" .... Architectures: ""amd64, 386, arm"" That's missing a bunch. Also, for FreeBSD, it only lists amd64, but 386 and arm are also supported. /cc @minux ",1.0,"doc: installation docs don't list all OS architectures - https://beta.golang.org/doc/install says: Operating System: ""Linux 2.6.23 or later with glibc"" .... Architectures: ""amd64, 386, arm"" That's missing a bunch. Also, for FreeBSD, it only lists amd64, but 386 and arm are also supported. /cc @minux ",1,doc installation docs don t list all os architectures says operating system linux or later with glibc architectures arm that s missing a bunch also for freebsd it only lists but and arm are also supported cc minux ,1 58616,8289435903.0,IssuesEvent,2018-09-19 14:41:10,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: provide advice for authors of existing packages with version v2.0+,Documentation NeedsInvestigation modules,"Hi, I was testing vgo the other day, trying to import some 3rd party dependencies that have version v2.0 or higher released on Github, but I couldn't figure out how. Example: Given [github.com/go-chi/chi](https://github.com/go-chi/chi) has latest version v3.3.2 released as a [git tag](https://github.com/go-chi/chi/releases/tag/v3.3.2) on Github, I'd like to import `github.com/go-chi/chi/v3` in my project, develop against it and eventually vendor it via `vgo vendor`. ```go package main import ""github.com/go-chi/chi/v3"" func main() { _ = chi.NewRouter() } ``` But since github.com/go-chi/chi didn't release a v3 module yet, I get this error: ```bash $ vgo run main.go vgo: creating new go.mod: module github.com/VojtechVitek/vgo-test vgo: resolving import ""github.com/go-chi/chi/v3"" vgo: finding github.com/go-chi/chi (latest) vgo: adding github.com/go-chi/chi v1.0.0 vgo: import ""github.com/go-chi/chi/v3"" [/Users/vojtechvitek/go/src/v/github.com/go-chi/chi@v1.0.0/v3]: open /Users/vojtechvitek/go/src/v/github.com/go-chi/chi@v1.0.0/v3: no such file or directory ``` vgo found version v1.0.0 but couldn't find ""v3"" subpkg. So I added an explicit version to my go.mod file and tried again: ``` $ cat go.mod module github.com/VojtechVitek/vgo-test require ( github.com/go-chi/chi v3.3.2 ) ``` running vgo again caused a silent side effect: ```diff module github.com/VojtechVitek/vgo-test require ( - github.com/go-chi/chi v3.3.2 + github.com/go-chi/chi v0.0.0-20171222161133-e83ac2304db3 ) ``` Hmm, seems like vgo doesn't see any v2.0+ tags? After reading some more blog posts on https://research.swtch.com (since `vgo` CLI help didn't seem to be very helpful / novice user friendly), I confirmed with: ``` $ vgo list -t github.com/go-chi/chi github.com/go-chi/chi v0.9.0 v1.0.0 ``` Now, I might be missing something, but it's not really clear to me how can I import v2.0+ or v3.0+ of a package (should I say module?) that I don't have any control over and ""is not ready yet"". Are there any guidelines for package consumers about this? Are there any guidelines for package authors? I couldn't find anything useful neither in research.swtch.com/vgo-module, nor in the accepted proposal or in the [wiki](https://github.com/golang/go/wiki/vgo). // EDIT: ``` $ vgo list -t github.com/go-chi/chi/v3 github.com/go-chi/chi/v3 v3.0.0 v3.1.0 v3.1.1 v3.1.2 v3.1.3 v3.1.4 v3.1.5 v3.2.0 v3.2.1 v3.3.0 v3.3.1 v3.3.2 ``` Ahaa, so I can list v3.0+ tags. But how do I use them in my monorepo properly? ``` $ vgo get github.com/go-chi/chi/v3 vgo: creating new go.mod: module github.com/VojtechVitek/vgo-test vgo: github.com/go-chi/chi/v3 v3.3.2: missing or invalid go.mod vgo get: missing or invalid go.mod ```",1.0,"cmd/go: provide advice for authors of existing packages with version v2.0+ - Hi, I was testing vgo the other day, trying to import some 3rd party dependencies that have version v2.0 or higher released on Github, but I couldn't figure out how. Example: Given [github.com/go-chi/chi](https://github.com/go-chi/chi) has latest version v3.3.2 released as a [git tag](https://github.com/go-chi/chi/releases/tag/v3.3.2) on Github, I'd like to import `github.com/go-chi/chi/v3` in my project, develop against it and eventually vendor it via `vgo vendor`. ```go package main import ""github.com/go-chi/chi/v3"" func main() { _ = chi.NewRouter() } ``` But since github.com/go-chi/chi didn't release a v3 module yet, I get this error: ```bash $ vgo run main.go vgo: creating new go.mod: module github.com/VojtechVitek/vgo-test vgo: resolving import ""github.com/go-chi/chi/v3"" vgo: finding github.com/go-chi/chi (latest) vgo: adding github.com/go-chi/chi v1.0.0 vgo: import ""github.com/go-chi/chi/v3"" [/Users/vojtechvitek/go/src/v/github.com/go-chi/chi@v1.0.0/v3]: open /Users/vojtechvitek/go/src/v/github.com/go-chi/chi@v1.0.0/v3: no such file or directory ``` vgo found version v1.0.0 but couldn't find ""v3"" subpkg. So I added an explicit version to my go.mod file and tried again: ``` $ cat go.mod module github.com/VojtechVitek/vgo-test require ( github.com/go-chi/chi v3.3.2 ) ``` running vgo again caused a silent side effect: ```diff module github.com/VojtechVitek/vgo-test require ( - github.com/go-chi/chi v3.3.2 + github.com/go-chi/chi v0.0.0-20171222161133-e83ac2304db3 ) ``` Hmm, seems like vgo doesn't see any v2.0+ tags? After reading some more blog posts on https://research.swtch.com (since `vgo` CLI help didn't seem to be very helpful / novice user friendly), I confirmed with: ``` $ vgo list -t github.com/go-chi/chi github.com/go-chi/chi v0.9.0 v1.0.0 ``` Now, I might be missing something, but it's not really clear to me how can I import v2.0+ or v3.0+ of a package (should I say module?) that I don't have any control over and ""is not ready yet"". Are there any guidelines for package consumers about this? Are there any guidelines for package authors? I couldn't find anything useful neither in research.swtch.com/vgo-module, nor in the accepted proposal or in the [wiki](https://github.com/golang/go/wiki/vgo). // EDIT: ``` $ vgo list -t github.com/go-chi/chi/v3 github.com/go-chi/chi/v3 v3.0.0 v3.1.0 v3.1.1 v3.1.2 v3.1.3 v3.1.4 v3.1.5 v3.2.0 v3.2.1 v3.3.0 v3.3.1 v3.3.2 ``` Ahaa, so I can list v3.0+ tags. But how do I use them in my monorepo properly? ``` $ vgo get github.com/go-chi/chi/v3 vgo: creating new go.mod: module github.com/VojtechVitek/vgo-test vgo: github.com/go-chi/chi/v3 v3.3.2: missing or invalid go.mod vgo get: missing or invalid go.mod ```",1,cmd go provide advice for authors of existing packages with version hi i was testing vgo the other day trying to import some party dependencies that have version or higher released on github but i couldn t figure out how example given has latest version released as a on github i d like to import github com go chi chi in my project develop against it and eventually vendor it via vgo vendor go package main import github com go chi chi func main chi newrouter but since github com go chi chi didn t release a module yet i get this error bash vgo run main go vgo creating new go mod module github com vojtechvitek vgo test vgo resolving import github com go chi chi vgo finding github com go chi chi latest vgo adding github com go chi chi vgo import github com go chi chi open users vojtechvitek go src v github com go chi chi no such file or directory vgo found version but couldn t find subpkg so i added an explicit version to my go mod file and tried again cat go mod module github com vojtechvitek vgo test require github com go chi chi running vgo again caused a silent side effect diff module github com vojtechvitek vgo test require github com go chi chi github com go chi chi hmm seems like vgo doesn t see any tags after reading some more blog posts on since vgo cli help didn t seem to be very helpful novice user friendly i confirmed with vgo list t github com go chi chi github com go chi chi now i might be missing something but it s not really clear to me how can i import or of a package should i say module that i don t have any control over and is not ready yet are there any guidelines for package consumers about this are there any guidelines for package authors i couldn t find anything useful neither in research swtch com vgo module nor in the accepted proposal or in the edit vgo list t github com go chi chi github com go chi chi ahaa so i can list tags but how do i use them in my monorepo properly vgo get github com go chi chi vgo creating new go mod module github com vojtechvitek vgo test vgo github com go chi chi missing or invalid go mod vgo get missing or invalid go mod ,1 435639,30511131430.0,IssuesEvent,2023-07-18 20:56:44,golang/go,https://api.github.com/repos/golang/go,opened,doc: write release notes for Go 1.22,Documentation NeedsFix release-blocker umbrella,"This is the tracking issue for writing the Go 1.22 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.22. When the Go 1.22 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. The previous issue was #58645.",1.0,"doc: write release notes for Go 1.22 - This is the tracking issue for writing the Go 1.22 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.22. When the Go 1.22 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. The previous issue was #58645.",1,doc write release notes for go this is the tracking issue for writing the go release notes the version at tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release the previous issue was ,1 130845,12463776118.0,IssuesEvent,2020-05-28 11:14:51,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/godoc: support exporting HTML documentation,Documentation Tools WaitingForInfo,"Is there a way to generate a godoc for a module/package or export the generated documentation in a static file format? Currently way of generating docs: `godoc -http=:PORT` Can we add an export button mechanism to the page? That can export the document for the entire project. ",1.0,"x/tools/cmd/godoc: support exporting HTML documentation - Is there a way to generate a godoc for a module/package or export the generated documentation in a static file format? Currently way of generating docs: `godoc -http=:PORT` Can we add an export button mechanism to the page? That can export the document for the entire project. ",1,x tools cmd godoc support exporting html documentation is there a way to generate a godoc for a module package or export the generated documentation in a static file format currently way of generating docs godoc http port can we add an export button mechanism to the page that can export the document for the entire project ,1 117146,9914440812.0,IssuesEvent,2019-06-28 14:23:08,golang/go,https://api.github.com/repos/golang/go,opened,golang.org/x/tools/go/packages: panic in testParseFileModifyAST,NeedsInvestigation Testing,"Observed in https://build.golang.org/log/269df758e38c6dcc180de71777773231b6f98014 (on `windows-amd64-2016`): ``` panic: runtime error: index out of range [recovered] panic: runtime error: index out of range goroutine 512 [running]: testing.tRunner.func1(0xc0001bab00) C:/workdir/go/src/testing/testing.go:830 +0x399 panic(0x6e5800, 0x9959e0) C:/workdir/go/src/runtime/panic.go:522 +0x1c3 golang.org/x/tools/go/packages_test.testParseFileModifyAST(0xc0001bab00, 0x7a5740, 0x9bbf10) C:/workdir/gopath/src/golang.org/x/tools/go/packages/packages_test.go:852 +0x4b9 golang.org/x/tools/go/packages/packagestest.TestAll.func1(0xc0001bab00) C:/workdir/gopath/src/golang.org/x/tools/go/packages/packagestest/export.go:101 +0x6f testing.tRunner(0xc0001bab00, 0xc000047e60) C:/workdir/go/src/testing/testing.go:865 +0xc7 created by testing.(*T).Run C:/workdir/go/src/testing/testing.go:916 +0x361 FAIL golang.org/x/tools/go/packages 17.895s ``` It's not obvious to me whether this is a secondary symptom of the race reported in #31749 or an unrelated bug. CC @matloob @ianthehat ",1.0,"golang.org/x/tools/go/packages: panic in testParseFileModifyAST - Observed in https://build.golang.org/log/269df758e38c6dcc180de71777773231b6f98014 (on `windows-amd64-2016`): ``` panic: runtime error: index out of range [recovered] panic: runtime error: index out of range goroutine 512 [running]: testing.tRunner.func1(0xc0001bab00) C:/workdir/go/src/testing/testing.go:830 +0x399 panic(0x6e5800, 0x9959e0) C:/workdir/go/src/runtime/panic.go:522 +0x1c3 golang.org/x/tools/go/packages_test.testParseFileModifyAST(0xc0001bab00, 0x7a5740, 0x9bbf10) C:/workdir/gopath/src/golang.org/x/tools/go/packages/packages_test.go:852 +0x4b9 golang.org/x/tools/go/packages/packagestest.TestAll.func1(0xc0001bab00) C:/workdir/gopath/src/golang.org/x/tools/go/packages/packagestest/export.go:101 +0x6f testing.tRunner(0xc0001bab00, 0xc000047e60) C:/workdir/go/src/testing/testing.go:865 +0xc7 created by testing.(*T).Run C:/workdir/go/src/testing/testing.go:916 +0x361 FAIL golang.org/x/tools/go/packages 17.895s ``` It's not obvious to me whether this is a secondary symptom of the race reported in #31749 or an unrelated bug. CC @matloob @ianthehat ",0,golang org x tools go packages panic in testparsefilemodifyast observed in on windows panic runtime error index out of range panic runtime error index out of range goroutine testing trunner c workdir go src testing testing go panic c workdir go src runtime panic go golang org x tools go packages test testparsefilemodifyast c workdir gopath src golang org x tools go packages packages test go golang org x tools go packages packagestest testall c workdir gopath src golang org x tools go packages packagestest export go testing trunner c workdir go src testing testing go created by testing t run c workdir go src testing testing go fail golang org x tools go packages it s not obvious to me whether this is a secondary symptom of the race reported in or an unrelated bug cc matloob ianthehat ,0 96630,27963934469.0,IssuesEvent,2023-03-24 17:46:57,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gitmirror: down due to new GitHub key,Builders NeedsFix Soon,https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ broke gitmirror. I'm updating the key built into the Docker image.,1.0,x/build/cmd/gitmirror: down due to new GitHub key - https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ broke gitmirror. I'm updating the key built into the Docker image.,0,x build cmd gitmirror down due to new github key broke gitmirror i m updating the key built into the docker image ,0 275121,20907589675.0,IssuesEvent,2022-03-24 05:09:39,golang/go,https://api.github.com/repos/golang/go,closed,"spec: in array and slice literals, the index/key can be non-integer type",Documentation NeedsFix,"### What version of Go are you using (`go version`)? Go playground ### What operating system and processor architecture are you using (`go env`)? ```golang package main const k float64 = 3.0 var _ = []int{k: 3} var _ = [...]int{k: 3} func main() {} ``` See https://play.golang.org/p/x3keRiD0fVT. This compiles without an error. ### What did you expect to see? From the spec: > For array and slice literals the following rules apply: > * Each element has an associated integer index marking its position in the array. > * An element with a key uses the key as its index. The key must be a non-negative constant representable by a value of type int; and **_if it is typed it must be of integer type_**. > * An element without a key uses the previous element's index plus one. If the first element has no key, its index is zero. It mentions that if the index is typed, it must be of integer type. However, the above code compiles even if the index has type `float64`. Probably the spec should be saying ""can be converted to int"" or something, or the compiler should report an error?",1.0,"spec: in array and slice literals, the index/key can be non-integer type - ### What version of Go are you using (`go version`)? Go playground ### What operating system and processor architecture are you using (`go env`)? ```golang package main const k float64 = 3.0 var _ = []int{k: 3} var _ = [...]int{k: 3} func main() {} ``` See https://play.golang.org/p/x3keRiD0fVT. This compiles without an error. ### What did you expect to see? From the spec: > For array and slice literals the following rules apply: > * Each element has an associated integer index marking its position in the array. > * An element with a key uses the key as its index. The key must be a non-negative constant representable by a value of type int; and **_if it is typed it must be of integer type_**. > * An element without a key uses the previous element's index plus one. If the first element has no key, its index is zero. It mentions that if the index is typed, it must be of integer type. However, the above code compiles even if the index has type `float64`. Probably the spec should be saying ""can be converted to int"" or something, or the compiler should report an error?",1,spec in array and slice literals the index key can be non integer type what version of go are you using go version go playground what operating system and processor architecture are you using go env golang package main const k var int k var int k func main see this compiles without an error what did you expect to see from the spec for array and slice literals the following rules apply each element has an associated integer index marking its position in the array an element with a key uses the key as its index the key must be a non negative constant representable by a value of type int and if it is typed it must be of integer type an element without a key uses the previous element s index plus one if the first element has no key its index is zero it mentions that if the index is typed it must be of integer type however the above code compiles even if the index has type probably the spec should be saying can be converted to int or something or the compiler should report an error ,1 98234,11048750026.0,IssuesEvent,2019-12-09 21:51:31,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document that go env GOMOD can return /dev/null,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? 
$ go version
go version devel +da4d58587e Sat Dec 7 15:57:30 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/myitcv/.cache/go-build""
GOENV=""/home/myitcv/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/myitcv/gostuff""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/myitcv/gos""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build492256999=/tmp/go-build -gno-record-gcc-switches""
### What did you do? The docs for `GOMOD` state: ``` $ go help environment ... GOMOD The absolute path to the go.mod of the main module, or the empty string if not using modules. ``` For some time I have (incorrectly) been advising people that the way to determine if you are in a module context or not (i.e. modules not off and you are in the context of a `go.mod`) is by testing whether the output from `go env GOMOD` is the empty string or not. However this fails when you consider: ``` $ cd $(mktemp -d) $ GO111MODULE=on go env GOMOD /dev/null ``` It's also not clear the docs are quite correct when it comes to modules being not off (i.e. auto or on): ``` $ cd $(mktemp -d) $ go env GOMOD ``` (i.e. empty string, but we aren't not using modules, we are in the auto mode. Granted this is a bit less clearly incorrect) I realise that this way `go env GOMOD` can be used to determine whether modules are off/not off, and whether you are in a module context or not assuming that they are not off. But documenting this a bit more clearly would, I think, help (selfishly me at least). Because the actual logic for correctly determining that modules are not off _and_ you are in a module context is: ```go cmd := exec.Command(""go"", ""env"", ""GOMOD"") out, _ := cmd.CombinedOutput() gomod := strings.TrimSpace(string(out)) if gomod != """" and gomod != os.DevNull { // .... ``` Thoughts? cc @bcmills @jayconrod FYI @mvdan @kortschak ",1.0,"cmd/go: document that go env GOMOD can return /dev/null - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +da4d58587e Sat Dec 7 15:57:30 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/myitcv/.cache/go-build""
GOENV=""/home/myitcv/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/myitcv/gostuff""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/myitcv/gos""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build492256999=/tmp/go-build -gno-record-gcc-switches""
### What did you do? The docs for `GOMOD` state: ``` $ go help environment ... GOMOD The absolute path to the go.mod of the main module, or the empty string if not using modules. ``` For some time I have (incorrectly) been advising people that the way to determine if you are in a module context or not (i.e. modules not off and you are in the context of a `go.mod`) is by testing whether the output from `go env GOMOD` is the empty string or not. However this fails when you consider: ``` $ cd $(mktemp -d) $ GO111MODULE=on go env GOMOD /dev/null ``` It's also not clear the docs are quite correct when it comes to modules being not off (i.e. auto or on): ``` $ cd $(mktemp -d) $ go env GOMOD ``` (i.e. empty string, but we aren't not using modules, we are in the auto mode. Granted this is a bit less clearly incorrect) I realise that this way `go env GOMOD` can be used to determine whether modules are off/not off, and whether you are in a module context or not assuming that they are not off. But documenting this a bit more clearly would, I think, help (selfishly me at least). Because the actual logic for correctly determining that modules are not off _and_ you are in a module context is: ```go cmd := exec.Command(""go"", ""env"", ""GOMOD"") out, _ := cmd.CombinedOutput() gomod := strings.TrimSpace(string(out)) if gomod != """" and gomod != os.DevNull { // .... ``` Thoughts? cc @bcmills @jayconrod FYI @mvdan @kortschak ",1,cmd go document that go env gomod can return dev null what version of go are you using go version go version go version devel sat dec linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home myitcv cache go build goenv home myitcv config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux gopath home myitcv gostuff goprivate goproxy goroot home myitcv gos gosumdb sum golang org gotmpdir gotooldir home myitcv gos pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do the docs for gomod state go help environment gomod the absolute path to the go mod of the main module or the empty string if not using modules for some time i have incorrectly been advising people that the way to determine if you are in a module context or not i e modules not off and you are in the context of a go mod is by testing whether the output from go env gomod is the empty string or not however this fails when you consider cd mktemp d on go env gomod dev null it s also not clear the docs are quite correct when it comes to modules being not off i e auto or on cd mktemp d go env gomod i e empty string but we aren t not using modules we are in the auto mode granted this is a bit less clearly incorrect i realise that this way go env gomod can be used to determine whether modules are off not off and whether you are in a module context or not assuming that they are not off but documenting this a bit more clearly would i think help selfishly me at least because the actual logic for correctly determining that modules are not off and you are in a module context is go cmd exec command go env gomod out cmd combinedoutput gomod strings trimspace string out if gomod and gomod os devnull thoughts cc bcmills jayconrod fyi mvdan kortschak ,1 5805,2974838461.0,IssuesEvent,2015-07-15 05:13:26,golang/go,https://api.github.com/repos/golang/go,closed,time: document how to render milli/micro/nano in time.Format,Documentation,"The reference time described in the docstring for Format doesn't provide a value for nanoseconds. This hides the functionality provided by the Format function to render milli, micro and nanoseconds. This has led to some confusion that Format can't handle sub-second precision: https://groups.google.com/forum/#!topic/golang-nuts/TIinEnPu5wE One option for a solution might just be to add '.000000000' to the reference time in the doc comment.",1.0,"time: document how to render milli/micro/nano in time.Format - The reference time described in the docstring for Format doesn't provide a value for nanoseconds. This hides the functionality provided by the Format function to render milli, micro and nanoseconds. This has led to some confusion that Format can't handle sub-second precision: https://groups.google.com/forum/#!topic/golang-nuts/TIinEnPu5wE One option for a solution might just be to add '.000000000' to the reference time in the doc comment.",1,time document how to render milli micro nano in time format the reference time described in the docstring for format doesn t provide a value for nanoseconds this hides the functionality provided by the format function to render milli micro and nanoseconds this has led to some confusion that format can t handle sub second precision one option for a solution might just be to add to the reference time in the doc comment ,1 84560,7926433657.0,IssuesEvent,2018-07-06 02:06:02,golang/go,https://api.github.com/repos/golang/go,closed,x/net/http2: fragile TestServerHandlerConnectionClose,NeedsFix Testing help wanted,"See https://storage.googleapis.com/go-build-log/28f9b880/windows-386-2008_897ede7f.log and https://storage.googleapis.com/go-build-log/28f9b880/linux-amd64_0ac7746a.log; it's pretty easy to reproduce with the following: ``` go test -v -run TestServerHandlerConnectionClose -count 100 ```",1.0,"x/net/http2: fragile TestServerHandlerConnectionClose - See https://storage.googleapis.com/go-build-log/28f9b880/windows-386-2008_897ede7f.log and https://storage.googleapis.com/go-build-log/28f9b880/linux-amd64_0ac7746a.log; it's pretty easy to reproduce with the following: ``` go test -v -run TestServerHandlerConnectionClose -count 100 ```",0,x net fragile testserverhandlerconnectionclose see and it s pretty easy to reproduce with the following go test v run testserverhandlerconnectionclose count ,0 68452,9187649226.0,IssuesEvent,2019-03-06 03:52:15,golang/go,https://api.github.com/repos/golang/go,closed,doc: Effective Go contains outdated map print result,Documentation,It would be better to either update them or add a note mentioning the print results are for Go 1.12-.,1.0,doc: Effective Go contains outdated map print result - It would be better to either update them or add a note mentioning the print results are for Go 1.12-.,1,doc effective go contains outdated map print result it would be better to either update them or add a note mentioning the print results are for go ,1 58118,8230375841.0,IssuesEvent,2018-09-07 12:45:01,golang/go,https://api.github.com/repos/golang/go,closed,fmt: add examples,Community Documentation NeedsFix,"Let's add examples. I think it would be good to add examples to each function (if possible?) as well as to illustrate some points - not every example should make every point but it would be good to cover these. - how do %d, %s, %q, %v differ - how do you do left/right padding - decimal formatting - how does ""ln"" ending vary from ""f"" ending When you open a change, put this at the bottom of the commit message: ``` Updates golang/go#27376. ``` That way gopherbot will post a comment here with a link to your CL. Add a comment if you want to fix one and I'll put your name next to the func in question. - [x] `func Errorf(format string, a ...interface{}) error`: @ianzapolsky - [ ] func Fprint(w io.Writer, a ...interface{}) (n int, err error) - [ ] `func Fprintf(w io.Writer, format string, a ...interface{}) (n int, err error)`: @MaerF0x0 - [x] `func Fprintln(w io.Writer, a ...interface{}) (n int, err error)`: @waits - [ ] `func Fscan(r io.Reader, a ...interface{}) (n int, err error)`: @andriisoldatenko - [ ] func Fscanf(r io.Reader, format string, a ...interface{}) (n int, err error) - [x] `func Fscanln(r io.Reader, a ...interface{}) (n int, err error)`: @mfrw - [ ] func Print(a ...interface{}) (n int, err error) - [ ] `func Printf(format string, a ...interface{}) (n int, err error)`: @mooreds - [x] `func Println(a ...interface{}) (n int, err error)`: @techmexdev - [ ] func Scan(a ...interface{}) (n int, err error) - [ ] func Scanf(format string, a ...interface{}) (n int, err error) - [ ] func Scanln(a ...interface{}) (n int, err error) - [ ] func Sprint(a ...interface{}) string - [x] `func Sprintf(format string, a ...interface{}) string`: @venilnoronha - [x] `func Sprintln(a ...interface{}) string`: @drewvanstone - [ ] func Sscan(str string, a ...interface{}) (n int, err error) - [ ] func Sscanf(str string, format string, a ...interface{}) (n int, err error) - [ ] func Sscanln(str string, a ...interface{}) (n int, err error) - [ ] type Formatter - [ ] type GoStringer - [ ] type ScanState - [ ] type Scanner - [ ] type State - [x] type Stringer ",1.0,"fmt: add examples - Let's add examples. I think it would be good to add examples to each function (if possible?) as well as to illustrate some points - not every example should make every point but it would be good to cover these. - how do %d, %s, %q, %v differ - how do you do left/right padding - decimal formatting - how does ""ln"" ending vary from ""f"" ending When you open a change, put this at the bottom of the commit message: ``` Updates golang/go#27376. ``` That way gopherbot will post a comment here with a link to your CL. Add a comment if you want to fix one and I'll put your name next to the func in question. - [x] `func Errorf(format string, a ...interface{}) error`: @ianzapolsky - [ ] func Fprint(w io.Writer, a ...interface{}) (n int, err error) - [ ] `func Fprintf(w io.Writer, format string, a ...interface{}) (n int, err error)`: @MaerF0x0 - [x] `func Fprintln(w io.Writer, a ...interface{}) (n int, err error)`: @waits - [ ] `func Fscan(r io.Reader, a ...interface{}) (n int, err error)`: @andriisoldatenko - [ ] func Fscanf(r io.Reader, format string, a ...interface{}) (n int, err error) - [x] `func Fscanln(r io.Reader, a ...interface{}) (n int, err error)`: @mfrw - [ ] func Print(a ...interface{}) (n int, err error) - [ ] `func Printf(format string, a ...interface{}) (n int, err error)`: @mooreds - [x] `func Println(a ...interface{}) (n int, err error)`: @techmexdev - [ ] func Scan(a ...interface{}) (n int, err error) - [ ] func Scanf(format string, a ...interface{}) (n int, err error) - [ ] func Scanln(a ...interface{}) (n int, err error) - [ ] func Sprint(a ...interface{}) string - [x] `func Sprintf(format string, a ...interface{}) string`: @venilnoronha - [x] `func Sprintln(a ...interface{}) string`: @drewvanstone - [ ] func Sscan(str string, a ...interface{}) (n int, err error) - [ ] func Sscanf(str string, format string, a ...interface{}) (n int, err error) - [ ] func Sscanln(str string, a ...interface{}) (n int, err error) - [ ] type Formatter - [ ] type GoStringer - [ ] type ScanState - [ ] type Scanner - [ ] type State - [x] type Stringer ",1,fmt add examples let s add examples i think it would be good to add examples to each function if possible as well as to illustrate some points not every example should make every point but it would be good to cover these how do d s q v differ how do you do left right padding decimal formatting how does ln ending vary from f ending when you open a change put this at the bottom of the commit message updates golang go that way gopherbot will post a comment here with a link to your cl add a comment if you want to fix one and i ll put your name next to the func in question func errorf format string a interface error ianzapolsky func fprint w io writer a interface n int err error func fprintf w io writer format string a interface n int err error func fprintln w io writer a interface n int err error waits func fscan r io reader a interface n int err error andriisoldatenko func fscanf r io reader format string a interface n int err error func fscanln r io reader a interface n int err error mfrw func print a interface n int err error func printf format string a interface n int err error mooreds func println a interface n int err error techmexdev func scan a interface n int err error func scanf format string a interface n int err error func scanln a interface n int err error func sprint a interface string func sprintf format string a interface string venilnoronha func sprintln a interface string drewvanstone func sscan str string a interface n int err error func sscanf str string format string a interface n int err error func sscanln str string a interface n int err error type formatter type gostringer type scanstate type scanner type state type stringer ,1 34340,6312281471.0,IssuesEvent,2017-07-24 02:31:53,golang/go,https://api.github.com/repos/golang/go,opened,"x/crypto/nacl/secretbox: document how small is ""small""",Documentation,"The documentation for secretbox states: Package secretbox encrypts and authenticates small messages. However, it is unclear to a casual reader how small ""small"" is. [""Validation and Verification"" says:](https://nacl.cr.yp.to/valid.html) > Tests are currently limited to 4096-byte messages. This is one of several reasons that callers should (1) split all data into packets sent through the network; (2) put a small global limit on packet length; and (3) separately encrypt and authenticate each packet. With a link to more explanation here: https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ We may want to provide the same advice to callers of this package, and advise them that ""small"" means ""4096 bytes or fewer"" ",1.0,"x/crypto/nacl/secretbox: document how small is ""small"" - The documentation for secretbox states: Package secretbox encrypts and authenticates small messages. However, it is unclear to a casual reader how small ""small"" is. [""Validation and Verification"" says:](https://nacl.cr.yp.to/valid.html) > Tests are currently limited to 4096-byte messages. This is one of several reasons that callers should (1) split all data into packets sent through the network; (2) put a small global limit on packet length; and (3) separately encrypt and authenticate each packet. With a link to more explanation here: https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ We may want to provide the same advice to callers of this package, and advise them that ""small"" means ""4096 bytes or fewer"" ",1,x crypto nacl secretbox document how small is small the documentation for secretbox states package secretbox encrypts and authenticates small messages however it is unclear to a casual reader how small small is tests are currently limited to byte messages this is one of several reasons that callers should split all data into packets sent through the network put a small global limit on packet length and separately encrypt and authenticate each packet with a link to more explanation here we may want to provide the same advice to callers of this package and advise them that small means bytes or fewer ,1 40769,6847922552.0,IssuesEvent,2017-11-13 16:48:29,golang/go,https://api.github.com/repos/golang/go,closed,doc: add a link to code of conduct,Documentation,"GitHub has defined a set of standard meta files to include with projects hosted on GitHub. According to the [GitHub Insights Community](https://github.com/golang/go/community) page for this project the only one missing is the code of conduct. Go has a code of conduct on it's website and we should link to it in the prescribed `.github/CODE_OF_CONDUCT.md` so that developers who go looking for it in the standard location on GitHub projects can find it easily. This would be consistent with the contribution guidelines that are linked to in `.github/CONTRIBUTING.md`. Ref: https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/",1.0,"doc: add a link to code of conduct - GitHub has defined a set of standard meta files to include with projects hosted on GitHub. According to the [GitHub Insights Community](https://github.com/golang/go/community) page for this project the only one missing is the code of conduct. Go has a code of conduct on it's website and we should link to it in the prescribed `.github/CODE_OF_CONDUCT.md` so that developers who go looking for it in the standard location on GitHub projects can find it easily. This would be consistent with the contribution guidelines that are linked to in `.github/CONTRIBUTING.md`. Ref: https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/",1,doc add a link to code of conduct github has defined a set of standard meta files to include with projects hosted on github according to the page for this project the only one missing is the code of conduct go has a code of conduct on it s website and we should link to it in the prescribed github code of conduct md so that developers who go looking for it in the standard location on github projects can find it easily this would be consistent with the contribution guidelines that are linked to in github contributing md ref ,1 64138,8712540762.0,IssuesEvent,2018-12-06 22:34:56,golang/go,https://api.github.com/repos/golang/go,closed,math: docs omit mention of IEEE 754 endianness,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? 1.11 (but N/A) ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? amd64 (but N/A) ### What did you do? Read pkg/math's documentation. ### What did you expect to see? Enough information to determine what bits to expect from `Float64bits` and/or `Float32bits` (and the bits going the other way, too). ### What did you see instead? Just enough information to guess that it's almost certainly either little-endian or big-endian, and may or may not depend on the host architecture. What I'd like to know is, to a first approximation: Will the sign bit be 0x80, 0x1, or 0x8000000? Probably! My default guess would be that byte order would be the same as it is for ints, thus, 0x80000000. But it'd be nice to have that explicit. If I weren't used to Intel, I'd expect the sign bit to be the first bit ""in memory"", meaning that out of a 64-bit float, it would be the bit in the byte with the same address as the whole float, which would be 0x80. It's not, apparently, according to go playground. And that makes sense for Intel CPUs, but I don't know whether it's portable to non-x86 (don't have a go arm64 handy to test on), and I don't know whether it's actually specified or just happens to work out that way.",1.0,"math: docs omit mention of IEEE 754 endianness - ### What version of Go are you using (`go version`)? 1.11 (but N/A) ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? amd64 (but N/A) ### What did you do? Read pkg/math's documentation. ### What did you expect to see? Enough information to determine what bits to expect from `Float64bits` and/or `Float32bits` (and the bits going the other way, too). ### What did you see instead? Just enough information to guess that it's almost certainly either little-endian or big-endian, and may or may not depend on the host architecture. What I'd like to know is, to a first approximation: Will the sign bit be 0x80, 0x1, or 0x8000000? Probably! My default guess would be that byte order would be the same as it is for ints, thus, 0x80000000. But it'd be nice to have that explicit. If I weren't used to Intel, I'd expect the sign bit to be the first bit ""in memory"", meaning that out of a 64-bit float, it would be the bit in the byte with the same address as the whole float, which would be 0x80. It's not, apparently, according to go playground. And that makes sense for Intel CPUs, but I don't know whether it's portable to non-x86 (don't have a go arm64 handy to test on), and I don't know whether it's actually specified or just happens to work out that way.",1,math docs omit mention of ieee endianness what version of go are you using go version but n a does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env but n a what did you do read pkg math s documentation what did you expect to see enough information to determine what bits to expect from and or and the bits going the other way too what did you see instead just enough information to guess that it s almost certainly either little endian or big endian and may or may not depend on the host architecture what i d like to know is to a first approximation will the sign bit be or probably my default guess would be that byte order would be the same as it is for ints thus but it d be nice to have that explicit if i weren t used to intel i d expect the sign bit to be the first bit in memory meaning that out of a bit float it would be the bit in the byte with the same address as the whole float which would be it s not apparently according to go playground and that makes sense for intel cpus but i don t know whether it s portable to non don t have a go handy to test on and i don t know whether it s actually specified or just happens to work out that way ,1 6573,5532635182.0,IssuesEvent,2017-03-21 11:08:54,golang/go,https://api.github.com/repos/golang/go,reopened,cmd/compile: optimize append performance,Performance,"Using `go devel +ed4a27a` I ran the following benchmarks: ``` go func BenchmarkFoo(b *testing.B) { a := make([]byte, 1000) b.SetBytes(int64(len(a))) for i := 0; i < b.N; i++ { var n int for j := 0; j < 1000; j++ { a[n] = byte(j) n++ } a = a[:n] } } func BenchmarkBar(b *testing.B) { a := make([]byte, 1000) b.SetBytes(int64(len(a))) for i := 0; i < b.N; i++ { a = a[:0] for j := 0; j < 1000; j++ { a = append(a, byte(j)) } } } ``` Currently I see: ``` BenchmarkFoo-4 3000000 588 ns/op 1700.17 MB/s BenchmarkBar-4 2000000 871 ns/op 1147.11 MB/s ``` I expect to see these two to perform about the same. @klauspost ",True,"cmd/compile: optimize append performance - Using `go devel +ed4a27a` I ran the following benchmarks: ``` go func BenchmarkFoo(b *testing.B) { a := make([]byte, 1000) b.SetBytes(int64(len(a))) for i := 0; i < b.N; i++ { var n int for j := 0; j < 1000; j++ { a[n] = byte(j) n++ } a = a[:n] } } func BenchmarkBar(b *testing.B) { a := make([]byte, 1000) b.SetBytes(int64(len(a))) for i := 0; i < b.N; i++ { a = a[:0] for j := 0; j < 1000; j++ { a = append(a, byte(j)) } } } ``` Currently I see: ``` BenchmarkFoo-4 3000000 588 ns/op 1700.17 MB/s BenchmarkBar-4 2000000 871 ns/op 1147.11 MB/s ``` I expect to see these two to perform about the same. @klauspost ",0,cmd compile optimize append performance using go devel i ran the following benchmarks go func benchmarkfoo b testing b a make byte b setbytes len a for i i b n i var n int for j j j a byte j n a a func benchmarkbar b testing b a make byte b setbytes len a for i i b n i a a for j j j a append a byte j currently i see benchmarkfoo ns op mb s benchmarkbar ns op mb s i expect to see these two to perform about the same klauspost ,0 186911,15087644456.0,IssuesEvent,2021-02-05 22:35:56,golang/go,https://api.github.com/repos/golang/go,closed,embed: document that paths must satisfy fs.ValidPath(name),Documentation NeedsInvestigation release-blocker,"The embed documentation does not says that paths must also satisfy `fs.ValidPath(name)`. It only says > The path separator is a forward slash, even on Windows systems. and > Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a leading slash. For example in this case: `//go:embed data/` the compiler fails with the error: `pattern data/: invalid pattern syntax` but ""data/"" is valid as pattern, it is not valid for the `fs.ValidPath` function. I think that the sentence > A //go:embed directive above a variable declaration specifies which files to embed, using one or more path.Match patterns. should mention `fs.ValidPath` and consequently ""The path separator is a forward slash, even on Windows systems"" and ""Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a leading slash"" can be removed. ",1.0,"embed: document that paths must satisfy fs.ValidPath(name) - The embed documentation does not says that paths must also satisfy `fs.ValidPath(name)`. It only says > The path separator is a forward slash, even on Windows systems. and > Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a leading slash. For example in this case: `//go:embed data/` the compiler fails with the error: `pattern data/: invalid pattern syntax` but ""data/"" is valid as pattern, it is not valid for the `fs.ValidPath` function. I think that the sentence > A //go:embed directive above a variable declaration specifies which files to embed, using one or more path.Match patterns. should mention `fs.ValidPath` and consequently ""The path separator is a forward slash, even on Windows systems"" and ""Patterns must not contain ‘.’ or ‘..’ path elements nor begin with a leading slash"" can be removed. ",1,embed document that paths must satisfy fs validpath name the embed documentation does not says that paths must also satisfy fs validpath name it only says the path separator is a forward slash even on windows systems and patterns must not contain ‘ ’ or ‘ ’ path elements nor begin with a leading slash for example in this case go embed data the compiler fails with the error pattern data invalid pattern syntax but data is valid as pattern it is not valid for the fs validpath function i think that the sentence a go embed directive above a variable declaration specifies which files to embed using one or more path match patterns should mention fs validpath and consequently the path separator is a forward slash even on windows systems and patterns must not contain ‘ ’ or ‘ ’ path elements nor begin with a leading slash can be removed ,1 132726,10761434058.0,IssuesEvent,2019-10-31 20:46:45,golang/go,https://api.github.com/repos/golang/go,closed,strings: TestBuilderAllocs flake on freebsd-386-12_0,NeedsInvestigation Testing,"`freebsd-386-12_0` (https://build.golang.org/log/380c04df9641b3e5274073af6c25f56e5607e60d): ``` --- FAIL: TestBuilderAllocs (0.00s) builder_test.go:193: got 1 alloc(s); want 0 FAIL FAIL strings 1.570s ``` It's not obvious to me whether this is a bug in the test proper or in `testing.AllocsPerRun`. CC @bradfitz; see previously #24647.",1.0,"strings: TestBuilderAllocs flake on freebsd-386-12_0 - `freebsd-386-12_0` (https://build.golang.org/log/380c04df9641b3e5274073af6c25f56e5607e60d): ``` --- FAIL: TestBuilderAllocs (0.00s) builder_test.go:193: got 1 alloc(s); want 0 FAIL FAIL strings 1.570s ``` It's not obvious to me whether this is a bug in the test proper or in `testing.AllocsPerRun`. CC @bradfitz; see previously #24647.",0,strings testbuilderallocs flake on freebsd freebsd fail testbuilderallocs builder test go got alloc s want fail fail strings it s not obvious to me whether this is a bug in the test proper or in testing allocsperrun cc bradfitz see previously ,0 48764,7456895635.0,IssuesEvent,2018-03-30 00:20:06,golang/go,https://api.github.com/repos/golang/go,closed,fmt: document the behaviour of %p on slices,Documentation,"I was surprised by the following program's output: ```go package main import ( ""fmt"" ) func main() { foo := make([]int, 0, 1) fmt.Printf(""same: %p\n"", foo) foo = append(foo, 0) fmt.Printf(""same: %p\n"", foo) foo = append(foo, 0) fmt.Printf(""different: %p\n"", foo) } ``` Example output: ``` same: 0xc420018060 same: 0xc420018060 different: 0xc420018070 ``` I was expecting an error because there is no documentation regarding `%p` with slices in https://golang.org/pkg/fmt/ but it works fine. I was surprised by the output as the printed address changed when the underlying array of the slice was modified. This is the expected behaviour because fmt is using the reflect package's Pointer() method on the slice, which will return the address of the first element of the slice. See https://github.com/golang/go/blob/38c561cb2caa8019e44059e2be71c909ceef30a6/src/reflect/value.go#L1267-L1269 There should be some documentation regarding this behaviour because it is unexpected imo.",1.0,"fmt: document the behaviour of %p on slices - I was surprised by the following program's output: ```go package main import ( ""fmt"" ) func main() { foo := make([]int, 0, 1) fmt.Printf(""same: %p\n"", foo) foo = append(foo, 0) fmt.Printf(""same: %p\n"", foo) foo = append(foo, 0) fmt.Printf(""different: %p\n"", foo) } ``` Example output: ``` same: 0xc420018060 same: 0xc420018060 different: 0xc420018070 ``` I was expecting an error because there is no documentation regarding `%p` with slices in https://golang.org/pkg/fmt/ but it works fine. I was surprised by the output as the printed address changed when the underlying array of the slice was modified. This is the expected behaviour because fmt is using the reflect package's Pointer() method on the slice, which will return the address of the first element of the slice. See https://github.com/golang/go/blob/38c561cb2caa8019e44059e2be71c909ceef30a6/src/reflect/value.go#L1267-L1269 There should be some documentation regarding this behaviour because it is unexpected imo.",1,fmt document the behaviour of p on slices i was surprised by the following program s output go package main import fmt func main foo make int fmt printf same p n foo foo append foo fmt printf same p n foo foo append foo fmt printf different p n foo example output same same different i was expecting an error because there is no documentation regarding p with slices in but it works fine i was surprised by the output as the printed address changed when the underlying array of the slice was modified this is the expected behaviour because fmt is using the reflect package s pointer method on the slice which will return the address of the first element of the slice see there should be some documentation regarding this behaviour because it is unexpected imo ,1 80699,23284503736.0,IssuesEvent,2022-08-05 15:07:38,golang/go,https://api.github.com/repos/golang/go,closed,x/build: various timeouts on dragonfly-amd64 builder,OS-Dragonfly Builders NeedsInvestigation,"``` --- FAIL: TestScript (0.02s) --- FAIL: TestScript/mod_all (8.94s) [...] rflags 0x202 cs 0x2b fs 0x23 gs 0x23 [context deadline exceeded] FAIL: testdata/script/list_test_err.txt:9: test timed out while running command FAIL FAIL cmd/go 1058.031s ``` [2022-07-29T14:06:25-9240558/dragonfly-amd64](https://build.golang.org/log/39b27fbeef550eeb193f208fc1048f4fbd65a4ad) ``` [... cs 0x2b fs 0x23 gs 0x23 *** Test killed with quit: ran too long (7m0s). FAIL cmd/api 420.188s ``` [2022-07-27T17:20:18-be7c681/dragonfly-amd64](https://build.golang.org/log/7dc0d7d207c4b7e412476fc2545dbe2d92259910) [2022-07-27T16:54:19-76ba1a5/dragonfly-amd64](https://build.golang.org/log/97552ee3076db66d80311a555b20b6d37862c89a) Possibly also related to timeouts in x/tools/cmd/fiximports in #50775.",1.0,"x/build: various timeouts on dragonfly-amd64 builder - ``` --- FAIL: TestScript (0.02s) --- FAIL: TestScript/mod_all (8.94s) [...] rflags 0x202 cs 0x2b fs 0x23 gs 0x23 [context deadline exceeded] FAIL: testdata/script/list_test_err.txt:9: test timed out while running command FAIL FAIL cmd/go 1058.031s ``` [2022-07-29T14:06:25-9240558/dragonfly-amd64](https://build.golang.org/log/39b27fbeef550eeb193f208fc1048f4fbd65a4ad) ``` [... cs 0x2b fs 0x23 gs 0x23 *** Test killed with quit: ran too long (7m0s). FAIL cmd/api 420.188s ``` [2022-07-27T17:20:18-be7c681/dragonfly-amd64](https://build.golang.org/log/7dc0d7d207c4b7e412476fc2545dbe2d92259910) [2022-07-27T16:54:19-76ba1a5/dragonfly-amd64](https://build.golang.org/log/97552ee3076db66d80311a555b20b6d37862c89a) Possibly also related to timeouts in x/tools/cmd/fiximports in #50775.",0,x build various timeouts on dragonfly builder fail testscript fail testscript mod all rflags cs fs gs fail testdata script list test err txt test timed out while running command fail fail cmd go cs fs gs test killed with quit ran too long fail cmd api possibly also related to timeouts in x tools cmd fiximports in ,0 251513,21486378214.0,IssuesEvent,2022-04-27 00:11:08,golang/go,https://api.github.com/repos/golang/go,closed,runtime: TestSmhasherWindowed is still flaky on linux-386-longtest,Testing NeedsInvestigation release-blocker,"[2020-12-10T22:58:49-6d3d3fb/linux-386-longtest](https://build.golang.org/log/5750dc9ccbde14acb96e92ecba6aa5a13d18c2f0) ``` ##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick --- FAIL: TestSmhasherWindowed (27.87s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys --- FAIL: TestSmhasherWindowed (26.69s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys --- FAIL: TestSmhasherWindowed (26.69s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys FAIL FAIL runtime 598.996s ``` [2020-10-26T21:47:49-36c5edd/linux-386-longtest](https://build.golang.org/log/02cd0210da985203ebd477cc274346b4d8f77da7) ``` --- FAIL: TestSmhasherWindowed (26.23s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:570: string keys FAIL FAIL runtime 169.624s ``` See previously #39352. I would guess that it's flaky on 32-bit ARM too, but we don't have a `longtest` builder for that configuration. CC @randall77 ",1.0,"runtime: TestSmhasherWindowed is still flaky on linux-386-longtest - [2020-12-10T22:58:49-6d3d3fb/linux-386-longtest](https://build.golang.org/log/5750dc9ccbde14acb96e92ecba6aa5a13d18c2f0) ``` ##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick --- FAIL: TestSmhasherWindowed (27.87s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys --- FAIL: TestSmhasherWindowed (26.69s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys --- FAIL: TestSmhasherWindowed (26.69s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:570: string keys FAIL FAIL runtime 598.996s ``` [2020-10-26T21:47:49-36c5edd/linux-386-longtest](https://build.golang.org/log/02cd0210da985203ebd477cc274346b4d8f77da7) ``` --- FAIL: TestSmhasherWindowed (26.23s) hash_test.go:566: 32 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:568: 64 bit keys hash_test.go:161: unexpected number of collisions: got=512 mean=0.499992 stddev=0.707101 threshold=156.565200 hash_test.go:570: string keys FAIL FAIL runtime 169.624s ``` See previously #39352. I would guess that it's flaky on 32-bit ARM too, but we don't have a `longtest` builder for that configuration. CC @randall77 ",0,runtime testsmhasherwindowed is still flaky on linux longtest gomaxprocs runtime cpu quick fail testsmhasherwindowed hash test go bit keys hash test go unexpected number of collisions got mean stddev threshold hash test go bit keys hash test go string keys fail testsmhasherwindowed hash test go bit keys hash test go unexpected number of collisions got mean stddev threshold hash test go bit keys hash test go string keys fail testsmhasherwindowed hash test go bit keys hash test go unexpected number of collisions got mean stddev threshold hash test go bit keys hash test go string keys fail fail runtime fail testsmhasherwindowed hash test go bit keys hash test go unexpected number of collisions got mean stddev threshold hash test go bit keys hash test go unexpected number of collisions got mean stddev threshold hash test go string keys fail fail runtime see previously i would guess that it s flaky on bit arm too but we don t have a longtest builder for that configuration cc ,0 39279,6733497169.0,IssuesEvent,2017-10-18 14:59:49,golang/go,https://api.github.com/repos/golang/go,opened,"x/net: Update ""net/context"" documentation to point to context package",Documentation,"I was trying to figure out the difference between the ""golang.org/x/net/context"" and ""context, "" and I couldn't find any, so I was a little bit confused. I had to dig into the release notes until I saw the release notes for [1.7](https://golang.org/doc/go1.7#context) where it says: > Go 1.7 moves the golang.org/x/net/context package into the standard library as context. It would be helpful to update the doc in ""x/net/context"" to point to the release note. Also, I notice that go tool fix help you to change imports of golang.org/x/net/context to context. It would be cool to reference that too. I would be happy to help with a patch if you think is worth it. ",1.0,"x/net: Update ""net/context"" documentation to point to context package - I was trying to figure out the difference between the ""golang.org/x/net/context"" and ""context, "" and I couldn't find any, so I was a little bit confused. I had to dig into the release notes until I saw the release notes for [1.7](https://golang.org/doc/go1.7#context) where it says: > Go 1.7 moves the golang.org/x/net/context package into the standard library as context. It would be helpful to update the doc in ""x/net/context"" to point to the release note. Also, I notice that go tool fix help you to change imports of golang.org/x/net/context to context. It would be cool to reference that too. I would be happy to help with a patch if you think is worth it. ",1,x net update net context documentation to point to context package i was trying to figure out the difference between the golang org x net context and context and i couldn t find any so i was a little bit confused i had to dig into the release notes until i saw the release notes for where it says go moves the golang org x net context package into the standard library as context it would be helpful to update the doc in x net context to point to the release note also i notice that go tool fix help you to change imports of golang org x net context to context it would be cool to reference that too i would be happy to help with a patch if you think is worth it ,1 22100,4773034418.0,IssuesEvent,2016-10-26 22:46:43,golang/go,https://api.github.com/repos/golang/go,closed,net/http/httptest: Better document usage of ResponseRecorder.HeaderMap vs. ResponseRecorder.Result,Documentation NeedsFix,"The Go 1.7 release notes say: > The ResponseRecorder's new Result method returns the recorded http.Response. Tests that need to check the response's headers or trailers should call Result and inspect the response fields instead of accessing ResponseRecorder's HeaderMap directly. However, the documentation itself doesn't give much guidance. The closest it says is > The Response.Header is a snapshot of the headers at the time of the first write call, or at the time of this call, if the handler never did a write. If I were just reading the httptest docs, I would probably just use HeaderMap as it's more convenient. It would be good to put a caveat by the definition of HeaderMap.",1.0,"net/http/httptest: Better document usage of ResponseRecorder.HeaderMap vs. ResponseRecorder.Result - The Go 1.7 release notes say: > The ResponseRecorder's new Result method returns the recorded http.Response. Tests that need to check the response's headers or trailers should call Result and inspect the response fields instead of accessing ResponseRecorder's HeaderMap directly. However, the documentation itself doesn't give much guidance. The closest it says is > The Response.Header is a snapshot of the headers at the time of the first write call, or at the time of this call, if the handler never did a write. If I were just reading the httptest docs, I would probably just use HeaderMap as it's more convenient. It would be good to put a caveat by the definition of HeaderMap.",1,net http httptest better document usage of responserecorder headermap vs responserecorder result the go release notes say the responserecorder s new result method returns the recorded http response tests that need to check the response s headers or trailers should call result and inspect the response fields instead of accessing responserecorder s headermap directly however the documentation itself doesn t give much guidance the closest it says is the response header is a snapshot of the headers at the time of the first write call or at the time of this call if the handler never did a write if i were just reading the httptest docs i would probably just use headermap as it s more convenient it would be good to put a caveat by the definition of headermap ,1 195127,15501387696.0,IssuesEvent,2021-03-11 10:28:29,golang/go,https://api.github.com/repos/golang/go,closed,request the chinese document page got the error,Documentation,"#### [document links](https://go-zh.org/doc/) ##### step 1. click this button ![1615457102(1)](https://user-images.githubusercontent.com/24775116/110771085-13459f80-8295-11eb-98f7-f6ab9efc618c.png) 2. got error ![1615457552(1)](https://user-images.githubusercontent.com/24775116/110771385-661f5700-8295-11eb-970d-ef501c16856f.jpg)",1.0,"request the chinese document page got the error - #### [document links](https://go-zh.org/doc/) ##### step 1. click this button ![1615457102(1)](https://user-images.githubusercontent.com/24775116/110771085-13459f80-8295-11eb-98f7-f6ab9efc618c.png) 2. got error ![1615457552(1)](https://user-images.githubusercontent.com/24775116/110771385-661f5700-8295-11eb-970d-ef501c16856f.jpg)",1,request the chinese document page got the error step click this button got error ,1 294783,22162671649.0,IssuesEvent,2022-06-04 18:42:43,golang/go,https://api.github.com/repos/golang/go,closed,doc: update Go memory model,Documentation Proposal Proposal-Accepted release-blocker Proposal-FinalCommentPeriod,"In June 2021 I posted a series of articles about memory models, ending with an article about changes I thought we should make to the Go memory model. See https://research.swtch.com/mm especially https://research.swtch.com/gomm. Then I opened a GitHub Discussion to discuss these changes; see #47141. Based on that discussion, I propose the following concrete changes to the memory model: - Document Go's overall approach. - Document that multiword races can cause crashes. - Document happens-before for runtime.SetFinalizer. - Document (or link to) happens-before for more sync types. - Document happens-before for sync/atomic, matching C++ sequentially consistent atomics (and Java, JavaScript, Rust, Swift, C, ...) - Document disallowed compiler optimizations. The exact details can be viewed in pending CLs prepared for concreteness, in particular [CL 381315](https://go.dev/cl/381315) (memory model) and [CL 381316](https://go.dev/cl/381316) (library docs). I have filed a separate proposal - #50860 - for another item that arose during that discussion, namely adding typed atomic values to sync/atomic. ",1.0,"doc: update Go memory model - In June 2021 I posted a series of articles about memory models, ending with an article about changes I thought we should make to the Go memory model. See https://research.swtch.com/mm especially https://research.swtch.com/gomm. Then I opened a GitHub Discussion to discuss these changes; see #47141. Based on that discussion, I propose the following concrete changes to the memory model: - Document Go's overall approach. - Document that multiword races can cause crashes. - Document happens-before for runtime.SetFinalizer. - Document (or link to) happens-before for more sync types. - Document happens-before for sync/atomic, matching C++ sequentially consistent atomics (and Java, JavaScript, Rust, Swift, C, ...) - Document disallowed compiler optimizations. The exact details can be viewed in pending CLs prepared for concreteness, in particular [CL 381315](https://go.dev/cl/381315) (memory model) and [CL 381316](https://go.dev/cl/381316) (library docs). I have filed a separate proposal - #50860 - for another item that arose during that discussion, namely adding typed atomic values to sync/atomic. ",1,doc update go memory model in june i posted a series of articles about memory models ending with an article about changes i thought we should make to the go memory model see especially then i opened a github discussion to discuss these changes see based on that discussion i propose the following concrete changes to the memory model document go s overall approach document that multiword races can cause crashes document happens before for runtime setfinalizer document or link to happens before for more sync types document happens before for sync atomic matching c sequentially consistent atomics and java javascript rust swift c document disallowed compiler optimizations the exact details can be viewed in pending cls prepared for concreteness in particular memory model and library docs i have filed a separate proposal for another item that arose during that discussion namely adding typed atomic values to sync atomic ,1 33349,6198137992.0,IssuesEvent,2017-07-05 18:27:49,golang/go,https://api.github.com/repos/golang/go,closed,runtime/pprof: Undefined type referred to in function comment,Documentation NeedsFix,"### What version of Go are you using (`go version`)? 1.9beta ### What did you do? Read documentation of `runtime/pprof` for Profiler Labels (http://tip.golang.org/pkg/runtime/pprof/#Labels) ### What did you expect to see? The function comment for http://tip.golang.org/pkg/runtime/pprof/#Labels should describe the return value as type LabelSet. ### What did you see instead? The typename returned by http://tip.golang.org/pkg/runtime/pprof/#Labels is LabelSet, but the documentation string refers to it as LabelList. ",1.0,"runtime/pprof: Undefined type referred to in function comment - ### What version of Go are you using (`go version`)? 1.9beta ### What did you do? Read documentation of `runtime/pprof` for Profiler Labels (http://tip.golang.org/pkg/runtime/pprof/#Labels) ### What did you expect to see? The function comment for http://tip.golang.org/pkg/runtime/pprof/#Labels should describe the return value as type LabelSet. ### What did you see instead? The typename returned by http://tip.golang.org/pkg/runtime/pprof/#Labels is LabelSet, but the documentation string refers to it as LabelList. ",1,runtime pprof undefined type referred to in function comment what version of go are you using go version what did you do read documentation of runtime pprof for profiler labels what did you expect to see the function comment for should describe the return value as type labelset what did you see instead the typename returned by is labelset but the documentation string refers to it as labellist ,1 189617,15192028314.0,IssuesEvent,2021-02-15 21:07:56,golang/go,https://api.github.com/repos/golang/go,opened,os: docs say nothing about path slash types,Documentation,"The `os` package docs say: > Package os provides a platform-independent interface to operating system functionality. The design is Unix-like, although the error handling is Go-like But nowhere at https://golang.org/pkg/os/ is ""slash"" mentioned. Yet there are two Go packages about paths and their slashes: `path` and `path/filepath`. That quoted line above might suggest only forward slashes are permitted (""the design is Unix-like""). Seems like the `os` package should say what it permits. Users will wonder: forward only? host native only? either way?",1.0,"os: docs say nothing about path slash types - The `os` package docs say: > Package os provides a platform-independent interface to operating system functionality. The design is Unix-like, although the error handling is Go-like But nowhere at https://golang.org/pkg/os/ is ""slash"" mentioned. Yet there are two Go packages about paths and their slashes: `path` and `path/filepath`. That quoted line above might suggest only forward slashes are permitted (""the design is Unix-like""). Seems like the `os` package should say what it permits. Users will wonder: forward only? host native only? either way?",1,os docs say nothing about path slash types the os package docs say package os provides a platform independent interface to operating system functionality the design is unix like although the error handling is go like but nowhere at is slash mentioned yet there are two go packages about paths and their slashes path and path filepath that quoted line above might suggest only forward slashes are permitted the design is unix like seems like the os package should say what it permits users will wonder forward only host native only either way ,1 44156,23510549730.0,IssuesEvent,2022-08-18 16:07:00,golang/go,https://api.github.com/repos/golang/go,closed,runtime: count globals toward GC trigger,Performance NeedsInvestigation compiler/runtime,"[CL 39471](https://golang.org/cl/39471) moves a large cache from the heap to a global. (A single Ctxt object is allocated at the beginning of compilation, so there's exactly one of these Prog caches, both before and after the CL.) The CL is just a simplified demo, but it mimics something real I want to do. The CL causes GC to use lots more CPU when compiling package archive/tar. (It affects other packages as well, but archive/tar shows it most prominently.) ``` name old time/op new time/op delta Tar 119ms ± 5% 120ms ± 3% ~ (p=0.061 n=45+46) name old user-ns/op new user-ns/op delta Tar 138M ± 5% 158M ± 7% +14.30% (p=0.000 n=44+48) ``` Note that the real time is about the same--the compiler itself is doing the same amount of work--but the CPU consumed goes up considerably. I'd expect it to be unchanged. @aclements @RLH ",True,"runtime: count globals toward GC trigger - [CL 39471](https://golang.org/cl/39471) moves a large cache from the heap to a global. (A single Ctxt object is allocated at the beginning of compilation, so there's exactly one of these Prog caches, both before and after the CL.) The CL is just a simplified demo, but it mimics something real I want to do. The CL causes GC to use lots more CPU when compiling package archive/tar. (It affects other packages as well, but archive/tar shows it most prominently.) ``` name old time/op new time/op delta Tar 119ms ± 5% 120ms ± 3% ~ (p=0.061 n=45+46) name old user-ns/op new user-ns/op delta Tar 138M ± 5% 158M ± 7% +14.30% (p=0.000 n=44+48) ``` Note that the real time is about the same--the compiler itself is doing the same amount of work--but the CPU consumed goes up considerably. I'd expect it to be unchanged. @aclements @RLH ",0,runtime count globals toward gc trigger moves a large cache from the heap to a global a single ctxt object is allocated at the beginning of compilation so there s exactly one of these prog caches both before and after the cl the cl is just a simplified demo but it mimics something real i want to do the cl causes gc to use lots more cpu when compiling package archive tar it affects other packages as well but archive tar shows it most prominently name old time op new time op delta tar ± ± p n name old user ns op new user ns op delta tar ± ± p n note that the real time is about the same the compiler itself is doing the same amount of work but the cpu consumed goes up considerably i d expect it to be unchanged aclements rlh ,0 168335,14146115157.0,IssuesEvent,2020-11-10 18:43:31,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: add release note for defaulting to -mod=readonly,Documentation NeedsFix release-blocker,"As noted in https://github.com/golang/go/issues/40728#issuecomment-723561987, the change to default to `-mod=readonly` for Go 1.16 has a substantial impact on user workflows, so it should have a release note before the beta. (The main issue is tagged as a proposal, so rather than reopening that issue and disrupting the proposal automation, I'm filing a separate doc issue.) CC @jayconrod @matloob @mvdan ",1.0,"cmd/go: add release note for defaulting to -mod=readonly - As noted in https://github.com/golang/go/issues/40728#issuecomment-723561987, the change to default to `-mod=readonly` for Go 1.16 has a substantial impact on user workflows, so it should have a release note before the beta. (The main issue is tagged as a proposal, so rather than reopening that issue and disrupting the proposal automation, I'm filing a separate doc issue.) CC @jayconrod @matloob @mvdan ",1,cmd go add release note for defaulting to mod readonly as noted in the change to default to mod readonly for go has a substantial impact on user workflows so it should have a release note before the beta the main issue is tagged as a proposal so rather than reopening that issue and disrupting the proposal automation i m filing a separate doc issue cc jayconrod matloob mvdan ,1 10006,7056203816.0,IssuesEvent,2018-01-04 11:45:29,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: expand TestIntendedInlining to more packages and funcs,Performance,"#17566 is about improving the inlining cost model. Making changes to the compiler, especially touching the inlining heuristics, always has the risk of unintentionally making some funcs non-inlineable, potentially resulting in noticeable performance regressions. That's why @josharian added `TestIntendedInlining`: https://go-review.googlesource.com/c/go/+/57410 It basically runs `go build -a -gcflags=-m runtime` and checks that certain funcs are printed in a line along with `can inline`. However, the test is limited to the runtime. There are other small functions in the standard library that we want to be inlineable, and which we even tweak to appease the current heuristic. A recent example: https://go-review.googlesource.com/c/go/+/63332 I propose that we add a way to cover more funcs in other packages within `std`. Thoughts: * We probably want to focus on low-level and basic packages first, like `unicode/utf8` and `bytes` * Should we modify `TestIntendedInlining`, or add a new test? (given how it uses `build -a`, I presume a single test would be the fastest) * If it covers more than just `runtime`, I presume we would want the test out of the `runtime` package (where? cmd/compile?) Suggestions of funcs/packages to add welcome. Happy to work on it if pointers on the above are given. CC @TocarIP @josharian @martisch ",True,"cmd/compile: expand TestIntendedInlining to more packages and funcs - #17566 is about improving the inlining cost model. Making changes to the compiler, especially touching the inlining heuristics, always has the risk of unintentionally making some funcs non-inlineable, potentially resulting in noticeable performance regressions. That's why @josharian added `TestIntendedInlining`: https://go-review.googlesource.com/c/go/+/57410 It basically runs `go build -a -gcflags=-m runtime` and checks that certain funcs are printed in a line along with `can inline`. However, the test is limited to the runtime. There are other small functions in the standard library that we want to be inlineable, and which we even tweak to appease the current heuristic. A recent example: https://go-review.googlesource.com/c/go/+/63332 I propose that we add a way to cover more funcs in other packages within `std`. Thoughts: * We probably want to focus on low-level and basic packages first, like `unicode/utf8` and `bytes` * Should we modify `TestIntendedInlining`, or add a new test? (given how it uses `build -a`, I presume a single test would be the fastest) * If it covers more than just `runtime`, I presume we would want the test out of the `runtime` package (where? cmd/compile?) Suggestions of funcs/packages to add welcome. Happy to work on it if pointers on the above are given. CC @TocarIP @josharian @martisch ",0,cmd compile expand testintendedinlining to more packages and funcs is about improving the inlining cost model making changes to the compiler especially touching the inlining heuristics always has the risk of unintentionally making some funcs non inlineable potentially resulting in noticeable performance regressions that s why josharian added testintendedinlining it basically runs go build a gcflags m runtime and checks that certain funcs are printed in a line along with can inline however the test is limited to the runtime there are other small functions in the standard library that we want to be inlineable and which we even tweak to appease the current heuristic a recent example i propose that we add a way to cover more funcs in other packages within std thoughts we probably want to focus on low level and basic packages first like unicode and bytes should we modify testintendedinlining or add a new test given how it uses build a i presume a single test would be the fastest if it covers more than just runtime i presume we would want the test out of the runtime package where cmd compile suggestions of funcs packages to add welcome happy to work on it if pointers on the above are given cc tocarip josharian martisch ,0 232218,17776404556.0,IssuesEvent,2021-08-30 19:50:30,golang/go,https://api.github.com/repos/golang/go,opened,dl: switch to go install path@latest syntax in documentation,Documentation NeedsFix modules,"Now that Go 1.17 is released and Go 1.15 in unsupported per [release policy](https://golang.org/doc/devel/release#policy), we should update documentation of [`golang.org/dl/go1.N` commands](https://pkg.go.dev/golang.org/dl#section-directories) to suggest the new `go install path@latest` installation syntax instead of `go get` per #43684. It should be okay to update documentation for all `golang.org/dl/...` commands, even pre-1.15 ones, since they're still meant to serve supported Go versions, all of which by now support the new syntax. CC @golang/release, @bcmills, @jayconrod, @matloob.",1.0,"dl: switch to go install path@latest syntax in documentation - Now that Go 1.17 is released and Go 1.15 in unsupported per [release policy](https://golang.org/doc/devel/release#policy), we should update documentation of [`golang.org/dl/go1.N` commands](https://pkg.go.dev/golang.org/dl#section-directories) to suggest the new `go install path@latest` installation syntax instead of `go get` per #43684. It should be okay to update documentation for all `golang.org/dl/...` commands, even pre-1.15 ones, since they're still meant to serve supported Go versions, all of which by now support the new syntax. CC @golang/release, @bcmills, @jayconrod, @matloob.",1,dl switch to go install path latest syntax in documentation now that go is released and go in unsupported per we should update documentation of to suggest the new go install path latest installation syntax instead of go get per it should be okay to update documentation for all golang org dl commands even pre ones since they re still meant to serve supported go versions all of which by now support the new syntax cc golang release bcmills jayconrod matloob ,1 135077,12663369662.0,IssuesEvent,2020-06-18 01:08:03,golang/go,https://api.github.com/repos/golang/go,closed,net/rpc: unclear documentation for Call.Done,Documentation NeedsDecision,"``` $ go doc net/rpc Call.Done package rpc // import ""net/rpc"" type Call struct { Done chan *Call // Strobes when call is complete. // ... other fields elided ... } ``` What does ""strobes"" mean in this context? Let's reword. cc @robpike ",1.0,"net/rpc: unclear documentation for Call.Done - ``` $ go doc net/rpc Call.Done package rpc // import ""net/rpc"" type Call struct { Done chan *Call // Strobes when call is complete. // ... other fields elided ... } ``` What does ""strobes"" mean in this context? Let's reword. cc @robpike ",1,net rpc unclear documentation for call done go doc net rpc call done package rpc import net rpc type call struct done chan call strobes when call is complete other fields elided what does strobes mean in this context let s reword cc robpike ,1 16719,4080260311.0,IssuesEvent,2016-05-31 00:23:23,golang/go,https://api.github.com/repos/golang/go,closed,sync: document that double RLock isn't safe,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6 darwin/amd64 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH="""" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" 3. What did you do? ```go package main import ( ""fmt"" ""sync"" ) func main() { ch := make(chan int) testFunc := func() { weirdLock := sync.RWMutex{} go func() { weirdLock.RLock() go func() { weirdLock.RLock() for i := 0; i < 3; i++ { func() { weirdLock.RLock() ch <- 1 weirdLock.RUnlock() }() } weirdLock.RUnlock() }() weirdLock.RUnlock() }() go func() { weirdLock.Lock() ch <- 1 weirdLock.Unlock() }() } runNum := 1000 for i := 0; i < runNum; i++ { testFunc() } total := 0 for i := 0; i < 4*runNum; i++ { total += <-ch } //Expect 4*runNum fmt.Println(total) } ``` http://play.golang.org/p/UWIAmPCRCu 4. What did you expect to see? output 4000 5. What did you see instead? `fatal error: all goroutines are asleep - deadlock!` runNum more big，the probability of deadlock more often ",1.0,"sync: document that double RLock isn't safe - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6 darwin/amd64 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH="""" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" 3. What did you do? ```go package main import ( ""fmt"" ""sync"" ) func main() { ch := make(chan int) testFunc := func() { weirdLock := sync.RWMutex{} go func() { weirdLock.RLock() go func() { weirdLock.RLock() for i := 0; i < 3; i++ { func() { weirdLock.RLock() ch <- 1 weirdLock.RUnlock() }() } weirdLock.RUnlock() }() weirdLock.RUnlock() }() go func() { weirdLock.Lock() ch <- 1 weirdLock.Unlock() }() } runNum := 1000 for i := 0; i < runNum; i++ { testFunc() } total := 0 for i := 0; i < 4*runNum; i++ { total += <-ch } //Expect 4*runNum fmt.Println(total) } ``` http://play.golang.org/p/UWIAmPCRCu 4. What did you expect to see? output 4000 5. What did you see instead? `fatal error: all goroutines are asleep - deadlock!` runNum more big，the probability of deadlock more often ",1,sync document that double rlock isn t safe please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath gorace goroot usr local go gotooldir usr local go pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fno common cxx clang cgo enabled what did you do go package main import fmt sync func main ch make chan int testfunc func weirdlock sync rwmutex go func weirdlock rlock go func weirdlock rlock for i i i func weirdlock rlock ch weirdlock runlock weirdlock runlock weirdlock runlock go func weirdlock lock ch weirdlock unlock runnum for i i runnum i testfunc total for i i runnum i total ch expect runnum fmt println total what did you expect to see output what did you see instead fatal error all goroutines are asleep deadlock runnum more big，the probability of deadlock more often ,1 14662,3872871474.0,IssuesEvent,2016-04-11 15:10:57,golang/go,https://api.github.com/repos/golang/go,closed,spec: define what a function is,Documentation,
There's almost no text on what a function actually is. Needs to be expanded.
,1.0,spec: define what a function is - 
There's almost no text on what a function actually is. Needs to be expanded.
,1,spec define what a function is there s almost no text on what a function actually is needs to be expanded ,1 32175,6037238832.0,IssuesEvent,2017-06-09 18:10:05,golang/go,https://api.github.com/repos/golang/go,closed,os/exec: docs bugs sections points to an issue with unsupported OS version,Documentation,"https://golang.org/pkg/os/exec/#pkg-note-BUG points to a bug which exists in an unsupported macosx version 10.6 only (I suppose). (https://github.com/golang/go/wiki/MinimumRequirements) Should this be removed?",1.0,"os/exec: docs bugs sections points to an issue with unsupported OS version - https://golang.org/pkg/os/exec/#pkg-note-BUG points to a bug which exists in an unsupported macosx version 10.6 only (I suppose). (https://github.com/golang/go/wiki/MinimumRequirements) Should this be removed?",1,os exec docs bugs sections points to an issue with unsupported os version points to a bug which exists in an unsupported macosx version only i suppose should this be removed ,1 278802,21097007494.0,IssuesEvent,2022-04-04 11:17:01,golang/go,https://api.github.com/repos/golang/go,closed,strings: Docs & Examples unclear about difference between ToTitle and ToUpper,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? The current documentation on https://golang.org/pkg/strings/ ### Does this issue reproduce with the latest release? Yes, using the examples inside the strings package documentation ### What operating system and processor architecture are you using (`go env`)? None providable ### What did you do? Copied `strings.ToTitle` example to `strings.ToUpper` and changed `ToTitle()` to `ToUpper()`: ``` package main import ( ""fmt"" ""strings"" ) func main() { fmt.Println(strings.ToUpper(""her royal highness"")) fmt.Println(strings.ToUpper(""loud noises"")) fmt.Println(strings.ToUpper(""хлеб"")) } ``` ### What did you expect to see? A difference in output. ### What did you see instead? Example ToTitle (unmodified) outputs: ``` HER ROYAL HIGHNESS LOUD NOISES ХЛЕБ ``` Example ToUpper (modified as described above) outputs: ``` HER ROYAL HIGHNESS LOUD NOISES ХЛЕБ ``` No difference. So for me it is unclear which function is now the correct one to use for an imaginary case.",1.0,"strings: Docs & Examples unclear about difference between ToTitle and ToUpper - ### What version of Go are you using (`go version`)? The current documentation on https://golang.org/pkg/strings/ ### Does this issue reproduce with the latest release? Yes, using the examples inside the strings package documentation ### What operating system and processor architecture are you using (`go env`)? None providable ### What did you do? Copied `strings.ToTitle` example to `strings.ToUpper` and changed `ToTitle()` to `ToUpper()`: ``` package main import ( ""fmt"" ""strings"" ) func main() { fmt.Println(strings.ToUpper(""her royal highness"")) fmt.Println(strings.ToUpper(""loud noises"")) fmt.Println(strings.ToUpper(""хлеб"")) } ``` ### What did you expect to see? A difference in output. ### What did you see instead? Example ToTitle (unmodified) outputs: ``` HER ROYAL HIGHNESS LOUD NOISES ХЛЕБ ``` Example ToUpper (modified as described above) outputs: ``` HER ROYAL HIGHNESS LOUD NOISES ХЛЕБ ``` No difference. So for me it is unclear which function is now the correct one to use for an imaginary case.",1,strings docs examples unclear about difference between totitle and toupper please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version the current documentation on does this issue reproduce with the latest release yes using the examples inside the strings package documentation what operating system and processor architecture are you using go env none providable what did you do copied strings totitle example to strings toupper and changed totitle to toupper package main import fmt strings func main fmt println strings toupper her royal highness fmt println strings toupper loud noises fmt println strings toupper хлеб what did you expect to see a difference in output what did you see instead example totitle unmodified outputs her royal highness loud noises хлеб example toupper modified as described above outputs her royal highness loud noises хлеб no difference so for me it is unclear which function is now the correct one to use for an imaginary case ,1 55167,30612707400.0,IssuesEvent,2023-07-23 20:15:22,golang/go,https://api.github.com/repos/golang/go,closed,runtime: special case timer channels,Performance NeedsFix early-in-cycle,"
Consider special-casing timer channels created with time.Ticker and time.After.
Namely, such chans need to contain next fire time and period. Then receive from such
looks like:

func chanrecv(c *Hchan) {
  ...
  if c.isTimeChan {
    for {
      next := c.nextTime
      if next == -1 {
        // already fired one-time timer
        blockForever()
      }
      newTime := -1
      if c.period != 0 {
        newTime = next + c.period
      }
      if CAS(&c.nextTime, next, newTime) {
        wait := next - now
        if wait > 0 {
          sleepFor(wait)
        }
        return
      }
    }
  }
  ...
}

This has several advantages:
1. No need to stop timers. If nobody waits on a timers, it's just a normal heap object
that can be garbage collected.
2. Faster operation for both blocking and non-blocking case.
3. Faster selects involving time chans.
4. Can combine time.Ticker/After into a single allocation.
",True,"runtime: special case timer channels - 
Consider special-casing timer channels created with time.Ticker and time.After.
Namely, such chans need to contain next fire time and period. Then receive from such
looks like:

func chanrecv(c *Hchan) {
  ...
  if c.isTimeChan {
    for {
      next := c.nextTime
      if next == -1 {
        // already fired one-time timer
        blockForever()
      }
      newTime := -1
      if c.period != 0 {
        newTime = next + c.period
      }
      if CAS(&c.nextTime, next, newTime) {
        wait := next - now
        if wait > 0 {
          sleepFor(wait)
        }
        return
      }
    }
  }
  ...
}

This has several advantages:
1. No need to stop timers. If nobody waits on a timers, it's just a normal heap object
that can be garbage collected.
2. Faster operation for both blocking and non-blocking case.
3. Faster selects involving time chans.
4. Can combine time.Ticker/After into a single allocation.
",0,runtime special case timer channels consider special casing timer channels created with time ticker and time after namely such chans need to contain next fire time and period then receive from such looks like func chanrecv c hchan if c istimechan for next c nexttime if next already fired one time timer blockforever newtime if c period newtime next c period if cas amp c nexttime next newtime wait next now if wait gt sleepfor wait return this has several advantages no need to stop timers if nobody waits on a timers it s just a normal heap object that can be garbage collected faster operation for both blocking and non blocking case faster selects involving time chans can combine time ticker after into a single allocation ,0 149775,13302143613.0,IssuesEvent,2020-08-25 13:54:29,golang/go,https://api.github.com/repos/golang/go,opened,x/pkgsite: documentation how to add experiments locally,Documentation NeedsFix pkgsite,"We should add a `doc/experiment.md` file which describes how to add experiments when running locally, including: - Running `go run devtools/cmd/experiment/experiment.go create ` - Where to find existing experiments - How to add a new experiment to the codebase",1.0,"x/pkgsite: documentation how to add experiments locally - We should add a `doc/experiment.md` file which describes how to add experiments when running locally, including: - Running `go run devtools/cmd/experiment/experiment.go create ` - Where to find existing experiments - How to add a new experiment to the codebase",1,x pkgsite documentation how to add experiments locally we should add a doc experiment md file which describes how to add experiments when running locally including running go run devtools cmd experiment experiment go create where to find existing experiments how to add a new experiment to the codebase,1 44469,11452407857.0,IssuesEvent,2020-02-06 13:38:38,golang/go,https://api.github.com/repos/golang/go,closed,x/build: investigate why vet failures on tip weren't caught by builders,Builders,"`go vet std` is reporting problems and exiting with a non-zero code on latest master (see #37030): ``` src $ go version go version devel +a864cc7560 Wed Feb 5 14:32:50 2020 +0000 darwin/amd64 src $ go vet std # sync/atomic sync/atomic/value.go:59:44: possible misuse of unsafe.Pointer # runtime/internal/atomic_test runtime/internal/atomic/atomic_test.go:94:7: possible misuse of unsafe.Pointer # strings strings/builder.go:30:9: possible misuse of unsafe.Pointer # runtime runtime/alg.go:56:22: possible misuse of unsafe.Pointer runtime/atomic_pointer.go:63:9: possible misuse of unsafe.Pointer runtime/cgocall.go:200:13: possible misuse of unsafe.Pointer runtime/cgocall.go:282:16: possible misuse of unsafe.Pointer runtime/cgocall.go:287:16: possible misuse of unsafe.Pointer [...] src $ echo $? 2 ``` Need to investigate why the builders didn't catch this. We used to have a `misc-vet-vetall` builder but that has changed in #31916. /cc @rsc @cagedmantis @toothrot",1.0,"x/build: investigate why vet failures on tip weren't caught by builders - `go vet std` is reporting problems and exiting with a non-zero code on latest master (see #37030): ``` src $ go version go version devel +a864cc7560 Wed Feb 5 14:32:50 2020 +0000 darwin/amd64 src $ go vet std # sync/atomic sync/atomic/value.go:59:44: possible misuse of unsafe.Pointer # runtime/internal/atomic_test runtime/internal/atomic/atomic_test.go:94:7: possible misuse of unsafe.Pointer # strings strings/builder.go:30:9: possible misuse of unsafe.Pointer # runtime runtime/alg.go:56:22: possible misuse of unsafe.Pointer runtime/atomic_pointer.go:63:9: possible misuse of unsafe.Pointer runtime/cgocall.go:200:13: possible misuse of unsafe.Pointer runtime/cgocall.go:282:16: possible misuse of unsafe.Pointer runtime/cgocall.go:287:16: possible misuse of unsafe.Pointer [...] src $ echo $? 2 ``` Need to investigate why the builders didn't catch this. We used to have a `misc-vet-vetall` builder but that has changed in #31916. /cc @rsc @cagedmantis @toothrot",0,x build investigate why vet failures on tip weren t caught by builders go vet std is reporting problems and exiting with a non zero code on latest master see src go version go version devel wed feb darwin src go vet std sync atomic sync atomic value go possible misuse of unsafe pointer runtime internal atomic test runtime internal atomic atomic test go possible misuse of unsafe pointer strings strings builder go possible misuse of unsafe pointer runtime runtime alg go possible misuse of unsafe pointer runtime atomic pointer go possible misuse of unsafe pointer runtime cgocall go possible misuse of unsafe pointer runtime cgocall go possible misuse of unsafe pointer runtime cgocall go possible misuse of unsafe pointer src echo need to investigate why the builders didn t catch this we used to have a misc vet vetall builder but that has changed in cc rsc cagedmantis toothrot,0 56042,8047425643.0,IssuesEvent,2018-08-01 00:36:01,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go list and rooted paths,Documentation,"go help packages says: ``` An import path that is a rooted path or that begins with a . or .. element is interpreted as a file system path and denotes the package in that directory. ``` The way I interpret it is that ``` go list /home/manlio/go/github/perillo/goprint ``` should list the goprint package; however go list reports an error: ``` can't load package: package /home/manlio/go/src/github.com/perillo/goprint: import ""/home/manlio/go/src/github.com/perillo/goprint"": cannot import absolute path ``` ",1.0,"cmd/go: go list and rooted paths - go help packages says: ``` An import path that is a rooted path or that begins with a . or .. element is interpreted as a file system path and denotes the package in that directory. ``` The way I interpret it is that ``` go list /home/manlio/go/github/perillo/goprint ``` should list the goprint package; however go list reports an error: ``` can't load package: package /home/manlio/go/src/github.com/perillo/goprint: import ""/home/manlio/go/src/github.com/perillo/goprint"": cannot import absolute path ``` ",1,cmd go go list and rooted paths go help packages says an import path that is a rooted path or that begins with a or element is interpreted as a file system path and denotes the package in that directory the way i interpret it is that go list home manlio go github perillo goprint should list the goprint package however go list reports an error can t load package package home manlio go src github com perillo goprint import home manlio go src github com perillo goprint cannot import absolute path ,1 270956,20616352457.0,IssuesEvent,2022-03-07 13:36:53,golang/go,https://api.github.com/repos/golang/go,closed,doc: update FAQ for the arrival of parametric polymorphism,Documentation NeedsFix,"Many sections of the FAQ need tweaking, a few need replacement. Update before release. For example, here's a question there that needs to be rethought: ""Why does Go not have generic types?""",1.0,"doc: update FAQ for the arrival of parametric polymorphism - Many sections of the FAQ need tweaking, a few need replacement. Update before release. For example, here's a question there that needs to be rethought: ""Why does Go not have generic types?""",1,doc update faq for the arrival of parametric polymorphism many sections of the faq need tweaking a few need replacement update before release for example here s a question there that needs to be rethought why does go not have generic types ,1 28090,8072714561.0,IssuesEvent,2018-08-06 16:50:24,golang/go,https://api.github.com/repos/golang/go,closed,"x/build/maintner: GerritCL.Created is not accurate (it equals to ""CL Updated"" time instead)",Builders Documentation NeedsFix,"### What version of Go are you using (`go version`)? ``` $ go version go version go1.10.1 darwin/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What did you do? I queried the [`maintner.GerritCL.Created`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Created) value for [CL 92456](https://go-review.googlesource.com/c/go/+/92456).
Sample Program
```Go package main import ( ""context"" ""fmt"" ""log"" ""time"" ""golang.org/x/build/maintner/godata"" ) func main() { c, err := godata.Get(context.Background()) if err != nil { log.Fatalln(err) } cl := c.Gerrit().Project(""go.googlesource.com"", ""go"").CL(92456) fmt.Println(""cl.Created:"", cl.Created.UTC().Format(time.UnixDate)) } ```
### What did you expect to see? [`maintner.GerritCL.Created`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Created) is not documented, but given the field is named `Created time.Time` and it's inside the `GerritCL` struct, one would expect it to be the time the CL was created. CL 92456 was created about [2 months ago](https://go-review.googlesource.com/c/go/+/92456#message-ca1f3042ded5036bef9e9c5a952c64cc2f85f0de). So, I expected to see a date like Feb 6, 2018, 6:57 PM UTC. ### What did you see instead? A date like Apr 6, 2018, 7:42 PM UTC. Which is around 9~ hours ago. It's the date the CL was last updated (merged). --- I've looked at the code and it looks like the `GerritCL.Created` value is assigned to the `CommitTime` of the latest meta commit. That would explain the results I saw.",1.0,"x/build/maintner: GerritCL.Created is not accurate (it equals to ""CL Updated"" time instead) - ### What version of Go are you using (`go version`)? ``` $ go version go version go1.10.1 darwin/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What did you do? I queried the [`maintner.GerritCL.Created`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Created) value for [CL 92456](https://go-review.googlesource.com/c/go/+/92456).
Sample Program
```Go package main import ( ""context"" ""fmt"" ""log"" ""time"" ""golang.org/x/build/maintner/godata"" ) func main() { c, err := godata.Get(context.Background()) if err != nil { log.Fatalln(err) } cl := c.Gerrit().Project(""go.googlesource.com"", ""go"").CL(92456) fmt.Println(""cl.Created:"", cl.Created.UTC().Format(time.UnixDate)) } ```
### What did you expect to see? [`maintner.GerritCL.Created`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Created) is not documented, but given the field is named `Created time.Time` and it's inside the `GerritCL` struct, one would expect it to be the time the CL was created. CL 92456 was created about [2 months ago](https://go-review.googlesource.com/c/go/+/92456#message-ca1f3042ded5036bef9e9c5a952c64cc2f85f0de). So, I expected to see a date like Feb 6, 2018, 6:57 PM UTC. ### What did you see instead? A date like Apr 6, 2018, 7:42 PM UTC. Which is around 9~ hours ago. It's the date the CL was last updated (merged). --- I've looked at the code and it looks like the `GerritCL.Created` value is assigned to the `CommitTime` of the latest meta commit. That would explain the results I saw.",0,x build maintner gerritcl created is not accurate it equals to cl updated time instead what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what did you do i queried the value for sample program go package main import context fmt log time golang org x build maintner godata func main c err godata get context background if err nil log fatalln err cl c gerrit project go googlesource com go cl fmt println cl created cl created utc format time unixdate what did you expect to see is not documented but given the field is named created time time and it s inside the gerritcl struct one would expect it to be the time the cl was created cl was created about so i expected to see a date like feb pm utc what did you see instead a date like apr pm utc which is around hours ago it s the date the cl was last updated merged i ve looked at the code and it looks like the gerritcl created value is assigned to the committime of the latest meta commit that would explain the results i saw ,0 134250,10887809717.0,IssuesEvent,2019-11-18 15:11:35,golang/go,https://api.github.com/repos/golang/go,closed,cmd/fix: incorrect loop variable aliasing in TestRewrite,NeedsFix Testing,"### What version of Go are you using (`go version`)? 
$ go version
go version devel +c20b71eb37 Sat Nov 16 02:06:39 2019 +0000 linux/amd6
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/u/.cache/go-build""
GOENV=""/home/u/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/u/goget:/home/u/Desktop/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/u/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/u/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/u/go/src/cmd/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-build745246669=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. clone the go repository: `git clone https://go.googlesource.com/go.git` 2. build go as usual: `cd src; ./all.bash` 3. edit `cmd/fix/context_test.go` to ensure that the test case should FAIL. ```diff diff --git a/src/cmd/fix/context_test.go b/src/cmd/fix/context_test.go index 935d0d7235..f666be2fb1 100644 --- a/src/cmd/fix/context_test.go +++ b/src/cmd/fix/context_test.go @@ -19,7 +19,7 @@ var _ = ""golang.org/x/net/context"" `, Out: `package main -import ""context"" +import ""context""x var _ = ""golang.org/x/net/context"" `, ``` 4. run `go test` from the `src/cmd/fix` directory. ``` $ go test PASS ok cmd/fix 0.032s ``` 5. notice that the test case passes, even though it *should* fail, given that we edited the expected output of the context rewrite rule. 6. remove call to `t.Parallel` in `cmd/fix/main_test.go` ```diff diff --git a/src/cmd/fix/main_test.go b/src/cmd/fix/main_test.go index ee74f24c6e..5214d67af1 100644 --- a/src/cmd/fix/main_test.go +++ b/src/cmd/fix/main_test.go @@ -77,7 +77,7 @@ func parseFixPrint(t *testing.T, fn func(*ast.File) bool, desc, in string, mustB func TestRewrite(t *testing.T) { for _, tt := range testCases { t.Run(tt.Name, func(t *testing.T) { - t.Parallel() + //t.Parallel() // Apply fix: should get tt.Out. out, fixed, ok := parseFixPrint(t, tt.Fn, tt.Name, tt.In, true) if !ok { ``` 7. re-run test case using `go test` from the `src/cmd/fix` directory. ``` --- FAIL: TestRewrite (2.86s) --- FAIL: TestRewrite/context.0 (0.00s) main_test.go:94: incorrect output. main_test.go:96: --- have package main import ""context"" var _ = ""golang.org/x/net/context"" --- want package main import ""context""x var _ = ""golang.org/x/net/context"" main_test.go:133: --- /tmp/go-fix-test929058818 2019-11-15 21:39:47.643666701 -0600 +++ /tmp/go-fix-test221839737 2019-11-15 21:39:47.643666701 -0600 @@ -1,5 +1,5 @@ package main -import ""context"" +import ""context""x var _ = ""golang.org/x/net/context"" FAIL exit status 1 FAIL cmd/fix 2.866s ``` 8. notice that the test case now fails, as it should do, given that we edited the expected output of the context rewrite rule. ### What did you expect to see? A failed test case (after having modified the expected output of the `context_test.go` test case). ### What did you see instead? Test cases passing without error.",1.0,"cmd/fix: incorrect loop variable aliasing in TestRewrite - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +c20b71eb37 Sat Nov 16 02:06:39 2019 +0000 linux/amd6
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/u/.cache/go-build""
GOENV=""/home/u/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/u/goget:/home/u/Desktop/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/u/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/u/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/u/go/src/cmd/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-build745246669=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. clone the go repository: `git clone https://go.googlesource.com/go.git` 2. build go as usual: `cd src; ./all.bash` 3. edit `cmd/fix/context_test.go` to ensure that the test case should FAIL. ```diff diff --git a/src/cmd/fix/context_test.go b/src/cmd/fix/context_test.go index 935d0d7235..f666be2fb1 100644 --- a/src/cmd/fix/context_test.go +++ b/src/cmd/fix/context_test.go @@ -19,7 +19,7 @@ var _ = ""golang.org/x/net/context"" `, Out: `package main -import ""context"" +import ""context""x var _ = ""golang.org/x/net/context"" `, ``` 4. run `go test` from the `src/cmd/fix` directory. ``` $ go test PASS ok cmd/fix 0.032s ``` 5. notice that the test case passes, even though it *should* fail, given that we edited the expected output of the context rewrite rule. 6. remove call to `t.Parallel` in `cmd/fix/main_test.go` ```diff diff --git a/src/cmd/fix/main_test.go b/src/cmd/fix/main_test.go index ee74f24c6e..5214d67af1 100644 --- a/src/cmd/fix/main_test.go +++ b/src/cmd/fix/main_test.go @@ -77,7 +77,7 @@ func parseFixPrint(t *testing.T, fn func(*ast.File) bool, desc, in string, mustB func TestRewrite(t *testing.T) { for _, tt := range testCases { t.Run(tt.Name, func(t *testing.T) { - t.Parallel() + //t.Parallel() // Apply fix: should get tt.Out. out, fixed, ok := parseFixPrint(t, tt.Fn, tt.Name, tt.In, true) if !ok { ``` 7. re-run test case using `go test` from the `src/cmd/fix` directory. ``` --- FAIL: TestRewrite (2.86s) --- FAIL: TestRewrite/context.0 (0.00s) main_test.go:94: incorrect output. main_test.go:96: --- have package main import ""context"" var _ = ""golang.org/x/net/context"" --- want package main import ""context""x var _ = ""golang.org/x/net/context"" main_test.go:133: --- /tmp/go-fix-test929058818 2019-11-15 21:39:47.643666701 -0600 +++ /tmp/go-fix-test221839737 2019-11-15 21:39:47.643666701 -0600 @@ -1,5 +1,5 @@ package main -import ""context"" +import ""context""x var _ = ""golang.org/x/net/context"" FAIL exit status 1 FAIL cmd/fix 2.866s ``` 8. notice that the test case now fails, as it should do, given that we edited the expected output of the context rewrite rule. ### What did you expect to see? A failed test case (after having modified the expected output of the `context_test.go` test case). ### What did you see instead? Test cases passing without error.",0,cmd fix incorrect loop variable aliasing in testrewrite what version of go are you using go version go version go version devel sat nov linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home u cache go build goenv home u config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux gopath home u goget home u desktop go goprivate goproxy goroot home u go gosumdb sum golang org gotmpdir gotooldir home u go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home u go src cmd go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 clone the go repository git clone build go as usual cd src all bash edit cmd fix context test go to ensure that the test case should fail diff diff git a src cmd fix context test go b src cmd fix context test go index a src cmd fix context test go b src cmd fix context test go var golang org x net context out package main import context import context x var golang org x net context run go test from the src cmd fix directory go test pass ok cmd fix notice that the test case passes even though it should fail given that we edited the expected output of the context rewrite rule remove call to t parallel in cmd fix main test go diff diff git a src cmd fix main test go b src cmd fix main test go index a src cmd fix main test go b src cmd fix main test go func parsefixprint t testing t fn func ast file bool desc in string mustb func testrewrite t testing t for tt range testcases t run tt name func t testing t t parallel t parallel apply fix should get tt out out fixed ok parsefixprint t tt fn tt name tt in true if ok re run test case using go test from the src cmd fix directory fail testrewrite fail testrewrite context main test go incorrect output main test go have package main import context var golang org x net context want package main import context x var golang org x net context main test go tmp go fix tmp go fix package main import context import context x var golang org x net context fail exit status fail cmd fix notice that the test case now fails as it should do given that we edited the expected output of the context rewrite rule what did you expect to see a failed test case after having modified the expected output of the context test go test case what did you see instead test cases passing without error ,0 14556,8633425546.0,IssuesEvent,2018-11-22 13:50:19,golang/go,https://api.github.com/repos/golang/go,opened,encoding/json: speed up the decoding scanner,Performance,"#5683 covered the overall speed issues of encoding and decoding JSON. It's now closed, since the package has gotten noticeably faster in the last few Go releases. For example, after a series of patches I sent during 1.12: ``` name old time/op new time/op delta CodeEncoder-4 7.43ms ± 0% 5.35ms ± 1% -28.01% (p=0.002 n=6+6) CodeDecoder-4 30.8ms ± 1% 27.3ms ± 0% -11.42% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 261MB/s ± 0% 363MB/s ± 1% +38.91% (p=0.002 n=6+6) CodeDecoder-4 62.9MB/s ± 1% 70.9MB/s ± 1% +12.71% (p=0.002 n=6+6) ``` Notice, however, how decoding is about five times slower than encoding. While it makes sense that decoding is more work, a 5x difference seems to point that there are some bottlenecks. Here are the encoding top 10 functions by cpu, as reported by `go test -run=- -bench=CodeEncoder -benchtime=5s -cpuprofile=cpu.out`: ``` flat flat% sum% cum cum% 3.93s 10.84% 10.84% 36.07s 99.50% encoding/json.structEncoder.encode 3.45s 9.52% 20.36% 3.92s 10.81% strconv.formatBits 3.39s 9.35% 29.71% 4.80s 13.24% strconv.(*extFloat).ShortestDecimal 2.50s 6.90% 36.61% 2.50s 6.90% runtime.memmove 2.41s 6.65% 43.26% 3.18s 8.77% encoding/json.(*encodeState).string 2.11s 5.82% 49.08% 2.11s 5.82% strconv.fmtF 1.78s 4.91% 53.99% 3.40s 9.38% bytes.(*Buffer).WriteString 1.36s 3.75% 57.74% 2s 5.52% bytes.(*Buffer).WriteByte 1.34s 3.70% 61.43% 1.34s 3.70% bytes.(*Buffer).tryGrowByReslice (inline) 1.32s 3.64% 65.08% 2.31s 6.37% bytes.(*Buffer).Write ``` It's been optimized to a point where `bytes.Buffer`, `runtime.memmove` and `strconv` all appear in the top 10, so it's pretty well optimized. I can't see any more low-hanging fruit in that top 10. And here are the as reported by `go test -run=- -bench=CodeDecoder -benchtime=5s -cpuprofile=cpu.out`: ``` flat flat% sum% cum cum% 3190ms 10.74% 10.74% 3240ms 10.91% encoding/json.stateInString 3150ms 10.60% 21.34% 8260ms 27.80% encoding/json.(*Decoder).readValue 2990ms 10.06% 31.40% 7660ms 25.78% encoding/json.(*decodeState).scanWhile 1990ms 6.70% 38.10% 21120ms 71.09% encoding/json.(*decodeState).object 1730ms 5.82% 43.92% 1860ms 6.26% encoding/json.stateEndValue 1550ms 5.22% 49.14% 2110ms 7.10% encoding/json.state1 1350ms 4.54% 53.69% 1350ms 4.54% encoding/json.unquoteBytes 1020ms 3.43% 57.12% 1080ms 3.64% encoding/json.stateBeginValue 920ms 3.10% 60.22% 3120ms 10.50% encoding/json.indirect 720ms 2.42% 62.64% 740ms 2.49% encoding/json.stateBeginString ``` The big difference here is that all 10 functions are in the json package itself. In particular, the scanner's `state*` functions take up half of the list, including number one. And numbers two and three, `readValue` and `scanWhile`, are also part of scanning tokens. There's another issue about speeding up the decoder, #16212. It's about doing reflect work ahread of time, like the encoder does. However, out of that top 10, only `object` and `indirect` involve any reflect work, so I doubt that a refactor for #16212 would bring substantial gains while the scanner takes vastly more time than reflection. So I propose that we refactor or even redesign the scanner to make it faster. The main bottleneck at the moment is the `step` function, which must be called for every decoded byte. I can imagine that it's slow for a few main reasons: * `step` is a function value, which can be nil - one nil check per byte * We can't quickly skip chunks of uninteresting bytes, such as whitespace or long quoted strings with safe characters * The calls cannot be inlined, even though many `state*` functions are very small - one call per byte The godoc for the `step` field reads: ``` // The step is a func to be called to execute the next transition. // Also tried using an integer constant and a single func // with a switch, but using the func directly was 10% faster // on a 64-bit Mac Mini, and it's nicer to read. ``` I tried using a function switch, and even a function jump table, but neither gave noticeable speed-ups. In fact, they all made `CodeDecoder` 1-5% slower. I presume the manual jump table via a `[...]func(*scanner, byte) int` array is slow because we still can't get rid of the nil checks. I'd hope that #5496 would help here. I have a few ideas in mind to try to make the work per byte a bit faster, but I'm limited by the ""one unknown step call per byte"" design, as I tried to explain above. I understand that the current design makes the JSON scanner simpler to reason about, but I wonder if there's anything we can do to make it faster while keeping it reasonably simple. This issue is to track small speed-ups in the scanner, but also to discuss larger refactors to it. I'm milestoning for 1.13, since at least the small speed-ups can be merged for that release. /cc @rsc @dsnet @bradfitz @josharian @kevinburke ",True,"encoding/json: speed up the decoding scanner - #5683 covered the overall speed issues of encoding and decoding JSON. It's now closed, since the package has gotten noticeably faster in the last few Go releases. For example, after a series of patches I sent during 1.12: ``` name old time/op new time/op delta CodeEncoder-4 7.43ms ± 0% 5.35ms ± 1% -28.01% (p=0.002 n=6+6) CodeDecoder-4 30.8ms ± 1% 27.3ms ± 0% -11.42% (p=0.004 n=6+5) name old speed new speed delta CodeEncoder-4 261MB/s ± 0% 363MB/s ± 1% +38.91% (p=0.002 n=6+6) CodeDecoder-4 62.9MB/s ± 1% 70.9MB/s ± 1% +12.71% (p=0.002 n=6+6) ``` Notice, however, how decoding is about five times slower than encoding. While it makes sense that decoding is more work, a 5x difference seems to point that there are some bottlenecks. Here are the encoding top 10 functions by cpu, as reported by `go test -run=- -bench=CodeEncoder -benchtime=5s -cpuprofile=cpu.out`: ``` flat flat% sum% cum cum% 3.93s 10.84% 10.84% 36.07s 99.50% encoding/json.structEncoder.encode 3.45s 9.52% 20.36% 3.92s 10.81% strconv.formatBits 3.39s 9.35% 29.71% 4.80s 13.24% strconv.(*extFloat).ShortestDecimal 2.50s 6.90% 36.61% 2.50s 6.90% runtime.memmove 2.41s 6.65% 43.26% 3.18s 8.77% encoding/json.(*encodeState).string 2.11s 5.82% 49.08% 2.11s 5.82% strconv.fmtF 1.78s 4.91% 53.99% 3.40s 9.38% bytes.(*Buffer).WriteString 1.36s 3.75% 57.74% 2s 5.52% bytes.(*Buffer).WriteByte 1.34s 3.70% 61.43% 1.34s 3.70% bytes.(*Buffer).tryGrowByReslice (inline) 1.32s 3.64% 65.08% 2.31s 6.37% bytes.(*Buffer).Write ``` It's been optimized to a point where `bytes.Buffer`, `runtime.memmove` and `strconv` all appear in the top 10, so it's pretty well optimized. I can't see any more low-hanging fruit in that top 10. And here are the as reported by `go test -run=- -bench=CodeDecoder -benchtime=5s -cpuprofile=cpu.out`: ``` flat flat% sum% cum cum% 3190ms 10.74% 10.74% 3240ms 10.91% encoding/json.stateInString 3150ms 10.60% 21.34% 8260ms 27.80% encoding/json.(*Decoder).readValue 2990ms 10.06% 31.40% 7660ms 25.78% encoding/json.(*decodeState).scanWhile 1990ms 6.70% 38.10% 21120ms 71.09% encoding/json.(*decodeState).object 1730ms 5.82% 43.92% 1860ms 6.26% encoding/json.stateEndValue 1550ms 5.22% 49.14% 2110ms 7.10% encoding/json.state1 1350ms 4.54% 53.69% 1350ms 4.54% encoding/json.unquoteBytes 1020ms 3.43% 57.12% 1080ms 3.64% encoding/json.stateBeginValue 920ms 3.10% 60.22% 3120ms 10.50% encoding/json.indirect 720ms 2.42% 62.64% 740ms 2.49% encoding/json.stateBeginString ``` The big difference here is that all 10 functions are in the json package itself. In particular, the scanner's `state*` functions take up half of the list, including number one. And numbers two and three, `readValue` and `scanWhile`, are also part of scanning tokens. There's another issue about speeding up the decoder, #16212. It's about doing reflect work ahread of time, like the encoder does. However, out of that top 10, only `object` and `indirect` involve any reflect work, so I doubt that a refactor for #16212 would bring substantial gains while the scanner takes vastly more time than reflection. So I propose that we refactor or even redesign the scanner to make it faster. The main bottleneck at the moment is the `step` function, which must be called for every decoded byte. I can imagine that it's slow for a few main reasons: * `step` is a function value, which can be nil - one nil check per byte * We can't quickly skip chunks of uninteresting bytes, such as whitespace or long quoted strings with safe characters * The calls cannot be inlined, even though many `state*` functions are very small - one call per byte The godoc for the `step` field reads: ``` // The step is a func to be called to execute the next transition. // Also tried using an integer constant and a single func // with a switch, but using the func directly was 10% faster // on a 64-bit Mac Mini, and it's nicer to read. ``` I tried using a function switch, and even a function jump table, but neither gave noticeable speed-ups. In fact, they all made `CodeDecoder` 1-5% slower. I presume the manual jump table via a `[...]func(*scanner, byte) int` array is slow because we still can't get rid of the nil checks. I'd hope that #5496 would help here. I have a few ideas in mind to try to make the work per byte a bit faster, but I'm limited by the ""one unknown step call per byte"" design, as I tried to explain above. I understand that the current design makes the JSON scanner simpler to reason about, but I wonder if there's anything we can do to make it faster while keeping it reasonably simple. This issue is to track small speed-ups in the scanner, but also to discuss larger refactors to it. I'm milestoning for 1.13, since at least the small speed-ups can be merged for that release. /cc @rsc @dsnet @bradfitz @josharian @kevinburke ",0,encoding json speed up the decoding scanner covered the overall speed issues of encoding and decoding json it s now closed since the package has gotten noticeably faster in the last few go releases for example after a series of patches i sent during name old time op new time op delta codeencoder ± ± p n codedecoder ± ± p n name old speed new speed delta codeencoder s ± s ± p n codedecoder s ± s ± p n notice however how decoding is about five times slower than encoding while it makes sense that decoding is more work a difference seems to point that there are some bottlenecks here are the encoding top functions by cpu as reported by go test run bench codeencoder benchtime cpuprofile cpu out flat flat sum cum cum encoding json structencoder encode strconv formatbits strconv extfloat shortestdecimal runtime memmove encoding json encodestate string strconv fmtf bytes buffer writestring bytes buffer writebyte bytes buffer trygrowbyreslice inline bytes buffer write it s been optimized to a point where bytes buffer runtime memmove and strconv all appear in the top so it s pretty well optimized i can t see any more low hanging fruit in that top and here are the as reported by go test run bench codedecoder benchtime cpuprofile cpu out flat flat sum cum cum encoding json stateinstring encoding json decoder readvalue encoding json decodestate scanwhile encoding json decodestate object encoding json stateendvalue encoding json encoding json unquotebytes encoding json statebeginvalue encoding json indirect encoding json statebeginstring the big difference here is that all functions are in the json package itself in particular the scanner s state functions take up half of the list including number one and numbers two and three readvalue and scanwhile are also part of scanning tokens there s another issue about speeding up the decoder it s about doing reflect work ahread of time like the encoder does however out of that top only object and indirect involve any reflect work so i doubt that a refactor for would bring substantial gains while the scanner takes vastly more time than reflection so i propose that we refactor or even redesign the scanner to make it faster the main bottleneck at the moment is the step function which must be called for every decoded byte i can imagine that it s slow for a few main reasons step is a function value which can be nil one nil check per byte we can t quickly skip chunks of uninteresting bytes such as whitespace or long quoted strings with safe characters the calls cannot be inlined even though many state functions are very small one call per byte the godoc for the step field reads the step is a func to be called to execute the next transition also tried using an integer constant and a single func with a switch but using the func directly was faster on a bit mac mini and it s nicer to read i tried using a function switch and even a function jump table but neither gave noticeable speed ups in fact they all made codedecoder slower i presume the manual jump table via a func scanner byte int array is slow because we still can t get rid of the nil checks i d hope that would help here i have a few ideas in mind to try to make the work per byte a bit faster but i m limited by the one unknown step call per byte design as i tried to explain above i understand that the current design makes the json scanner simpler to reason about but i wonder if there s anything we can do to make it faster while keeping it reasonably simple this issue is to track small speed ups in the scanner but also to discuss larger refactors to it i m milestoning for since at least the small speed ups can be merged for that release cc rsc dsnet bradfitz josharian kevinburke ,0 81468,23470702566.0,IssuesEvent,2022-08-16 21:29:21,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/relui: send CLs to release coordinators,Builders NeedsFix,"relui currently doesn't set any reviewers on the CLs it mails, which means you have to go digging through the logs to find them. It should send them to the release coordinators; we already sort of know who they are for the release announcement. We can use the `gophers` package for this if we want, or read user info from Gerrit.",1.0,"x/build/cmd/relui: send CLs to release coordinators - relui currently doesn't set any reviewers on the CLs it mails, which means you have to go digging through the logs to find them. It should send them to the release coordinators; we already sort of know who they are for the release announcement. We can use the `gophers` package for this if we want, or read user info from Gerrit.",0,x build cmd relui send cls to release coordinators relui currently doesn t set any reviewers on the cls it mails which means you have to go digging through the logs to find them it should send them to the release coordinators we already sort of know who they are for the release announcement we can use the gophers package for this if we want or read user info from gerrit ,0 9148,3257535577.0,IssuesEvent,2015-10-20 18:17:11,golang/go,https://api.github.com/repos/golang/go,closed,spec: Do exact floating-point constants differentiate between -0.0 and 0.0?,Documentation,"The spec does not seem to be clear. The test test/fixedbugs/bug434.go says that -0.0 and 0.0 are the same. Clarify.",1.0,"spec: Do exact floating-point constants differentiate between -0.0 and 0.0? - The spec does not seem to be clear. The test test/fixedbugs/bug434.go says that -0.0 and 0.0 are the same. Clarify.",1,spec do exact floating point constants differentiate between and the spec does not seem to be clear the test test fixedbugs go says that and are the same clarify ,1 358196,25182126125.0,IssuesEvent,2022-11-11 14:35:44,golang/go,https://api.github.com/repos/golang/go,closed,net/netip: documentation: p.IP() should say p.Addr(),Documentation NeedsFix,"### What version of Go are you using (`go version`)? Any 1.18+ ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for net/netip package online. https://pkg.go.dev/net/netip#AddrPort.IsValid > ""IsValid reports whether p.IP() is valid."" https://pkg.go.dev/net/netip#Prefix.IsValid > ""IsValid reports whether p.Bits() has a valid range for p.IP()"" However, neither AddrPort nor Prefix has an `IP()` method. ### What did you expect to see? I think p.IP() should say p.Addr() in both cases ### What did you see instead? See above",1.0,"net/netip: documentation: p.IP() should say p.Addr() - ### What version of Go are you using (`go version`)? Any 1.18+ ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for net/netip package online. https://pkg.go.dev/net/netip#AddrPort.IsValid > ""IsValid reports whether p.IP() is valid."" https://pkg.go.dev/net/netip#Prefix.IsValid > ""IsValid reports whether p.Bits() has a valid range for p.IP()"" However, neither AddrPort nor Prefix has an `IP()` method. ### What did you expect to see? I think p.IP() should say p.Addr() in both cases ### What did you see instead? See above",1,net netip documentation p ip should say p addr what version of go are you using go version any does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env n a what did you do read the documentation for net netip package online isvalid reports whether p ip is valid isvalid reports whether p bits has a valid range for p ip however neither addrport nor prefix has an ip method what did you expect to see i think p ip should say p addr in both cases what did you see instead see above,1 339134,24611489018.0,IssuesEvent,2022-10-14 22:08:24,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Missing Retract field and ModPath struct in GoMod module reference docs,Documentation help wanted NeedsFix modules," ### What version of Go are you using (`go version`)? n/a ### Does this issue reproduce with the latest release? n/a ### What operating system and processor architecture are you using (`go env`)? n/a ### What did you do? Reviewed https://go.dev/ref/mod#go-mod-edit (source: https://github.com/golang/website/blob/master/_content/ref/mod.md#go-mod-edit-go-mod-edit) ### What did you expect to see? The description of the `-json` output should include the `Retract []Retract` field in the GoMod struct and include the `ModPath` struct (and the Module field should be of type ModPath). This field and struct are present in the `go help mod edit` documentation. ### What did you see instead? Missing Retract field and ModPath struct. ",1.0,"x/website: Missing Retract field and ModPath struct in GoMod module reference docs - ### What version of Go are you using (`go version`)? n/a ### Does this issue reproduce with the latest release? n/a ### What operating system and processor architecture are you using (`go env`)? n/a ### What did you do? Reviewed https://go.dev/ref/mod#go-mod-edit (source: https://github.com/golang/website/blob/master/_content/ref/mod.md#go-mod-edit-go-mod-edit) ### What did you expect to see? The description of the `-json` output should include the `Retract []Retract` field in the GoMod struct and include the `ModPath` struct (and the Module field should be of type ModPath). This field and struct are present in the `go help mod edit` documentation. ### What did you see instead? Missing Retract field and ModPath struct. ",1,x website missing retract field and modpath struct in gomod module reference docs please answer these questions before submitting your issue thanks what version of go are you using go version n a does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env n a what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best reviewed source what did you expect to see the description of the json output should include the retract retract field in the gomod struct and include the modpath struct and the module field should be of type modpath this field and struct are present in the go help mod edit documentation what did you see instead missing retract field and modpath struct ,1 78563,10073179353.0,IssuesEvent,2019-07-24 09:02:45,golang/go,https://api.github.com/repos/golang/go,closed,net/http: documentation unclear about when request body is closed,Documentation,"It is currently possible for a request body to be read, even _after_ `http.Client.Do` returns. This can be a source of potential race conditions. It is currently unclear in the documentation that this can happen. To the contrary, the documentation is hinting at the fact that the request body _will_ be closed after the function returns, at least to my understanding. To illustrate, the attached playground example reproduces the problem, when compiled with the `-race` flag: https://play.golang.org/p/Z0t0QEawcev Furthermore, I'm unsure about the correctness of reading from an `io.ReadCloser` (the request body) after a call to `Close`. The purpose of this issue is to clarify whether: * This is a bug? * Documentation can be improved? Useful links: * [http.RoundTripper documentation](https://github.com/golang/go/blob/go1.12/src/net/http/client.go#L133-L137) * [http.Client.Do documentation](https://github.com/golang/go/blob/go1.12/src/net/http/client.go#L486-L487)",1.0,"net/http: documentation unclear about when request body is closed - It is currently possible for a request body to be read, even _after_ `http.Client.Do` returns. This can be a source of potential race conditions. It is currently unclear in the documentation that this can happen. To the contrary, the documentation is hinting at the fact that the request body _will_ be closed after the function returns, at least to my understanding. To illustrate, the attached playground example reproduces the problem, when compiled with the `-race` flag: https://play.golang.org/p/Z0t0QEawcev Furthermore, I'm unsure about the correctness of reading from an `io.ReadCloser` (the request body) after a call to `Close`. The purpose of this issue is to clarify whether: * This is a bug? * Documentation can be improved? Useful links: * [http.RoundTripper documentation](https://github.com/golang/go/blob/go1.12/src/net/http/client.go#L133-L137) * [http.Client.Do documentation](https://github.com/golang/go/blob/go1.12/src/net/http/client.go#L486-L487)",1,net http documentation unclear about when request body is closed it is currently possible for a request body to be read even after http client do returns this can be a source of potential race conditions it is currently unclear in the documentation that this can happen to the contrary the documentation is hinting at the fact that the request body will be closed after the function returns at least to my understanding to illustrate the attached playground example reproduces the problem when compiled with the race flag furthermore i m unsure about the correctness of reading from an io readcloser the request body after a call to close the purpose of this issue is to clarify whether this is a bug documentation can be improved useful links ,1 46150,7238835961.0,IssuesEvent,2018-02-13 15:45:47,golang/go,https://api.github.com/repos/golang/go,closed,spec: type alias identity unclear,Documentation WaitingForInfo,"In the ""Type Alias"" [proposal](https://github.com/golang/proposal/blob/master/design/18130-type-alias.md#proposal) by Russ Cox & Robert Griesemer it is specified that: > After such a declaration, T1 and T2 are identical types. Given the above, I think that this should be made more obvious within the spec in either the [_Type Identity_](https://golang.org/ref/spec#Type_identity) section or the [_Type Declarations_](https://golang.org/ref/spec#Type_declarations), _""Alias declarations""_ sub-section.",1.0,"spec: type alias identity unclear - In the ""Type Alias"" [proposal](https://github.com/golang/proposal/blob/master/design/18130-type-alias.md#proposal) by Russ Cox & Robert Griesemer it is specified that: > After such a declaration, T1 and T2 are identical types. Given the above, I think that this should be made more obvious within the spec in either the [_Type Identity_](https://golang.org/ref/spec#Type_identity) section or the [_Type Declarations_](https://golang.org/ref/spec#Type_declarations), _""Alias declarations""_ sub-section.",1,spec type alias identity unclear in the type alias by russ cox robert griesemer it is specified that after such a declaration and are identical types given the above i think that this should be made more obvious within the spec in either the section or the alias declarations sub section ,1 285190,21486388981.0,IssuesEvent,2022-04-27 00:12:12,golang/go,https://api.github.com/repos/golang/go,closed,time: second precision timezone format not documented,Documentation help wanted NeedsFix,"`go doc time` says: ``` Numeric time zone offsets format as follows: ""-0700"" ±hhmm ""-07:00"" ±hh:mm ""-07"" ±hh ``` However, timezones with second precision (""-07:00:00"" and ""-070000"") are also supported: https://github.com/golang/go/blob/master/src/time/format.go#L151 Could these be added to the documentation? Took me a while to figure out why my pre-1900 date with LMT timezone parsed correctly. ",1.0,"time: second precision timezone format not documented - `go doc time` says: ``` Numeric time zone offsets format as follows: ""-0700"" ±hhmm ""-07:00"" ±hh:mm ""-07"" ±hh ``` However, timezones with second precision (""-07:00:00"" and ""-070000"") are also supported: https://github.com/golang/go/blob/master/src/time/format.go#L151 Could these be added to the documentation? Took me a while to figure out why my pre-1900 date with LMT timezone parsed correctly. ",1,time second precision timezone format not documented go doc time says numeric time zone offsets format as follows ±hhmm ±hh mm ±hh however timezones with second precision and are also supported could these be added to the documentation took me a while to figure out why my pre date with lmt timezone parsed correctly ,1 150943,13386314344.0,IssuesEvent,2020-09-02 14:34:39,golang/go,https://api.github.com/repos/golang/go,closed,x/website: error and suggestion for tutorials pages,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
1.15
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/josh/.cache/go-build""
GOENV=""/home/josh/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/josh/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/josh/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/josh/projects/go/greetings/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-build087138363=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I noticed two errors on the tutorial site: 1. https://golang.org/doc/tutorial/call-module-code - Step 3, the line should read: fmt.Println(message) and not (greeting) 2. https://golang.org/doc/tutorial/handle-errors - Step 1, the ""nil"" being returned with ""message"" should probably be blue and bold to match the other new lines of code to be added. ### What did you expect to see? 1. message being printed instead of greeting 2. bolding of new code ### What did you see instead? as reported above",1.0,"x/website: error and suggestion for tutorials pages - ### What version of Go are you using (`go version`)? 
$ go version
1.15
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/josh/.cache/go-build""
GOENV=""/home/josh/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/josh/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/josh/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/josh/projects/go/greetings/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-build087138363=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I noticed two errors on the tutorial site: 1. https://golang.org/doc/tutorial/call-module-code - Step 3, the line should read: fmt.Println(message) and not (greeting) 2. https://golang.org/doc/tutorial/handle-errors - Step 1, the ""nil"" being returned with ""message"" should probably be blue and bold to match the other new lines of code to be added. ### What did you expect to see? 1. message being printed instead of greeting 2. bolding of new code ### What did you see instead? as reported above",1,x website error and suggestion for tutorials pages please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home josh cache go build goenv home josh config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home josh go pkg mod gonoproxy gonosumdb goos linux gopath home josh go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home josh projects go greetings go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 i noticed two errors on the tutorial site step the line should read fmt println message and not greeting step the nil being returned with message should probably be blue and bold to match the other new lines of code to be added what did you expect to see message being printed instead of greeting bolding of new code what did you see instead as reported above,1 50832,7634096312.0,IssuesEvent,2018-05-06 13:55:14,golang/go,https://api.github.com/repos/golang/go,closed,"net/http, x/net/http2: update RFC numbers used as normative references",Documentation help wanted,"The documentation in x/net/http and x/net/http2 packages still contains the obsolete RFC 2616 as a normative reference. I think it's better to replace the reference to RFC 2616 with a series of RFCs 7230 through 7235 for avoiding unnecessary confusion. When we see some inconsistency, for example, RFC 2616 vs. RFC 723x, in the current implementation, that should be addressed as another issue. So this should be a documentation issue.",1.0,"net/http, x/net/http2: update RFC numbers used as normative references - The documentation in x/net/http and x/net/http2 packages still contains the obsolete RFC 2616 as a normative reference. I think it's better to replace the reference to RFC 2616 with a series of RFCs 7230 through 7235 for avoiding unnecessary confusion. When we see some inconsistency, for example, RFC 2616 vs. RFC 723x, in the current implementation, that should be addressed as another issue. So this should be a documentation issue.",1,net http x net update rfc numbers used as normative references the documentation in x net http and x net packages still contains the obsolete rfc as a normative reference i think it s better to replace the reference to rfc with a series of rfcs through for avoiding unnecessary confusion when we see some inconsistency for example rfc vs rfc in the current implementation that should be addressed as another issue so this should be a documentation issue ,1 35096,6412685159.0,IssuesEvent,2017-08-08 04:31:21,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: indentation of raw strings in examples looks suboptimal in godoc,Documentation NeedsFix Suggested,"### Motivation There are two ways a Go [example](https://godoc.org/testing#hdr-Examples) can be read: 1. In the source code of a _test.go file. 2. Via `godoc` command or the web interface it provides. In most cases, examples look equally good in both interfaces. However, in some cases, there may be two alternative ways to write an example, such that one of them looks better inside source code, and the other looks better in the godoc interface. My understanding is that it's better to prioritize the godoc interface over the source code, since most people will be reading examples via godoc (be it locally, or via https://godoc.org, or https://golang.org/pkg/). If that is not correct, the rest of this issue is not valid. ## Issue I found that there are 5 examples in `encoding/json` package that have raw strings with indentation which is suboptimal when seen via the godoc interface. They are: - [ ] https://tip.golang.org/pkg/encoding/json/#example_Decoder: ![image](https://user-images.githubusercontent.com/1924134/28241824-68a28366-6959-11e7-89d7-2c74dab82d11.png) - [x] https://tip.golang.org/pkg/encoding/json/#example_Decoder_Decode_stream: (Resolved by CL [48910](https://golang.org/cl/48910).) ![image](https://user-images.githubusercontent.com/1924134/28241827-75ee5496-6959-11e7-9944-f7ddb66308dd.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_Decoder_Token: ![image](https://user-images.githubusercontent.com/1924134/28241828-7f1f46ec-6959-11e7-9512-b77c36adfec0.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_Unmarshal: ![image](https://user-images.githubusercontent.com/1924134/28244990-79478be4-69b8-11e7-931c-8110289ec0ed.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_RawMessage_unmarshal: ![image](https://user-images.githubusercontent.com/1924134/28245003-b28835f2-69b8-11e7-81e9-14ff04275f5b.png) Their readability in godoc interface can be improved by dedenting the contents of the raw string by 1 tab.",1.0,"encoding/json: indentation of raw strings in examples looks suboptimal in godoc - ### Motivation There are two ways a Go [example](https://godoc.org/testing#hdr-Examples) can be read: 1. In the source code of a _test.go file. 2. Via `godoc` command or the web interface it provides. In most cases, examples look equally good in both interfaces. However, in some cases, there may be two alternative ways to write an example, such that one of them looks better inside source code, and the other looks better in the godoc interface. My understanding is that it's better to prioritize the godoc interface over the source code, since most people will be reading examples via godoc (be it locally, or via https://godoc.org, or https://golang.org/pkg/). If that is not correct, the rest of this issue is not valid. ## Issue I found that there are 5 examples in `encoding/json` package that have raw strings with indentation which is suboptimal when seen via the godoc interface. They are: - [ ] https://tip.golang.org/pkg/encoding/json/#example_Decoder: ![image](https://user-images.githubusercontent.com/1924134/28241824-68a28366-6959-11e7-89d7-2c74dab82d11.png) - [x] https://tip.golang.org/pkg/encoding/json/#example_Decoder_Decode_stream: (Resolved by CL [48910](https://golang.org/cl/48910).) ![image](https://user-images.githubusercontent.com/1924134/28241827-75ee5496-6959-11e7-9944-f7ddb66308dd.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_Decoder_Token: ![image](https://user-images.githubusercontent.com/1924134/28241828-7f1f46ec-6959-11e7-9512-b77c36adfec0.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_Unmarshal: ![image](https://user-images.githubusercontent.com/1924134/28244990-79478be4-69b8-11e7-931c-8110289ec0ed.png) - [ ] https://tip.golang.org/pkg/encoding/json/#example_RawMessage_unmarshal: ![image](https://user-images.githubusercontent.com/1924134/28245003-b28835f2-69b8-11e7-81e9-14ff04275f5b.png) Their readability in godoc interface can be improved by dedenting the contents of the raw string by 1 tab.",1,encoding json indentation of raw strings in examples looks suboptimal in godoc motivation there are two ways a go can be read in the source code of a test go file via godoc command or the web interface it provides in most cases examples look equally good in both interfaces however in some cases there may be two alternative ways to write an example such that one of them looks better inside source code and the other looks better in the godoc interface my understanding is that it s better to prioritize the godoc interface over the source code since most people will be reading examples via godoc be it locally or via or if that is not correct the rest of this issue is not valid issue i found that there are examples in encoding json package that have raw strings with indentation which is suboptimal when seen via the godoc interface they are resolved by cl their readability in godoc interface can be improved by dedenting the contents of the raw string by tab ,1 47006,7298966897.0,IssuesEvent,2018-02-26 18:36:23,golang/go,https://api.github.com/repos/golang/go,closed,unsafe: wrong type mentioned in explanation,Documentation NeedsFix help wanted,"> In this usage hdr.Data is really an alternate way to refer to the underlying pointer in the **slice** header, not a uintptr variable itself. **slice** should be **string**",1.0,"unsafe: wrong type mentioned in explanation - > In this usage hdr.Data is really an alternate way to refer to the underlying pointer in the **slice** header, not a uintptr variable itself. **slice** should be **string**",1,unsafe wrong type mentioned in explanation in this usage hdr data is really an alternate way to refer to the underlying pointer in the slice header not a uintptr variable itself slice should be string ,1 62394,8603381558.0,IssuesEvent,2018-11-16 16:40:17,golang/go,https://api.github.com/repos/golang/go,closed,net/http: SameSite description is grammatically incorrect,Documentation help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go 1.11.x ### Does this issue reproduce with the latest release? The issue is with the documentation for net/http/SameSite documentation which was added in go 1.11 ### What did you expect to see? I believe the following captures the intended description, without restructuring it too significantly **SameSite allows a server to define a cookie attribute making it impossible for the browser to send this cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage and provide some protection against cross-site request forgery attacks.** ### What did you see instead? SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks. ",1.0,"net/http: SameSite description is grammatically incorrect - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go 1.11.x ### Does this issue reproduce with the latest release? The issue is with the documentation for net/http/SameSite documentation which was added in go 1.11 ### What did you expect to see? I believe the following captures the intended description, without restructuring it too significantly **SameSite allows a server to define a cookie attribute making it impossible for the browser to send this cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage and provide some protection against cross-site request forgery attacks.** ### What did you see instead? SameSite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage, and provides some protection against cross-site request forgery attacks. ",1,net http samesite description is grammatically incorrect please answer these questions before submitting your issue thanks what version of go are you using go version go x does this issue reproduce with the latest release the issue is with the documentation for net http samesite documentation which was added in go what did you expect to see i believe the following captures the intended description without restructuring it too significantly samesite allows a server to define a cookie attribute making it impossible for the browser to send this cookie along with cross site requests the main goal is to mitigate the risk of cross origin information leakage and provide some protection against cross site request forgery attacks what did you see instead samesite allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross site requests the main goal is mitigate the risk of cross origin information leakage and provides some protection against cross site request forgery attacks ,1 62145,8577586029.0,IssuesEvent,2018-11-13 00:43:24,golang/go,https://api.github.com/repos/golang/go,closed,spec: documentation of len() in string type unclear,Documentation NeedsInvestigation,"https://github.com/golang/go/blob/f58b02a29c395b5ec28bb548b1fd3ca18e2b3a4f/doc/go_spec.html#L833 The documentation on how specifically `len()` can be used to determine the size of a string type in bytes can be confusing as this would make you expect that `len(""go"")` would return `16` (like `unsafe.Sizeof(""go"")` would) but actually gives you `2` I would like to ask for a better phrasing of how to use `len()` on string type in the docs",1.0,"spec: documentation of len() in string type unclear - https://github.com/golang/go/blob/f58b02a29c395b5ec28bb548b1fd3ca18e2b3a4f/doc/go_spec.html#L833 The documentation on how specifically `len()` can be used to determine the size of a string type in bytes can be confusing as this would make you expect that `len(""go"")` would return `16` (like `unsafe.Sizeof(""go"")` would) but actually gives you `2` I would like to ask for a better phrasing of how to use `len()` on string type in the docs",1,spec documentation of len in string type unclear the documentation on how specifically len can be used to determine the size of a string type in bytes can be confusing as this would make you expect that len go would return like unsafe sizeof go would but actually gives you i would like to ask for a better phrasing of how to use len on string type in the docs,1 425255,29298484096.0,IssuesEvent,2023-05-25 00:05:52,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: please document that float +inf/-inf/nan will cause json.Marshal return error ,Documentation NeedsFix,"What version of Go are you using (go version)? go version go1.19.2 darwin/amd64 Does this issue reproduce with the latest release? It does with go playground What did you do? Same as https://github.com/golang/go/issues/3480 https://play.golang.org/p/K4xwS7iy4MP What did you expect to see? Document that float +inf/-inf/nan will cause json.Marshal return error or Not throwing serialization errors on basic numeric data types with valid state. What did you see instead? No document of this kind of thing and return json: unsupported value: NaN Should golang standard library document possible/common error type of a package or a function like windows api document(https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew) or linux man (https://linux.die.net/man/3/mmap)? Code with standard library sometime looks like try and fix again and again without document of possible/common error type. reference: * https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript * https://github.com/golang/go/issues/3480 * https://github.com/golang/go/issues/25721 * https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew * https://linux.die.net/man/3/mmap",1.0,"encoding/json: please document that float +inf/-inf/nan will cause json.Marshal return error - What version of Go are you using (go version)? go version go1.19.2 darwin/amd64 Does this issue reproduce with the latest release? It does with go playground What did you do? Same as https://github.com/golang/go/issues/3480 https://play.golang.org/p/K4xwS7iy4MP What did you expect to see? Document that float +inf/-inf/nan will cause json.Marshal return error or Not throwing serialization errors on basic numeric data types with valid state. What did you see instead? No document of this kind of thing and return json: unsupported value: NaN Should golang standard library document possible/common error type of a package or a function like windows api document(https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew) or linux man (https://linux.die.net/man/3/mmap)? Code with standard library sometime looks like try and fix again and again without document of possible/common error type. reference: * https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript * https://github.com/golang/go/issues/3480 * https://github.com/golang/go/issues/25721 * https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-deletefilew * https://linux.die.net/man/3/mmap",1,encoding json please document that float inf inf nan will cause json marshal return error what version of go are you using go version go version darwin does this issue reproduce with the latest release it does with go playground what did you do same as what did you expect to see document that float inf inf nan will cause json marshal return error or not throwing serialization errors on basic numeric data types with valid state what did you see instead no document of this kind of thing and return json unsupported value nan should golang standard library document possible common error type of a package or a function like windows api document or linux man code with standard library sometime looks like try and fix again and again without document of possible common error type reference ,1 167413,14112202675.0,IssuesEvent,2020-11-07 03:53:23,golang/go,https://api.github.com/repos/golang/go,closed,archive/zip: documentation refers to io.FS instead of fs.FS,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version devel +633f9e2060 Wed Nov 4 06:42:33 2020 +0000 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/artyom/Library/Caches/go-build""
GOENV=""/Users/artyom/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""-ldflags=-w -trimpath""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/artyom/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/artyom/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/artyom/Repositories/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/artyom/Repositories/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lb/3rk8rqs53czgb4v35w_342xc0000gn/T/go-build536273506=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Checked archive/zip documentation to see whether package implements newly added FS interface: ``` go (master) ¶ ./bin/go doc -all archive/zip | grep -C2 FS func (r *Reader) Open(name string) (fs.File, error) Open opens the named file in the ZIP archive, using the semantics of io.FS.Open: paths are always slash separated, with no leading / or ../ elements. ``` ### What did you expect to see? Documentation mentions [fs.FS interface](https://tip.golang.org/pkg/io/fs/#FS) ### What did you see instead? Documentation refers to non-existing io.FS",1.0,"archive/zip: documentation refers to io.FS instead of fs.FS - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +633f9e2060 Wed Nov 4 06:42:33 2020 +0000 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/artyom/Library/Caches/go-build""
GOENV=""/Users/artyom/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""-ldflags=-w -trimpath""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/artyom/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/artyom/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/artyom/Repositories/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/artyom/Repositories/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lb/3rk8rqs53czgb4v35w_342xc0000gn/T/go-build536273506=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Checked archive/zip documentation to see whether package implements newly added FS interface: ``` go (master) ¶ ./bin/go doc -all archive/zip | grep -C2 FS func (r *Reader) Open(name string) (fs.File, error) Open opens the named file in the ZIP archive, using the semantics of io.FS.Open: paths are always slash separated, with no leading / or ../ elements. ``` ### What did you expect to see? Documentation mentions [fs.FS interface](https://tip.golang.org/pkg/io/fs/#FS) ### What did you see instead? Documentation refers to non-existing io.FS",1,archive zip documentation refers to io fs instead of fs fs please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version devel wed nov darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env on goarch gobin gocache users artyom library caches go build goenv users artyom library application support go env goexe goflags ldflags w trimpath gohostarch gohostos darwin goinsecure gomodcache users artyom go pkg mod gonoproxy gonosumdb goos darwin gopath users artyom go goprivate goproxy goroot users artyom repositories go gosumdb sum golang org gotmpdir gotooldir users artyom repositories go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders lb t go tmp go build gno record gcc switches fno common 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 checked archive zip documentation to see whether package implements newly added fs interface go master ¶ bin go doc all archive zip grep fs func r reader open name string fs file error open opens the named file in the zip archive using the semantics of io fs open paths are always slash separated with no leading or elements what did you expect to see documentation mentions what did you see instead documentation refers to non existing io fs,1 88233,10567109628.0,IssuesEvent,2019-10-06 00:34:20,golang/go,https://api.github.com/repos/golang/go,closed,unicode/utf8: document specification,Documentation NeedsFix,"The `utf8` package merely documents that it ""supports text encoded in UTF-8"", but doesn't point to any external sources for what ""UTF-8"" exactly is. I'm not an expert in this area, but my understanding is that UTF-8 is formally defined in [RFC 3629](https://tools.ietf.org/html/rfc3629). Is that true? Furthermore, does the `Valid` function implement validation for merely the syntax of UTF-8 encoding ([section 4](https://tools.ietf.org/html/rfc3629#section-4)) or a validation of the ""definition"" of UTF-8 ([section 3](https://tools.ietf.org/html/rfc3629#section-3))? The code seems to suggest that it is the later. The godoc does not make this clear to me and probably should be documented.",1.0,"unicode/utf8: document specification - The `utf8` package merely documents that it ""supports text encoded in UTF-8"", but doesn't point to any external sources for what ""UTF-8"" exactly is. I'm not an expert in this area, but my understanding is that UTF-8 is formally defined in [RFC 3629](https://tools.ietf.org/html/rfc3629). Is that true? Furthermore, does the `Valid` function implement validation for merely the syntax of UTF-8 encoding ([section 4](https://tools.ietf.org/html/rfc3629#section-4)) or a validation of the ""definition"" of UTF-8 ([section 3](https://tools.ietf.org/html/rfc3629#section-3))? The code seems to suggest that it is the later. The godoc does not make this clear to me and probably should be documented.",1,unicode document specification the package merely documents that it supports text encoded in utf but doesn t point to any external sources for what utf exactly is i m not an expert in this area but my understanding is that utf is formally defined in is that true furthermore does the valid function implement validation for merely the syntax of utf encoding or a validation of the definition of utf the code seems to suggest that it is the later the godoc does not make this clear to me and probably should be documented ,1 95120,10866568624.0,IssuesEvent,2019-11-14 21:33:33,golang/go,https://api.github.com/repos/golang/go,closed,doc: doc/articles/wiki test failing when GOROOT is read-only,Documentation NeedsFix,"From https://build.golang.org/log/e704977e8e25fee42871ecc456d8e0045f01db3f (thanks @mengzhuo!): ``` ##### ../doc/articles/wiki go build command-line-arguments: copying /tmp/workdir-host-linux-mipsle-mengzhuo/tmp/go-build204611216/b001/exe/a.out: open get.bin: permission denied kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] 2019/11/14 05:35:08 Failed: exit status 2 2019/11/14 05:35:09 FAILED ``` (Part of #28387, the continuing saga.)",1.0,"doc: doc/articles/wiki test failing when GOROOT is read-only - From https://build.golang.org/log/e704977e8e25fee42871ecc456d8e0045f01db3f (thanks @mengzhuo!): ``` ##### ../doc/articles/wiki go build command-line-arguments: copying /tmp/workdir-host-linux-mipsle-mengzhuo/tmp/go-build204611216/b001/exe/a.out: open get.bin: permission denied kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] 2019/11/14 05:35:08 Failed: exit status 2 2019/11/14 05:35:09 FAILED ``` (Part of #28387, the continuing saga.)",1,doc doc articles wiki test failing when goroot is read only from thanks mengzhuo doc articles wiki go build command line arguments copying tmp workdir host linux mipsle mengzhuo tmp go exe a out open get bin permission denied kill usage kill pid jobspec or kill l failed exit status failed part of the continuing saga ,1 52731,13042184567.0,IssuesEvent,2020-07-28 21:54:13,golang/go,https://api.github.com/repos/golang/go,closed,Packages under rsc.io are no longer available,Builders NeedsInvestigation Soon," ### What version of Go are you using (`go version`)? Go 1.12, Go 1.14 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? I don't think this matters but here it goes. This failed both on my laptop with Go 1.14 and in GitHub Action that uses Go1.12
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/yenlinc/Library/Caches/go-build""
GOENV=""/Users/yenlinc/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""*""
GONOSUMDB=""*""
GOOS=""darwin""
GOPATH=""/Users/yenlinc/go""
GOPRIVATE=""*""
GOPROXY=""direct""
GOROOT=""/usr/local/Cellar/go/1.14.3/libexec""
GOSUMDB=""off""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.14.3/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/yenlinc/workplace/yenlinc/amazon-kinesis-streams-for-fluent-bit/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/v4/nbxvs8tj4ms68w5ghhnzn_f1ckngqg/T/go-build594642831=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Ran `go build` command ### What did you expect to see? Modules should be fetched successfully and compilation should succeed. ### What did you see instead? Since this morning, 2 packages under `rsc.io` have been failing: ``` go build -buildmode c-shared -o ./bin/kinesis.so ./ go: github.com/aws/amazon-kinesis-firehose-for-fluent-bit@v1.4.1 requires github.com/golang/mock@v1.4.3 requires rsc.io/quote/v3@v3.1.0: unrecognized import path ""rsc.io/quote/v3"": reading https://rsc.io/quote/v3?go-get=1: 503 Service Unavailable ``` ``` $ go mod download go: finding github.com/aws/amazon-kinesis-firehose-for-fluent-bit v1.2.2-0.20200717080229-e3ffb88e79bb go: finding github.com/aws/aws-sdk-go v1.33.13 go: finding github.com/lestrrat-go/strftime v1.0.2-0.20200618102204-1b0bc59fa4ab go: finding github.com/stretchr/objx v0.3.0 go: finding github.com/sirupsen/logrus v1.6.0 go: finding github.com/yuin/goldmark v1.1.33 go: rsc.io/sampler@v1.99.99: unrecognized import path ""rsc.io/sampler"" (parse https://rsc.io/sampler?go-get=1: no go-import meta tags ()) go: finding golang.org/x/crypto v0.0.0-20200709230013-948cd5f35899 go: finding golang.org/x/text v0.3.3 go: finding github.com/google/gofuzz v1.1.0 go: finding gopkg.in/yaml.v3 v3.0.0-20200615113413-eeeca48fe776 go: finding github.com/cenkalti/backoff v2.2.1+incompatible go: finding golang.org/x/net v0.0.0-20200707034311-ab3426394381 go: finding github.com/fluent/fluent-bit-go v0.0.0-20200707230002-2a28684e2382 go: finding github.com/stretchr/testify v1.6.1 go: finding github.com/json-iterator/go v1.1.10 go: finding gopkg.in/check.v1 v1.0.0-20200227125254-8fa46927fb4f go: finding golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae go: finding golang.org/x/tools v0.0.0-20200717024301-6ddee64345a6 go: finding github.com/golang/mock v1.4.3 go: error loading module requirements ``` ",1.0,"Packages under rsc.io are no longer available - ### What version of Go are you using (`go version`)? Go 1.12, Go 1.14 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? I don't think this matters but here it goes. This failed both on my laptop with Go 1.14 and in GitHub Action that uses Go1.12
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/yenlinc/Library/Caches/go-build""
GOENV=""/Users/yenlinc/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""*""
GONOSUMDB=""*""
GOOS=""darwin""
GOPATH=""/Users/yenlinc/go""
GOPRIVATE=""*""
GOPROXY=""direct""
GOROOT=""/usr/local/Cellar/go/1.14.3/libexec""
GOSUMDB=""off""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.14.3/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/yenlinc/workplace/yenlinc/amazon-kinesis-streams-for-fluent-bit/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/v4/nbxvs8tj4ms68w5ghhnzn_f1ckngqg/T/go-build594642831=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Ran `go build` command ### What did you expect to see? Modules should be fetched successfully and compilation should succeed. ### What did you see instead? Since this morning, 2 packages under `rsc.io` have been failing: ``` go build -buildmode c-shared -o ./bin/kinesis.so ./ go: github.com/aws/amazon-kinesis-firehose-for-fluent-bit@v1.4.1 requires github.com/golang/mock@v1.4.3 requires rsc.io/quote/v3@v3.1.0: unrecognized import path ""rsc.io/quote/v3"": reading https://rsc.io/quote/v3?go-get=1: 503 Service Unavailable ``` ``` $ go mod download go: finding github.com/aws/amazon-kinesis-firehose-for-fluent-bit v1.2.2-0.20200717080229-e3ffb88e79bb go: finding github.com/aws/aws-sdk-go v1.33.13 go: finding github.com/lestrrat-go/strftime v1.0.2-0.20200618102204-1b0bc59fa4ab go: finding github.com/stretchr/objx v0.3.0 go: finding github.com/sirupsen/logrus v1.6.0 go: finding github.com/yuin/goldmark v1.1.33 go: rsc.io/sampler@v1.99.99: unrecognized import path ""rsc.io/sampler"" (parse https://rsc.io/sampler?go-get=1: no go-import meta tags ()) go: finding golang.org/x/crypto v0.0.0-20200709230013-948cd5f35899 go: finding golang.org/x/text v0.3.3 go: finding github.com/google/gofuzz v1.1.0 go: finding gopkg.in/yaml.v3 v3.0.0-20200615113413-eeeca48fe776 go: finding github.com/cenkalti/backoff v2.2.1+incompatible go: finding golang.org/x/net v0.0.0-20200707034311-ab3426394381 go: finding github.com/fluent/fluent-bit-go v0.0.0-20200707230002-2a28684e2382 go: finding github.com/stretchr/testify v1.6.1 go: finding github.com/json-iterator/go v1.1.10 go: finding gopkg.in/check.v1 v1.0.0-20200227125254-8fa46927fb4f go: finding golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae go: finding golang.org/x/tools v0.0.0-20200717024301-6ddee64345a6 go: finding github.com/golang/mock v1.4.3 go: error loading module requirements ``` ",0,packages under rsc io are no longer available please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go go does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env i don t think this matters but here it goes this failed both on my laptop with go and in github action that uses go env output go env goarch gobin gocache users yenlinc library caches go build goenv users yenlinc library application support go env goexe goflags gohostarch gohostos darwin goinsecure gonoproxy gonosumdb goos darwin gopath users yenlinc go goprivate goproxy direct goroot usr local cellar go libexec gosumdb off gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users yenlinc workplace yenlinc amazon kinesis streams for fluent bit go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do ran go build command what did you expect to see modules should be fetched successfully and compilation should succeed what did you see instead since this morning packages under rsc io have been failing go build buildmode c shared o bin kinesis so go github com aws amazon kinesis firehose for fluent bit requires github com golang mock requires rsc io quote unrecognized import path rsc io quote reading service unavailable go mod download go finding github com aws amazon kinesis firehose for fluent bit go finding github com aws aws sdk go go finding github com lestrrat go strftime go finding github com stretchr objx go finding github com sirupsen logrus go finding github com yuin goldmark go rsc io sampler unrecognized import path rsc io sampler parse no go import meta tags go finding golang org x crypto go finding golang org x text go finding github com google gofuzz go finding gopkg in yaml go finding github com cenkalti backoff incompatible go finding golang org x net go finding github com fluent fluent bit go go finding github com stretchr testify go finding github com json iterator go go finding gopkg in check go finding golang org x sys go finding golang org x tools go finding github com golang mock go error loading module requirements ,0 78704,10082124595.0,IssuesEvent,2019-07-25 10:24:18,golang/go,https://api.github.com/repos/golang/go,closed,doc: wrong link in release history,Documentation NeedsFix,"### What did you do? I visited the [release history](https://golang.org/doc/devel/release.html) page for the Go language. ### What did you expect to see? I expected the minor revisions' links to be correct. ### What did you see instead? Instead, the link to the [go1.6.4 milestone](https://golang.org/doc/devel/release.html#go1.6.minor) does not exist and in its place there is a link to the 1.7.4 milestone. The same happens with go1.7.6 and go1.5.4.",1.0,"doc: wrong link in release history - ### What did you do? I visited the [release history](https://golang.org/doc/devel/release.html) page for the Go language. ### What did you expect to see? I expected the minor revisions' links to be correct. ### What did you see instead? Instead, the link to the [go1.6.4 milestone](https://golang.org/doc/devel/release.html#go1.6.minor) does not exist and in its place there is a link to the 1.7.4 milestone. The same happens with go1.7.6 and go1.5.4.",1,doc wrong link in release history what did you do i visited the page for the go language what did you expect to see i expected the minor revisions links to be correct what did you see instead instead the link to the does not exist and in its place there is a link to the milestone the same happens with and ,1 272884,20762116106.0,IssuesEvent,2022-03-15 17:03:02,golang/go,https://api.github.com/repos/golang/go,closed,doc: write Go 1.18 release notes,Documentation help wanted NeedsFix recurring umbrella,"Tracking bug for writing the Go 1.18 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.18. When the Go 1.18 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #44513, #40700, #37419, #36878, #17929, #15810, #5929, etc.",1.0,"doc: write Go 1.18 release notes - Tracking bug for writing the Go 1.18 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.18. When the Go 1.18 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #44513, #40700, #37419, #36878, #17929, #15810, #5929, etc.",1,doc write go release notes tracking bug for writing the go release notes the latest state on tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 15125,3926470838.0,IssuesEvent,2016-04-23 00:01:43,golang/go,https://api.github.com/repos/golang/go,closed,doc: add link to security@golang.org from https://golang.org/doc/contribute.html,Documentation,"CONTRIBUTING.md points to security@golang.org > Sensitive security-related issues should be reported to security@golang.org. but the [Contribution Guidelines](https://golang.org/doc/contribute.html) does not.",1.0,"doc: add link to security@golang.org from https://golang.org/doc/contribute.html - CONTRIBUTING.md points to security@golang.org > Sensitive security-related issues should be reported to security@golang.org. but the [Contribution Guidelines](https://golang.org/doc/contribute.html) does not.",1,doc add link to security golang org from contributing md points to security golang org sensitive security related issues should be reported to security golang org but the does not ,1 89049,25570566028.0,IssuesEvent,2022-11-30 17:20:16,golang/go,https://api.github.com/repos/golang/go,reopened,x/build/cmd/coordinator: TestFindWork failures,Builders NeedsInvestigation,"``` #!watchflakes post <- pkg == ""golang.org/x/build/cmd/coordinator"" && test == ""TestFindWork"" ``` Bug automatically created to track these flakes. — watchflakes ",1.0,"x/build/cmd/coordinator: TestFindWork failures - ``` #!watchflakes post <- pkg == ""golang.org/x/build/cmd/coordinator"" && test == ""TestFindWork"" ``` Bug automatically created to track these flakes. — watchflakes ",0,x build cmd coordinator testfindwork failures watchflakes post pkg golang org x build cmd coordinator test testfindwork bug automatically created to track these flakes — watchflakes ,0 11044,3454720354.0,IssuesEvent,2015-12-17 17:00:28,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: document that ""go get"" never operates on vendor directories",Documentation,"In the docs here: https://golang.org/cmd/go/#hdr-Vendor_Directories There is a single section that mentions how the behavior of `go get` changes when the `GO15VENDOREXPERIMENT` env var is enabled: ``` When the vendor experiment is enabled, 'go get' checks out submodules when checking out or updating a git repository (see 'go help get'). ``` A source of confusion and many questions (twitter, slack) results from the assumption that running `go get` with the flag enabled will place downloaded packages into a `vendor` directory, which is not the case. A sentence or two added to the documentation would help: ``` When the vendor experiment is enabled, 'go get' checks out submodules when checking out or updating a git repository (see 'go help get'). The storage location of downloaded packages does not change with the experiment enabled; 'go get' will not place retrieved packages into a 'vendor' directory. ``` Is it possible to update the documentation prior to the next release? ",1.0,"cmd/go: document that ""go get"" never operates on vendor directories - In the docs here: https://golang.org/cmd/go/#hdr-Vendor_Directories There is a single section that mentions how the behavior of `go get` changes when the `GO15VENDOREXPERIMENT` env var is enabled: ``` When the vendor experiment is enabled, 'go get' checks out submodules when checking out or updating a git repository (see 'go help get'). ``` A source of confusion and many questions (twitter, slack) results from the assumption that running `go get` with the flag enabled will place downloaded packages into a `vendor` directory, which is not the case. A sentence or two added to the documentation would help: ``` When the vendor experiment is enabled, 'go get' checks out submodules when checking out or updating a git repository (see 'go help get'). The storage location of downloaded packages does not change with the experiment enabled; 'go get' will not place retrieved packages into a 'vendor' directory. ``` Is it possible to update the documentation prior to the next release? ",1,cmd go document that go get never operates on vendor directories in the docs here there is a single section that mentions how the behavior of go get changes when the env var is enabled when the vendor experiment is enabled go get checks out submodules when checking out or updating a git repository see go help get a source of confusion and many questions twitter slack results from the assumption that running go get with the flag enabled will place downloaded packages into a vendor directory which is not the case a sentence or two added to the documentation would help when the vendor experiment is enabled go get checks out submodules when checking out or updating a git repository see go help get the storage location of downloaded packages does not change with the experiment enabled go get will not place retrieved packages into a vendor directory is it possible to update the documentation prior to the next release ,1 68393,9172155451.0,IssuesEvent,2019-03-04 05:48:23,golang/go,https://api.github.com/repos/golang/go,closed,encoding/csv: document that Writer is buffered,Documentation NeedsFix,"`csv.Writer` is implemented as a `bufio.Writer`, but this isn't clearly documented. The only place buffering is mentioned is in the `Writer` example and in the `Flush()` method. This makes it easy for a user to neglect to flush the underlying buffer and check for an error when writing a CSV, which can result in data loss. I believe the documentation on `csv.Writer` should clearly state that the implementation is buffered and thus must be flushed. Here is the current documentation: ``` // A Writer writes records to a CSV encoded file. // // As returned by NewWriter, a Writer writes records terminated by a // newline and uses ',' as the field delimiter. The exported fields can be // changed to customize the details before the first call to Write or WriteAll. // // Comma is the field delimiter. // // If UseCRLF is true, the Writer ends each output line with \r\n instead of \n. type Writer struct { Comma rune // Field delimiter (set to ',' by NewWriter) UseCRLF bool // True to use \r\n as the line terminator w *bufio.Writer } ```",1.0,"encoding/csv: document that Writer is buffered - `csv.Writer` is implemented as a `bufio.Writer`, but this isn't clearly documented. The only place buffering is mentioned is in the `Writer` example and in the `Flush()` method. This makes it easy for a user to neglect to flush the underlying buffer and check for an error when writing a CSV, which can result in data loss. I believe the documentation on `csv.Writer` should clearly state that the implementation is buffered and thus must be flushed. Here is the current documentation: ``` // A Writer writes records to a CSV encoded file. // // As returned by NewWriter, a Writer writes records terminated by a // newline and uses ',' as the field delimiter. The exported fields can be // changed to customize the details before the first call to Write or WriteAll. // // Comma is the field delimiter. // // If UseCRLF is true, the Writer ends each output line with \r\n instead of \n. type Writer struct { Comma rune // Field delimiter (set to ',' by NewWriter) UseCRLF bool // True to use \r\n as the line terminator w *bufio.Writer } ```",1,encoding csv document that writer is buffered csv writer is implemented as a bufio writer but this isn t clearly documented the only place buffering is mentioned is in the writer example and in the flush method this makes it easy for a user to neglect to flush the underlying buffer and check for an error when writing a csv which can result in data loss i believe the documentation on csv writer should clearly state that the implementation is buffered and thus must be flushed here is the current documentation a writer writes records to a csv encoded file as returned by newwriter a writer writes records terminated by a newline and uses as the field delimiter the exported fields can be changed to customize the details before the first call to write or writeall comma is the field delimiter if usecrlf is true the writer ends each output line with r n instead of n type writer struct comma rune field delimiter set to by newwriter usecrlf bool true to use r n as the line terminator w bufio writer ,1 214391,16563198123.0,IssuesEvent,2021-05-29 00:16:57,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document text/template/parse changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
text/template/parse

TODO: https://golang.org/cl/301493: add a mode to skip func-check on parsing

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46025."" in the body.",1.0,"doc/go1.17: document text/template/parse changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
text/template/parse

TODO: https://golang.org/cl/301493: add a mode to skip func-check on parsing

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46025."" in the body.",1,doc document text template parse changes for go as of filing this issue the contained the following html text template parse todo a href add a mode to skip func check on parsing this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 14750,3881178911.0,IssuesEvent,2016-04-13 02:29:02,golang/go,https://api.github.com/repos/golang/go,closed,html/template: Provide an example of loading a template from a file and executing it.,Documentation,"by **kburkeorg**: 
Most websites store their templates in files on disk. It would be convenient if the
documentation provided an example with template data stored in a file, then loaded into
memory and executed with variables and a byte buffer.
",1.0,"html/template: Provide an example of loading a template from a file and executing it. - by **kburkeorg**: 
Most websites store their templates in files on disk. It would be convenient if the
documentation provided an example with template data stored in a file, then loaded into
memory and executed with variables and a byte buffer.
",1,html template provide an example of loading a template from a file and executing it by kburkeorg most websites store their templates in files on disk it would be convenient if the documentation provided an example with template data stored in a file then loaded into memory and executed with variables and a byte buffer ,1 108063,11579674191.0,IssuesEvent,2020-02-21 18:27:03,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: document change in Number behavior for 1.14,Documentation NeedsFix release-blocker,"I just upgraded one of our internal repositories to Go 1.14rc1 and our tests failed. The reason the tests failed is due to this issue: https://github.com/golang/go/issues/14702 I had to go in and update our code base to make Go 1.14 work, so it's technically a breaking change. More dangerously, this is a **runtime** breaking change and not a compile time one. so I can only imagine the number of Go apps out there running in production that would break because of this. As much as I like the new behavior, I imagine this might cause some production apps to go down in the wild. On one hand, the repository was incorrectly using json.Number and treating it as something that *could* be a number, but would also **allow strings**. In fact, people probably assume that's what json.Number is since it is of type string. I'm opening a new issue instead of commenting on the old one because I'd like to bring light into this breaking behavior and make sure we have a decision before Go 1.14 is officially released. cc: @mvdan @rsc Thanks! $ go version Go 1.14rc1, darwin ",1.0,"encoding/json: document change in Number behavior for 1.14 - I just upgraded one of our internal repositories to Go 1.14rc1 and our tests failed. The reason the tests failed is due to this issue: https://github.com/golang/go/issues/14702 I had to go in and update our code base to make Go 1.14 work, so it's technically a breaking change. More dangerously, this is a **runtime** breaking change and not a compile time one. so I can only imagine the number of Go apps out there running in production that would break because of this. As much as I like the new behavior, I imagine this might cause some production apps to go down in the wild. On one hand, the repository was incorrectly using json.Number and treating it as something that *could* be a number, but would also **allow strings**. In fact, people probably assume that's what json.Number is since it is of type string. I'm opening a new issue instead of commenting on the old one because I'd like to bring light into this breaking behavior and make sure we have a decision before Go 1.14 is officially released. cc: @mvdan @rsc Thanks! $ go version Go 1.14rc1, darwin ",1,encoding json document change in number behavior for i just upgraded one of our internal repositories to go and our tests failed the reason the tests failed is due to this issue i had to go in and update our code base to make go work so it s technically a breaking change more dangerously this is a runtime breaking change and not a compile time one so i can only imagine the number of go apps out there running in production that would break because of this as much as i like the new behavior i imagine this might cause some production apps to go down in the wild on one hand the repository was incorrectly using json number and treating it as something that could be a number but would also allow strings in fact people probably assume that s what json number is since it is of type string i m opening a new issue instead of commenting on the old one because i d like to bring light into this breaking behavior and make sure we have a decision before go is officially released cc mvdan rsc thanks go version go darwin ,1 180843,14814879837.0,IssuesEvent,2021-01-14 06:03:17,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: defining the workspace root,Documentation Tools gopls,"`gopls` supports both module and GOPATH modes. However, we need to define a scope in which language features like references, rename, and implementation should operate. The following is subject to, and will likely, change. For now, we have the following cases: ### Module mode #### Supported - Open workspace at the module root (directory containing the `go.mod` file). The scope is the entire module. - Open a subdirectory of a module. The scope is the subdirectory that has been opened. #### Unsupported - Open a directory that contains a module in a subdirectory. `gopls` will not work in this case. ### GOPATH mode #### Supported - Open a directory inside of your GOPATH. The scope is the open directory. #### At your own risk - Open your entire GOPATH. The workspace scope will be your entire `GOPATH`. Note that this will cause `gopls` to load your entire GOPATH. If your GOPATH is large, this will take a long time and cause `gopls` to be very slow. To work around this case, you can create a new GOPATH that contains only the packages you want to work on. #### Unsupported - Open a directory containing your GOPATH. Similar to the case above, this will cause `gopls` to treat your entire GOPATH as the workspace scope. It will be very slow to start because it will try to find all of the Go files in the directory you have opened. It will then load all of the files it has found. --- We are working on addressing all of these cases and improving the behavior of `gopls` in the unsupported cases. All of these cases will be supported once `gopls` reaches `v1.0.0`. We understand it may be inconvenient to change your typical workflow to accommodate frequent changes in `gopls`. In this case, it may be easier to stick with a version of `gopls` that works for you (`gopls/v0.2.2`, for instance), or if you are using GOPATH, `gopls` may not be the best tool to use until it reaches `v1.0.0`. If you have additional use cases that are not mentioned above, please comment below. ",1.0,"x/tools/gopls: defining the workspace root - `gopls` supports both module and GOPATH modes. However, we need to define a scope in which language features like references, rename, and implementation should operate. The following is subject to, and will likely, change. For now, we have the following cases: ### Module mode #### Supported - Open workspace at the module root (directory containing the `go.mod` file). The scope is the entire module. - Open a subdirectory of a module. The scope is the subdirectory that has been opened. #### Unsupported - Open a directory that contains a module in a subdirectory. `gopls` will not work in this case. ### GOPATH mode #### Supported - Open a directory inside of your GOPATH. The scope is the open directory. #### At your own risk - Open your entire GOPATH. The workspace scope will be your entire `GOPATH`. Note that this will cause `gopls` to load your entire GOPATH. If your GOPATH is large, this will take a long time and cause `gopls` to be very slow. To work around this case, you can create a new GOPATH that contains only the packages you want to work on. #### Unsupported - Open a directory containing your GOPATH. Similar to the case above, this will cause `gopls` to treat your entire GOPATH as the workspace scope. It will be very slow to start because it will try to find all of the Go files in the directory you have opened. It will then load all of the files it has found. --- We are working on addressing all of these cases and improving the behavior of `gopls` in the unsupported cases. All of these cases will be supported once `gopls` reaches `v1.0.0`. We understand it may be inconvenient to change your typical workflow to accommodate frequent changes in `gopls`. In this case, it may be easier to stick with a version of `gopls` that works for you (`gopls/v0.2.2`, for instance), or if you are using GOPATH, `gopls` may not be the best tool to use until it reaches `v1.0.0`. If you have additional use cases that are not mentioned above, please comment below. ",1,x tools gopls defining the workspace root gopls supports both module and gopath modes however we need to define a scope in which language features like references rename and implementation should operate the following is subject to and will likely change for now we have the following cases module mode supported open workspace at the module root directory containing the go mod file the scope is the entire module open a subdirectory of a module the scope is the subdirectory that has been opened unsupported open a directory that contains a module in a subdirectory gopls will not work in this case gopath mode supported open a directory inside of your gopath the scope is the open directory at your own risk open your entire gopath the workspace scope will be your entire gopath note that this will cause gopls to load your entire gopath if your gopath is large this will take a long time and cause gopls to be very slow to work around this case you can create a new gopath that contains only the packages you want to work on unsupported open a directory containing your gopath similar to the case above this will cause gopls to treat your entire gopath as the workspace scope it will be very slow to start because it will try to find all of the go files in the directory you have opened it will then load all of the files it has found we are working on addressing all of these cases and improving the behavior of gopls in the unsupported cases all of these cases will be supported once gopls reaches we understand it may be inconvenient to change your typical workflow to accommodate frequent changes in gopls in this case it may be easier to stick with a version of gopls that works for you gopls for instance or if you are using gopath gopls may not be the best tool to use until it reaches if you have additional use cases that are not mentioned above please comment below ,1 151629,13428050122.0,IssuesEvent,2020-09-06 20:24:28,golang/go,https://api.github.com/repos/golang/go,closed,go/ast: mention strconv.Unquote in BasicLit documentation,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/tenntenn/Library/Caches/go-build""
GOENV=""/Users/tenntenn/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/tenntenn/Documents/gopath""
GOPRIVATE=""""
GOPROXY=""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=""""
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/wm/76fqhrc52ls25p4cmjrjbdqh0000gp/T/go-build969893907=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://golang.org/pkg/go/ast/#BasicLit ### What did you expect to see? I propose improve the document of `ast.BasicLit`. When `BasicLit.Kind` is `token.STRING`, we must call `strconv.Unquote` to get unquoted string value. So I think the document of `ast.BasicLit` should refer to `strconv.Unquote`. ### What did you see instead? https://golang.org/pkg/go/ast/#BasicLit",1.0,"go/ast: mention strconv.Unquote in BasicLit documentation - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/tenntenn/Library/Caches/go-build""
GOENV=""/Users/tenntenn/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/tenntenn/Documents/gopath""
GOPRIVATE=""""
GOPROXY=""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=""""
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/wm/76fqhrc52ls25p4cmjrjbdqh0000gp/T/go-build969893907=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://golang.org/pkg/go/ast/#BasicLit ### What did you expect to see? I propose improve the document of `ast.BasicLit`. When `BasicLit.Kind` is `token.STRING`, we must call `strconv.Unquote` to get unquoted string value. So I think the document of `ast.BasicLit` should refer to `strconv.Unquote`. ### What did you see instead? https://golang.org/pkg/go/ast/#BasicLit",1,go ast mention strconv unquote in basiclit documentation please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users tenntenn library caches go build goenv users tenntenn library application support go env goexe goflags gohostarch gohostos darwin goinsecure gonoproxy gonosumdb goos darwin gopath users tenntenn documents gopath goprivate goproxy direct goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders wm t go tmp go build gno record gcc switches fno common 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 what did you expect to see i propose improve the document of ast basiclit when basiclit kind is token string we must call strconv unquote to get unquoted string value so i think the document of ast basiclit should refer to strconv unquote what did you see instead ,1 219469,17093072139.0,IssuesEvent,2021-07-08 20:22:57,golang/go,https://api.github.com/repos/golang/go,closed,net: TestCVE202133195 fails if /etc/resolv.conf specifies ndots larger than 3 [1.15 backport],CherryPickCandidate Testing,"@shawn-xdji requested issue #46955 to be considered for backport to the next 1.15 minor release. > @gopherbot ple​ase consider this for backport to 1.15, it's a test failure",1.0,"net: TestCVE202133195 fails if /etc/resolv.conf specifies ndots larger than 3 [1.15 backport] - @shawn-xdji requested issue #46955 to be considered for backport to the next 1.15 minor release. > @gopherbot ple​ase consider this for backport to 1.15, it's a test failure",0,net fails if etc resolv conf specifies ndots larger than shawn xdji requested issue to be considered for backport to the next minor release gopherbot ple​ase consider this for backport to it s a test failure,0 142605,13035159265.0,IssuesEvent,2020-07-28 09:54:04,golang/go,https://api.github.com/repos/golang/go,closed,x/blog: some more details in `/json` section,Documentation,"### What did you expect to see? Iam from Python background and hence it was little bit difficult for me to understand how unmarshalling works, specially if the keywords are `lowercase` The https://blog.golang.org/json blog appears in the top of the search while searching for json. There is this line ```The json package only accesses the exported fields of struct types (those that begin with an uppercase letter). Therefore only the the exported fields of a struct will be present in the JSON output.``` It would be great if we could also add an example saying ```If your json has lowercase keys, then you might have to follow the below snippet to access them. For further information check out https://golang.org/pkg/encoding/json/#Marshal``` ```go type Message struct { Name string `json:”name” Body string `json:”body” Time int64 `json:”time” } ``` ### What did you see instead? The example stops with the ```The json package only accesses the exported fields of struct types (those that begin with an uppercase letter). Therefore only the the exported fields of a struct will be present in the JSON output.``` This makes it bit difficult for new comers to easily understand the techniques that are very trivial. I would be happy to submit PR, but I dont know where the docs of blog are.",1.0,"x/blog: some more details in `/json` section - ### What did you expect to see? Iam from Python background and hence it was little bit difficult for me to understand how unmarshalling works, specially if the keywords are `lowercase` The https://blog.golang.org/json blog appears in the top of the search while searching for json. There is this line ```The json package only accesses the exported fields of struct types (those that begin with an uppercase letter). Therefore only the the exported fields of a struct will be present in the JSON output.``` It would be great if we could also add an example saying ```If your json has lowercase keys, then you might have to follow the below snippet to access them. For further information check out https://golang.org/pkg/encoding/json/#Marshal``` ```go type Message struct { Name string `json:”name” Body string `json:”body” Time int64 `json:”time” } ``` ### What did you see instead? The example stops with the ```The json package only accesses the exported fields of struct types (those that begin with an uppercase letter). Therefore only the the exported fields of a struct will be present in the JSON output.``` This makes it bit difficult for new comers to easily understand the techniques that are very trivial. I would be happy to submit PR, but I dont know where the docs of blog are.",1,x blog some more details in json section what did you expect to see iam from python background and hence it was little bit difficult for me to understand how unmarshalling works specially if the keywords are lowercase the blog appears in the top of the search while searching for json there is this line the json package only accesses the exported fields of struct types those that begin with an uppercase letter therefore only the the exported fields of a struct will be present in the json output it would be great if we could also add an example saying if your json has lowercase keys then you might have to follow the below snippet to access them for further information check out go type message struct name string json ”name” body string json ”body” time json ”time” what did you see instead the example stops with the the json package only accesses the exported fields of struct types those that begin with an uppercase letter therefore only the the exported fields of a struct will be present in the json output this makes it bit difficult for new comers to easily understand the techniques that are very trivial i would be happy to submit pr but i dont know where the docs of blog are ,1 98952,11101837509.0,IssuesEvent,2019-12-16 22:19:09,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: document automatic use of -mod=readonly and less-aggressive go.mod updates for Go 1.14,Documentation NeedsFix modules release-blocker,Realized that I'm missing some release notes for `-mod=readonly` and `go.mod` file maintenance in general for Go 1.14. This is a note-to-self to remember to add them soon. (I'll add issue references in the CL.),1.0,cmd/go: document automatic use of -mod=readonly and less-aggressive go.mod updates for Go 1.14 - Realized that I'm missing some release notes for `-mod=readonly` and `go.mod` file maintenance in general for Go 1.14. This is a note-to-self to remember to add them soon. (I'll add issue references in the CL.),1,cmd go document automatic use of mod readonly and less aggressive go mod updates for go realized that i m missing some release notes for mod readonly and go mod file maintenance in general for go this is a note to self to remember to add them soon i ll add issue references in the cl ,1 2378,3807249475.0,IssuesEvent,2016-03-25 06:40:01,golang/go,https://api.github.com/repos/golang/go,opened,syscall: guard against Windows DLL preloading attacks ,Security,"Taru Karttunen noted that Go should be more paranoid by default when loading DLLs. Background: https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/ Microsoft's guidelines: https://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx LoadLibraryEx docs: https://msdn.microsoft.com/en-us/library/ms684179(v=vs.85).aspx @rsc proposed: > 1) Change syscall.LoadDLL to call LoadLibraryEx with flags=LOAD_LIBRARY_SEARCH_SYSTEM32 instead of calling LoadLibrary. That is, LoadDLL is now secure by default and cannot load DLLs from the directory containing the executable. > 2) Add a LoadLibraryEx to x/sys/win so that users can still get at the old behavior if they want it (by appropriate passing of flags). CL forthcoming. /cc @alexbrainman @adg @broady @jbuberel @ianlancetaylor ",True,"syscall: guard against Windows DLL preloading attacks - Taru Karttunen noted that Go should be more paranoid by default when loading DLLs. Background: https://textplain.wordpress.com/2015/12/18/dll-hijacking-just-wont-die/ Microsoft's guidelines: https://msdn.microsoft.com/en-us/library/ff919712%28VS.85%29.aspx LoadLibraryEx docs: https://msdn.microsoft.com/en-us/library/ms684179(v=vs.85).aspx @rsc proposed: > 1) Change syscall.LoadDLL to call LoadLibraryEx with flags=LOAD_LIBRARY_SEARCH_SYSTEM32 instead of calling LoadLibrary. That is, LoadDLL is now secure by default and cannot load DLLs from the directory containing the executable. > 2) Add a LoadLibraryEx to x/sys/win so that users can still get at the old behavior if they want it (by appropriate passing of flags). CL forthcoming. /cc @alexbrainman @adg @broady @jbuberel @ianlancetaylor ",0,syscall guard against windows dll preloading attacks taru karttunen noted that go should be more paranoid by default when loading dlls background microsoft s guidelines loadlibraryex docs rsc proposed change syscall loaddll to call loadlibraryex with flags load library search instead of calling loadlibrary that is loaddll is now secure by default and cannot load dlls from the directory containing the executable add a loadlibraryex to x sys win so that users can still get at the old behavior if they want it by appropriate passing of flags cl forthcoming cc alexbrainman adg broady jbuberel ianlancetaylor ,0 44168,7094226588.0,IssuesEvent,2018-01-13 00:46:37,golang/go,https://api.github.com/repos/golang/go,closed,dist: one-line installer: additional safety/trust features,Documentation NeedsInvestigation WaitingForInfo,"The one-line installer tracked in https://github.com/golang/go/issues/23381 is something many new and current Go programmers will use, likely downloaded from golang.org. In that issue I mentioned having a sensation of distrust when using the Go 1.10 beta installer, and this issue is to discuss any additional features that may reduce such distrust. My opinion is the valid HTTPS link source is trustworthy enough (I still ran the Go 1.10 beta) and that this issue is a nice to have perception improvement. @broady mentions in the other issue that a GPG signature is provided for all downloads on golang.org already. The sensation of distrust is due to thinking that the features provided in the downloaded binary could be easily replicated by a third party with deconstructive intent. Due to the open source of the tool I'm not sure there's much else that could be done there and the website seems to have just about every necessary security feature, but maybe documentation saying ""only download from golang.org and check for the browser green certificate verification and verify the GPG key this way"" could be part of the tool distribution.",1.0,"dist: one-line installer: additional safety/trust features - The one-line installer tracked in https://github.com/golang/go/issues/23381 is something many new and current Go programmers will use, likely downloaded from golang.org. In that issue I mentioned having a sensation of distrust when using the Go 1.10 beta installer, and this issue is to discuss any additional features that may reduce such distrust. My opinion is the valid HTTPS link source is trustworthy enough (I still ran the Go 1.10 beta) and that this issue is a nice to have perception improvement. @broady mentions in the other issue that a GPG signature is provided for all downloads on golang.org already. The sensation of distrust is due to thinking that the features provided in the downloaded binary could be easily replicated by a third party with deconstructive intent. Due to the open source of the tool I'm not sure there's much else that could be done there and the website seems to have just about every necessary security feature, but maybe documentation saying ""only download from golang.org and check for the browser green certificate verification and verify the GPG key this way"" could be part of the tool distribution.",1,dist one line installer additional safety trust features the one line installer tracked in is something many new and current go programmers will use likely downloaded from golang org in that issue i mentioned having a sensation of distrust when using the go beta installer and this issue is to discuss any additional features that may reduce such distrust my opinion is the valid https link source is trustworthy enough i still ran the go beta and that this issue is a nice to have perception improvement broady mentions in the other issue that a gpg signature is provided for all downloads on golang org already the sensation of distrust is due to thinking that the features provided in the downloaded binary could be easily replicated by a third party with deconstructive intent due to the open source of the tool i m not sure there s much else that could be done there and the website seems to have just about every necessary security feature but maybe documentation saying only download from golang org and check for the browser green certificate verification and verify the gpg key this way could be part of the tool distribution ,1 399607,27247588425.0,IssuesEvent,2023-02-22 04:16:36,golang/go,https://api.github.com/repos/golang/go,closed,"spec: unable to create constraint based upon type parameter: ""type in term ~T cannot be a type parameter""",Documentation," ### What version of Go are you using (`go version`)? 
https://go.dev/play/p/Ztyu2FJaajl
go1.20.1
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Go Playground server ### What did you do? ```go package main type A[T any, U ~T] struct{} type B[T any, U ~T | ~*T] struct{} type C[T any] interface{ ~T | ~*T } func main() {} ``` ### What did you expect to see? no error ### What did you see instead? ``` ./prog.go:3:18: type in term ~T cannot be a type parameter ./prog.go:4:18: type in term ~T cannot be a type parameter ./prog.go:5:27: type in term ~T cannot be a type parameter Go build failed. ``` Too bad Google isn't using numbered sections in the Go spec, that would make it easier to cite precise specification items. So constraints are interfaces and implicitly converted to them using the syntax of the first four examples. The spec states that ""An interface type T may not embed a type element that is, contains, or embeds T, directly or indirectly."" However, we're specifying a type with T as an underlying type. If I read the specification correctly then this should be legal. It's probably a separate issue with the specification that a constraint of `type A[T any, U T | *T] struct{}` is not legal.",1.0,"spec: unable to create constraint based upon type parameter: ""type in term ~T cannot be a type parameter"" - ### What version of Go are you using (`go version`)? 
https://go.dev/play/p/Ztyu2FJaajl
go1.20.1
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Go Playground server ### What did you do? ```go package main type A[T any, U ~T] struct{} type B[T any, U ~T | ~*T] struct{} type C[T any] interface{ ~T | ~*T } func main() {} ``` ### What did you expect to see? no error ### What did you see instead? ``` ./prog.go:3:18: type in term ~T cannot be a type parameter ./prog.go:4:18: type in term ~T cannot be a type parameter ./prog.go:5:27: type in term ~T cannot be a type parameter Go build failed. ``` Too bad Google isn't using numbered sections in the Go spec, that would make it easier to cite precise specification items. So constraints are interfaces and implicitly converted to them using the syntax of the first four examples. The spec states that ""An interface type T may not embed a type element that is, contains, or embeds T, directly or indirectly."" However, we're specifying a type with T as an underlying type. If I read the specification correctly then this should be legal. It's probably a separate issue with the specification that a constraint of `type A[T any, U T | *T] struct{}` is not legal.",1,spec unable to create constraint based upon type parameter type in term t cannot be a type parameter please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go playground server what did you do go package main type a struct type b struct type c interface t t func main what did you expect to see no error what did you see instead prog go type in term t cannot be a type parameter prog go type in term t cannot be a type parameter prog go type in term t cannot be a type parameter go build failed too bad google isn t using numbered sections in the go spec that would make it easier to cite precise specification items so constraints are interfaces and implicitly converted to them using the syntax of the first four examples the spec states that an interface type t may not embed a type element that is contains or embeds t directly or indirectly however we re specifying a type with t as an underlying type if i read the specification correctly then this should be legal it s probably a separate issue with the specification that a constraint of type a struct is not legal ,1 365987,25562770277.0,IssuesEvent,2022-11-30 12:06:32,golang/go,https://api.github.com/repos/golang/go,opened,testing: document the usage of export_test.go ,Documentation,"While I am trying to introduce the usage of `export_test.go` to someone new to Go, I failed to find a document regarding this feature neither in [testing](https://pkg.go.dev/testing) nor in [go command](https://pkg.go.dev/cmd/go@go1.19.3#hdr-Testing_flags), not even in the wiki. I am not sure if I overlooked somewhere, but I would propose documenting this somewhere more visible, such as the [testing](https://pkg.go.dev/testing) package's document. ",1.0,"testing: document the usage of export_test.go - While I am trying to introduce the usage of `export_test.go` to someone new to Go, I failed to find a document regarding this feature neither in [testing](https://pkg.go.dev/testing) nor in [go command](https://pkg.go.dev/cmd/go@go1.19.3#hdr-Testing_flags), not even in the wiki. I am not sure if I overlooked somewhere, but I would propose documenting this somewhere more visible, such as the [testing](https://pkg.go.dev/testing) package's document. ",1,testing document the usage of export test go while i am trying to introduce the usage of export test go to someone new to go i failed to find a document regarding this feature neither in nor in not even in the wiki i am not sure if i overlooked somewhere but i would propose documenting this somewhere more visible such as the package s document ,1 21564,4725397131.0,IssuesEvent,2016-10-18 06:20:16,golang/go,https://api.github.com/repos/golang/go,closed,net/url: url.RawQuery = url.Query().Encode() can change the URL,Documentation,"In the following code: ```go u, _ := url.Parse(""http://www.example.com/path?foo"") fmt.Println(u) u.RawQuery = u.Query().Encode() fmt.Println(u) ``` The third line actually changes the URL. The [output](https://play.golang.org/p/HPRB2NlCq4) is: ``` http://www.example.com/path?foo http://www.example.com/path?foo= ``` A strict reading of [RFC 3986 Section 6](https://tools.ietf.org/html/rfc3986#section-6) suggests that these are two different URLs even after applying the (optional) syntax-based normalizations described in Section 6.2.2. I know of some servers that consider these URLs different. For example, compare the following links: [http://www.vcfed.org/forum/forumdisplay.php?23-DEC](http://www.vcfed.org/forum/forumdisplay.php?23-DEC) [http://www.vcfed.org/forum/forumdisplay.php?23-DEC=](http://www.vcfed.org/forum/forumdisplay.php?23-DEC=) I consider this a bug, but I doubt we could fix this bug in a backwards-compatible way. At least, I think we should update the documentation to make it clear that url.Query().Encode() can change query param ""foo"" to ""foo="", which may be considered a different URL by some servers.",1.0,"net/url: url.RawQuery = url.Query().Encode() can change the URL - In the following code: ```go u, _ := url.Parse(""http://www.example.com/path?foo"") fmt.Println(u) u.RawQuery = u.Query().Encode() fmt.Println(u) ``` The third line actually changes the URL. The [output](https://play.golang.org/p/HPRB2NlCq4) is: ``` http://www.example.com/path?foo http://www.example.com/path?foo= ``` A strict reading of [RFC 3986 Section 6](https://tools.ietf.org/html/rfc3986#section-6) suggests that these are two different URLs even after applying the (optional) syntax-based normalizations described in Section 6.2.2. I know of some servers that consider these URLs different. For example, compare the following links: [http://www.vcfed.org/forum/forumdisplay.php?23-DEC](http://www.vcfed.org/forum/forumdisplay.php?23-DEC) [http://www.vcfed.org/forum/forumdisplay.php?23-DEC=](http://www.vcfed.org/forum/forumdisplay.php?23-DEC=) I consider this a bug, but I doubt we could fix this bug in a backwards-compatible way. At least, I think we should update the documentation to make it clear that url.Query().Encode() can change query param ""foo"" to ""foo="", which may be considered a different URL by some servers.",1,net url url rawquery url query encode can change the url in the following code go u url parse fmt println u u rawquery u query encode fmt println u the third line actually changes the url the is a strict reading of suggests that these are two different urls even after applying the optional syntax based normalizations described in section i know of some servers that consider these urls different for example compare the following links i consider this a bug but i doubt we could fix this bug in a backwards compatible way at least i think we should update the documentation to make it clear that url query encode can change query param foo to foo which may be considered a different url by some servers ,1 24467,12302098557.0,IssuesEvent,2020-05-11 16:24:34,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: optimize division for positive integers,NeedsInvestigation Performance," ### What version of Go are you using (`go version`)? go version go1.13.1 windows/amd64 ### Does this issue reproduce with the latest release? yes ### What did you do? ~~~go func Indent(width int) string { const tabsAndSpaces = ""\t\t\t\t\t\t\t\t\t "" middle := len(tabsAndSpaces) - 7 if width >= 0 && width <= 8*middle+7 { start := middle - width/8 end := middle + width%8 return tabsAndSpaces[start:end] } return strings.Repeat(""\t"", width/8) + "" ""[:width%8] } ~~~ ### What did you expect to see? Since the variable `width` has bounds checks and is thus guaranteed to be positive, the generated code omits the extra instructions for negative numbers. In general, I prefer to write arithmetic expressions in my code instead of bit manipulations because the expressions `width/8` and `width%8` pair up nicely. In contrast, `width>>3` and `width&7` requires more thought. ### What did you see instead? ~~~text util.go:7 MOVQ BX, SI util.go:7 SARQ $0x3f, BX util.go:7 SHRQ $0x3d, BX util.go:7 ADDQ SI, BX util.go:7 SARQ $0x3, BX util.go:8 MOVQ BX, DI util.go:8 SHLQ $0x3, BX util.go:8 SUBQ BX, SI util.go:8 LEAQ 0x9(SI), CX ~~~ The `SARQ` and `SHRQ` are not necessary here.",True,"cmd/compile: optimize division for positive integers - ### What version of Go are you using (`go version`)? go version go1.13.1 windows/amd64 ### Does this issue reproduce with the latest release? yes ### What did you do? ~~~go func Indent(width int) string { const tabsAndSpaces = ""\t\t\t\t\t\t\t\t\t "" middle := len(tabsAndSpaces) - 7 if width >= 0 && width <= 8*middle+7 { start := middle - width/8 end := middle + width%8 return tabsAndSpaces[start:end] } return strings.Repeat(""\t"", width/8) + "" ""[:width%8] } ~~~ ### What did you expect to see? Since the variable `width` has bounds checks and is thus guaranteed to be positive, the generated code omits the extra instructions for negative numbers. In general, I prefer to write arithmetic expressions in my code instead of bit manipulations because the expressions `width/8` and `width%8` pair up nicely. In contrast, `width>>3` and `width&7` requires more thought. ### What did you see instead? ~~~text util.go:7 MOVQ BX, SI util.go:7 SARQ $0x3f, BX util.go:7 SHRQ $0x3d, BX util.go:7 ADDQ SI, BX util.go:7 SARQ $0x3, BX util.go:8 MOVQ BX, DI util.go:8 SHLQ $0x3, BX util.go:8 SUBQ BX, SI util.go:8 LEAQ 0x9(SI), CX ~~~ The `SARQ` and `SHRQ` are not necessary here.",0,cmd compile optimize division for positive integers what version of go are you using go version go version windows does this issue reproduce with the latest release yes what did you do go func indent width int string const tabsandspaces t t t t t t t t t middle len tabsandspaces if width width middle start middle width end middle width return tabsandspaces return strings repeat t width what did you expect to see since the variable width has bounds checks and is thus guaranteed to be positive the generated code omits the extra instructions for negative numbers in general i prefer to write arithmetic expressions in my code instead of bit manipulations because the expressions width and width pair up nicely in contrast width and width requires more thought what did you see instead text util go movq bx si util go sarq bx util go shrq bx util go addq si bx util go sarq bx util go movq bx di util go shlq bx util go subq bx si util go leaq si cx the sarq and shrq are not necessary here ,0 183532,14944063121.0,IssuesEvent,2021-01-26 00:30:58,golang/go,https://api.github.com/repos/golang/go,closed,os: document file descriptor ownership semantics for os.NewFile(),Documentation NeedsFix,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.6 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/vic/.cache/go-build""
GOENV=""/home/vic/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/vic/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/vic/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.15""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.15/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/vic/go/src/github.com/optimyze/prodfiler/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-build483022862=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I am not providing a repro case here, as this is dependent on GC pressure & is intended behavior What I did: I used `os.NewFile` with a file descriptor owned by a different piece of code. To illustrate: ```go func func1(fd uintptr) { myFile := os.NewFile(fd, """") [do some stuff with myFile, like using interfaces that require an io.ReadSeeker] [not closing myFile, not closing fd] } func func2() { fd := getFDFromSomewhere() func1(fd) // code using fd after this is unedefined behavior // Indeed, fd might get closed at any point when `myFile` (in `func1`) gets garbage collected } ``` This seems to be intended behavior because of: https://github.com/golang/go/blob/master/src/os/file_unix.go#L178 The GC behavior is documented on `os.File.Fd()`: https://github.com/golang/go/blob/master/src/os/file_unix.go#L65 ### What did you expect to see? I expected to see a comment on `os.NewFile` warning me that the naked file descriptor can only be used while the returned `os.File` isn't garbage-collected ### What did you see instead? Documentation isn't explicit (unless I was looking at the wrong place?), `os.NewFIle` doesn't mention garbage collection at all. This triggered a difficult-to-reproduce/diagnose bug in my service - I had to go and read the Golang source code to find the root cause. I'll be happy to open a PR to fix the documentation if this issue seems legit. Thanks!",1.0,"os: document file descriptor ownership semantics for os.NewFile() - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.6 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/vic/.cache/go-build""
GOENV=""/home/vic/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/vic/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/vic/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.15""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.15/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/vic/go/src/github.com/optimyze/prodfiler/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-build483022862=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I am not providing a repro case here, as this is dependent on GC pressure & is intended behavior What I did: I used `os.NewFile` with a file descriptor owned by a different piece of code. To illustrate: ```go func func1(fd uintptr) { myFile := os.NewFile(fd, """") [do some stuff with myFile, like using interfaces that require an io.ReadSeeker] [not closing myFile, not closing fd] } func func2() { fd := getFDFromSomewhere() func1(fd) // code using fd after this is unedefined behavior // Indeed, fd might get closed at any point when `myFile` (in `func1`) gets garbage collected } ``` This seems to be intended behavior because of: https://github.com/golang/go/blob/master/src/os/file_unix.go#L178 The GC behavior is documented on `os.File.Fd()`: https://github.com/golang/go/blob/master/src/os/file_unix.go#L65 ### What did you expect to see? I expected to see a comment on `os.NewFile` warning me that the naked file descriptor can only be used while the returned `os.File` isn't garbage-collected ### What did you see instead? Documentation isn't explicit (unless I was looking at the wrong place?), `os.NewFIle` doesn't mention garbage collection at all. This triggered a difficult-to-reproduce/diagnose bug in my service - I had to go and read the Golang source code to find the root cause. I'll be happy to open a PR to fix the documentation if this issue seems legit. Thanks!",1,os document file descriptor ownership semantics for os newfile what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home vic cache go build goenv home vic config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home vic go pkg mod gonoproxy gonosumdb goos linux gopath home vic go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home vic go src github com optimyze prodfiler go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do i am not providing a repro case here as this is dependent on gc pressure is intended behavior what i did i used os newfile with a file descriptor owned by a different piece of code to illustrate go func fd uintptr myfile os newfile fd func fd getfdfromsomewhere fd code using fd after this is unedefined behavior indeed fd might get closed at any point when myfile in gets garbage collected this seems to be intended behavior because of the gc behavior is documented on os file fd what did you expect to see i expected to see a comment on os newfile warning me that the naked file descriptor can only be used while the returned os file isn t garbage collected what did you see instead documentation isn t explicit unless i was looking at the wrong place os newfile doesn t mention garbage collection at all this triggered a difficult to reproduce diagnose bug in my service i had to go and read the golang source code to find the root cause i ll be happy to open a pr to fix the documentation if this issue seems legit thanks ,1 26146,5226057057.0,IssuesEvent,2017-01-27 20:08:35,golang/go,https://api.github.com/repos/golang/go,closed,doc: broken wiki Images in golang/go/wiki/Mobile,Documentation NeedsFix,"I'm reading the Go Mobile docs, and some images is not found * Deploying app bundle https://camo.githubusercontent.com/fbc28cc15ba04a995fe26925658557d8be5565fe/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d696f732d6465706c6f792e706e67 * Xcode project layout with hello.framework https://camo.githubusercontent.com/ca8480d267fa6fba06cd69ddbd7a157083a7dab9/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d696d706f72742d616e64726f696473747564696f2e706e67 * Drag and drop Hello.framework https://camo.githubusercontent.com/4056086ee93aa86233588f92a7e180374d11807d/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d62696e642d696f73647261672e706e67 * Xcode project layout with Hello.framework https://camo.githubusercontent.com/158aaea172021b5c38d1cf2fcccfa39336384a77/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d62696e642d696f732e706e67 Should this be reported here? If I know which image should be there I can send a fix, but as I am a begginer looking for how to start to work with go, I'm not familiar with this documentation yet. ",1.0,"doc: broken wiki Images in golang/go/wiki/Mobile - I'm reading the Go Mobile docs, and some images is not found * Deploying app bundle https://camo.githubusercontent.com/fbc28cc15ba04a995fe26925658557d8be5565fe/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d696f732d6465706c6f792e706e67 * Xcode project layout with hello.framework https://camo.githubusercontent.com/ca8480d267fa6fba06cd69ddbd7a157083a7dab9/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d696d706f72742d616e64726f696473747564696f2e706e67 * Drag and drop Hello.framework https://camo.githubusercontent.com/4056086ee93aa86233588f92a7e180374d11807d/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d62696e642d696f73647261672e706e67 * Xcode project layout with Hello.framework https://camo.githubusercontent.com/158aaea172021b5c38d1cf2fcccfa39336384a77/68747470733a2f2f676f6f676c6564726976652e636f6d2f686f73742f30427966536a64505673394d5a626b686a6555684d597a52546545452f676f77696b692f676f6d6f62696c652d62696e642d696f732e706e67 Should this be reported here? If I know which image should be there I can send a fix, but as I am a begginer looking for how to start to work with go, I'm not familiar with this documentation yet. ",1,doc broken wiki images in golang go wiki mobile i m reading the go mobile docs and some images is not found deploying app bundle xcode project layout with hello framework drag and drop hello framework xcode project layout with hello framework should this be reported here if i know which image should be there i can send a fix but as i am a begginer looking for how to start to work with go i m not familiar with this documentation yet ,1 16156,4020814257.0,IssuesEvent,2016-05-16 19:46:19,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: document that object keys are sorted,Documentation,"If you call json.Marshal with a map, it sorts the keys. If you do a search, you will find a Stack Overflow page explaining this[1]. However, this behavior isn't mentioned in the godoc. It's useful to assume that the emitted JSON will be deterministic, since then you can use string equality or compare hashes to look for duplicates and compare the emitted JSON to a golden copy in tests. But since this property isn't mentioned, it's unclear whether users can rely on the emitted JSON remaining the same in new versions of Go. Many people will do it anyway, so perhaps we should make it official? [1] http://stackoverflow.com/questions/18668652/how-to-produce-json-with-sorted-keys-in-go ",1.0,"encoding/json: document that object keys are sorted - If you call json.Marshal with a map, it sorts the keys. If you do a search, you will find a Stack Overflow page explaining this[1]. However, this behavior isn't mentioned in the godoc. It's useful to assume that the emitted JSON will be deterministic, since then you can use string equality or compare hashes to look for duplicates and compare the emitted JSON to a golden copy in tests. But since this property isn't mentioned, it's unclear whether users can rely on the emitted JSON remaining the same in new versions of Go. Many people will do it anyway, so perhaps we should make it official? [1] http://stackoverflow.com/questions/18668652/how-to-produce-json-with-sorted-keys-in-go ",1,encoding json document that object keys are sorted if you call json marshal with a map it sorts the keys if you do a search you will find a stack overflow page explaining this however this behavior isn t mentioned in the godoc it s useful to assume that the emitted json will be deterministic since then you can use string equality or compare hashes to look for duplicates and compare the emitted json to a golden copy in tests but since this property isn t mentioned it s unclear whether users can rely on the emitted json remaining the same in new versions of go many people will do it anyway so perhaps we should make it official ,1 82086,10269668022.0,IssuesEvent,2019-08-23 09:35:28,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/stringer: document -linecomment in 'go doc stringer',Documentation NeedsFix help wanted,"This proposal is for that the 'stringer' tool gets flexibility at return strings, because the names that it returns are cased as they are in the values defined. ### Problem ``` type systemKind int const ( Windows systemKind = iota MacOS Linux Android Ios ) ``` ``` $ stringer -type systemKind ./test_data/ ``` The names that it generates are `WindowsMacOSLinuxAndroidIos`. But sometimes you want show the name of other way, e.g. ""macOS"" for ""MacOS"" or ""iOS"" for ""Ios"" So, the name given to define a constant has not to be the name wanted to be showed into a string. Also, I would want to get other funcion name to get the string given into a tag string. ### Proposal Using a tag string like `str` to generate an alternative name, and with an optional tag name (e.g. `long`) to generate a funcion where return the string. ``` const ( Windows systemKind = iota MacOS // `str:""macOS""` Linux // `long:""the best system""` Android Ios // `str:""iOS""` ) ``` So the method `(i systemKind) String()` would get `WindowsmacOSLinuxAndroidiOS`. And it would add a second method, e.g. `(systemKind) LongString()` where it would return ""the best system"" for the value `Linux`.",1.0,"x/tools/cmd/stringer: document -linecomment in 'go doc stringer' - This proposal is for that the 'stringer' tool gets flexibility at return strings, because the names that it returns are cased as they are in the values defined. ### Problem ``` type systemKind int const ( Windows systemKind = iota MacOS Linux Android Ios ) ``` ``` $ stringer -type systemKind ./test_data/ ``` The names that it generates are `WindowsMacOSLinuxAndroidIos`. But sometimes you want show the name of other way, e.g. ""macOS"" for ""MacOS"" or ""iOS"" for ""Ios"" So, the name given to define a constant has not to be the name wanted to be showed into a string. Also, I would want to get other funcion name to get the string given into a tag string. ### Proposal Using a tag string like `str` to generate an alternative name, and with an optional tag name (e.g. `long`) to generate a funcion where return the string. ``` const ( Windows systemKind = iota MacOS // `str:""macOS""` Linux // `long:""the best system""` Android Ios // `str:""iOS""` ) ``` So the method `(i systemKind) String()` would get `WindowsmacOSLinuxAndroidiOS`. And it would add a second method, e.g. `(systemKind) LongString()` where it would return ""the best system"" for the value `Linux`.",1,x tools cmd stringer document linecomment in go doc stringer this proposal is for that the stringer tool gets flexibility at return strings because the names that it returns are cased as they are in the values defined problem type systemkind int const windows systemkind iota macos linux android ios stringer type systemkind test data the names that it generates are windowsmacoslinuxandroidios but sometimes you want show the name of other way e g macos for macos or ios for ios so the name given to define a constant has not to be the name wanted to be showed into a string also i would want to get other funcion name to get the string given into a tag string proposal using a tag string like str to generate an alternative name and with an optional tag name e g long to generate a funcion where return the string const windows systemkind iota macos str macos linux long the best system android ios str ios so the method i systemkind string would get windowsmacoslinuxandroidios and it would add a second method e g systemkind longstring where it would return the best system for the value linux ,1 237645,19662790431.0,IssuesEvent,2022-01-10 18:50:07,golang/go,https://api.github.com/repos/golang/go,closed,x/vulndb/internal/worker: tests failing on Android builders since CL 375716 due to missing cvelistrepo testdata,Testing NeedsFix release-blocker mobile,"``` --- FAIL: TestDoUpdate (0.00s) update_test.go:73: readTxtarRepo(""../cvelistrepo/testdata/basic.txtar""): open ../cvelistrepo/testdata/basic.txtar: no such file or directory --- FAIL: TestCheckUpdate (0.00s) worker_test.go:31: readTxtarRepo(""../cvelistrepo/testdata/basic.txtar""): open ../cvelistrepo/testdata/basic.txtar: no such file or directory 2022/01/06 16:35:32 INFO CreateIssues starting; destination: in memory, total needing issue: 1 2022/01/06 16:35:32 INFO created issue inMemory#1 for ID1 CVE=ID1 2022/01/06 16:35:32 INFO CreateIssues done: 1 created limit=0 FAIL exitcode=1 FAIL golang.org/x/vulndb/internal/worker 1.259s ``` `greplogs --dashboard -md -l -e 'open \.\./cvelistrepo/testdata.*: no such file or directory' --since=2021-12-01`
[2022-01-06T15:00:16-5ec67cc-da7891f/android-386-emu](https://build.golang.org/log/630ec2012e168bdaca481f331501ccb7f4609dfb) [2022-01-06T15:00:16-5ec67cc-da7891f/android-amd64-emu](https://build.golang.org/log/02be7e04ea884752a6ba36feef62ccce330a8360) [2022-01-06T14:02:44-5ec67cc-f300fc2/android-386-emu](https://build.golang.org/log/a47cc47a4e06de519de5128fc793382af86d66ef) [2022-01-06T14:02:44-5ec67cc-f300fc2/android-amd64-emu](https://build.golang.org/log/bd481cb59b163c2e9239960f77717071d5aec34b) [2022-01-06T00:26:47-5ec67cc-b5bfaf4/android-386-emu](https://build.golang.org/log/2bb33c9a1fce257323afa6cf4ac942823c2acf79) [2022-01-06T00:26:47-5ec67cc-b5bfaf4/android-amd64-emu](https://build.golang.org/log/9e2c6f8ca56c8a552e2a2f19922196bda9e4bfad) [2022-01-05T23:58:13-5ec67cc-ab70d7c/android-386-emu](https://build.golang.org/log/b68405c2c44f714a1205f61ba462822b9a031b52) [2022-01-05T23:58:13-5ec67cc-ab70d7c/android-amd64-emu](https://build.golang.org/log/9ae6803b21b6ac23d9f560574700640f7cd8240b) [2022-01-05T23:58:13-5ec67cc-2b39d86/android-386-emu](https://build.golang.org/log/aea3464e42744935cb90987e467371ac158d2076) [2022-01-05T23:58:13-5ec67cc-2b39d86/android-amd64-emu](https://build.golang.org/log/da9ef7bdc0e3a3baa9d0c040304f2a8dc47ae78a) [2022-01-05T23:58:01-1250886-ab70d7c/android-386-emu](https://build.golang.org/log/b16026be1478c81b3d8eb5d07bca28ca392477e6) [2022-01-05T23:58:01-1250886-ab70d7c/android-amd64-emu](https://build.golang.org/log/91ed31b14387da33beb3a81b2bdb669f96c452d9) [2022-01-05T23:58:01-1250886-2b39d86/android-386-emu](https://build.golang.org/log/74f5899803a3859a50d4a83187e43d1c4d77934b) [2022-01-05T23:58:01-1250886-2b39d86/android-amd64-emu](https://build.golang.org/log/3dcf4b8d1b2f3b77987616b7556e1419f90e7342)
",1.0,"x/vulndb/internal/worker: tests failing on Android builders since CL 375716 due to missing cvelistrepo testdata - ``` --- FAIL: TestDoUpdate (0.00s) update_test.go:73: readTxtarRepo(""../cvelistrepo/testdata/basic.txtar""): open ../cvelistrepo/testdata/basic.txtar: no such file or directory --- FAIL: TestCheckUpdate (0.00s) worker_test.go:31: readTxtarRepo(""../cvelistrepo/testdata/basic.txtar""): open ../cvelistrepo/testdata/basic.txtar: no such file or directory 2022/01/06 16:35:32 INFO CreateIssues starting; destination: in memory, total needing issue: 1 2022/01/06 16:35:32 INFO created issue inMemory#1 for ID1 CVE=ID1 2022/01/06 16:35:32 INFO CreateIssues done: 1 created limit=0 FAIL exitcode=1 FAIL golang.org/x/vulndb/internal/worker 1.259s ``` `greplogs --dashboard -md -l -e 'open \.\./cvelistrepo/testdata.*: no such file or directory' --since=2021-12-01`
[2022-01-06T15:00:16-5ec67cc-da7891f/android-386-emu](https://build.golang.org/log/630ec2012e168bdaca481f331501ccb7f4609dfb) [2022-01-06T15:00:16-5ec67cc-da7891f/android-amd64-emu](https://build.golang.org/log/02be7e04ea884752a6ba36feef62ccce330a8360) [2022-01-06T14:02:44-5ec67cc-f300fc2/android-386-emu](https://build.golang.org/log/a47cc47a4e06de519de5128fc793382af86d66ef) [2022-01-06T14:02:44-5ec67cc-f300fc2/android-amd64-emu](https://build.golang.org/log/bd481cb59b163c2e9239960f77717071d5aec34b) [2022-01-06T00:26:47-5ec67cc-b5bfaf4/android-386-emu](https://build.golang.org/log/2bb33c9a1fce257323afa6cf4ac942823c2acf79) [2022-01-06T00:26:47-5ec67cc-b5bfaf4/android-amd64-emu](https://build.golang.org/log/9e2c6f8ca56c8a552e2a2f19922196bda9e4bfad) [2022-01-05T23:58:13-5ec67cc-ab70d7c/android-386-emu](https://build.golang.org/log/b68405c2c44f714a1205f61ba462822b9a031b52) [2022-01-05T23:58:13-5ec67cc-ab70d7c/android-amd64-emu](https://build.golang.org/log/9ae6803b21b6ac23d9f560574700640f7cd8240b) [2022-01-05T23:58:13-5ec67cc-2b39d86/android-386-emu](https://build.golang.org/log/aea3464e42744935cb90987e467371ac158d2076) [2022-01-05T23:58:13-5ec67cc-2b39d86/android-amd64-emu](https://build.golang.org/log/da9ef7bdc0e3a3baa9d0c040304f2a8dc47ae78a) [2022-01-05T23:58:01-1250886-ab70d7c/android-386-emu](https://build.golang.org/log/b16026be1478c81b3d8eb5d07bca28ca392477e6) [2022-01-05T23:58:01-1250886-ab70d7c/android-amd64-emu](https://build.golang.org/log/91ed31b14387da33beb3a81b2bdb669f96c452d9) [2022-01-05T23:58:01-1250886-2b39d86/android-386-emu](https://build.golang.org/log/74f5899803a3859a50d4a83187e43d1c4d77934b) [2022-01-05T23:58:01-1250886-2b39d86/android-amd64-emu](https://build.golang.org/log/3dcf4b8d1b2f3b77987616b7556e1419f90e7342)
",0,x vulndb internal worker tests failing on android builders since cl due to missing cvelistrepo testdata fail testdoupdate update test go readtxtarrepo cvelistrepo testdata basic txtar open cvelistrepo testdata basic txtar no such file or directory fail testcheckupdate worker test go readtxtarrepo cvelistrepo testdata basic txtar open cvelistrepo testdata basic txtar no such file or directory info createissues starting destination in memory total needing issue info created issue inmemory for cve info createissues done created limit fail exitcode fail golang org x vulndb internal worker greplogs dashboard md l e open cvelistrepo testdata no such file or directory since ,0 50568,12522585344.0,IssuesEvent,2020-06-03 19:27:07,golang/go,https://api.github.com/repos/golang/go,opened,x/build/cmd/release: 8 targets are not passing tests successfully on master branch,Builders NeedsInvestigation release-blocker,"The `release` command is used by `releasebot` to build targets. In the first stage (-mode=prepare), it runs tests. In second stage, it skips tests. `release` supports 12 normal targets (not counting new optional longtest-only targets; ignore those for now), see [here](https://github.com/golang/build/blob/6b5029f2f0a732eb990c3ee5f4149483eab22d9a/cmd/releasebot/main.go#L41-L55). These targets are passing tests (they run successfully without `-skip_tests` flag given to `release`) on a recent `master` commit (e.g., 09e791feb1dfbfc05578a17cd9c035ef82af4033): - src - linux-armv6l - linux-ppc64le - linux-s390x These are not passing: - darwin-amd64 - blocked on TODO - freebsd-386 - blocked on TODO - freebsd-amd64 - blocked on TODO - linux-386 - blocked on TODO - linux-amd64 - blocked on #39385 (and more, TODO) - linux-arm64 - blocked on TODO - windows-386 - blocked on TODO - windows-amd64 - blocked on TODO Each one can be reproduced if your account has permissions needed to run `releasebot` (they are documented at https://github.com/golang/build/tree/master/cmd/releasebot#permissions) with: ``` $ release -target= -version=go1.15beta1 -watch -rev=09e791feb1dfbfc05578a17cd9c035ef82af4033 ``` (The `release` command creates a tarball and places it in a temporary staging directory; it doesn't publish anything, so it is safe to run as shown above.) See #39385 as an example of a specific test that is failing. This is the high-level tracking issue for the entire problem. Next, I'll be updating it and splitting into smaller, distinct failures that can be investigated independently. This issue requires investigation. The problem is either in how the `release` command sets up the environment and executes commands on the target builder, or in the builder definition, or in the test, or some combination. Depending on what we learn, we may end up deciding this is okay to resolve after beta1 (but before the final release) and skip these test failures in order to make the Go 1.15 beta 1 available for testing and finding unknown issues sooner.",1.0,"x/build/cmd/release: 8 targets are not passing tests successfully on master branch - The `release` command is used by `releasebot` to build targets. In the first stage (-mode=prepare), it runs tests. In second stage, it skips tests. `release` supports 12 normal targets (not counting new optional longtest-only targets; ignore those for now), see [here](https://github.com/golang/build/blob/6b5029f2f0a732eb990c3ee5f4149483eab22d9a/cmd/releasebot/main.go#L41-L55). These targets are passing tests (they run successfully without `-skip_tests` flag given to `release`) on a recent `master` commit (e.g., 09e791feb1dfbfc05578a17cd9c035ef82af4033): - src - linux-armv6l - linux-ppc64le - linux-s390x These are not passing: - darwin-amd64 - blocked on TODO - freebsd-386 - blocked on TODO - freebsd-amd64 - blocked on TODO - linux-386 - blocked on TODO - linux-amd64 - blocked on #39385 (and more, TODO) - linux-arm64 - blocked on TODO - windows-386 - blocked on TODO - windows-amd64 - blocked on TODO Each one can be reproduced if your account has permissions needed to run `releasebot` (they are documented at https://github.com/golang/build/tree/master/cmd/releasebot#permissions) with: ``` $ release -target= -version=go1.15beta1 -watch -rev=09e791feb1dfbfc05578a17cd9c035ef82af4033 ``` (The `release` command creates a tarball and places it in a temporary staging directory; it doesn't publish anything, so it is safe to run as shown above.) See #39385 as an example of a specific test that is failing. This is the high-level tracking issue for the entire problem. Next, I'll be updating it and splitting into smaller, distinct failures that can be investigated independently. This issue requires investigation. The problem is either in how the `release` command sets up the environment and executes commands on the target builder, or in the builder definition, or in the test, or some combination. Depending on what we learn, we may end up deciding this is okay to resolve after beta1 (but before the final release) and skip these test failures in order to make the Go 1.15 beta 1 available for testing and finding unknown issues sooner.",0,x build cmd release targets are not passing tests successfully on master branch the release command is used by releasebot to build targets in the first stage mode prepare it runs tests in second stage it skips tests release supports normal targets not counting new optional longtest only targets ignore those for now see these targets are passing tests they run successfully without skip tests flag given to release on a recent master commit e g src linux linux linux these are not passing darwin blocked on todo freebsd blocked on todo freebsd blocked on todo linux blocked on todo linux blocked on and more todo linux blocked on todo windows blocked on todo windows blocked on todo each one can be reproduced if your account has permissions needed to run releasebot they are documented at with release target version watch rev the release command creates a tarball and places it in a temporary staging directory it doesn t publish anything so it is safe to run as shown above see as an example of a specific test that is failing this is the high level tracking issue for the entire problem next i ll be updating it and splitting into smaller distinct failures that can be investigated independently this issue requires investigation the problem is either in how the release command sets up the environment and executes commands on the target builder or in the builder definition or in the test or some combination depending on what we learn we may end up deciding this is okay to resolve after but before the final release and skip these test failures in order to make the go beta available for testing and finding unknown issues sooner ,0 226184,17315474220.0,IssuesEvent,2021-07-27 05:08:31,golang/go,https://api.github.com/repos/golang/go,closed,testing: unclear if T.Name includes sub-tests as part of its string,Documentation NeedsFix help wanted,"The current docs say: > Name returns the name of the running test or benchmark. For a `func TestFoo(t *testing.T)`, I think it's reasonably clear that Name will be `TestFoo`. However, for a sub-test like `t.Run(""Bar"", ...)`, it's not clear from the documentation if Name will return `TestFoo/Bar` or just `TestFoo`. Another open question is whether the name will be altered, just like it is when printing output. For example, `t.Run(""bar baz"", ...)` ends up printing `TestFoo/bar_baz` in the terminal, so if the subtest name is included in the Name method, I'm not sure which of the two I'd expect. cc @mpvl as per the owners doc cc @adg @bradfitz since they added the Name method",1.0,"testing: unclear if T.Name includes sub-tests as part of its string - The current docs say: > Name returns the name of the running test or benchmark. For a `func TestFoo(t *testing.T)`, I think it's reasonably clear that Name will be `TestFoo`. However, for a sub-test like `t.Run(""Bar"", ...)`, it's not clear from the documentation if Name will return `TestFoo/Bar` or just `TestFoo`. Another open question is whether the name will be altered, just like it is when printing output. For example, `t.Run(""bar baz"", ...)` ends up printing `TestFoo/bar_baz` in the terminal, so if the subtest name is included in the Name method, I'm not sure which of the two I'd expect. cc @mpvl as per the owners doc cc @adg @bradfitz since they added the Name method",1,testing unclear if t name includes sub tests as part of its string the current docs say name returns the name of the running test or benchmark for a func testfoo t testing t i think it s reasonably clear that name will be testfoo however for a sub test like t run bar it s not clear from the documentation if name will return testfoo bar or just testfoo another open question is whether the name will be altered just like it is when printing output for example t run bar baz ends up printing testfoo bar baz in the terminal so if the subtest name is included in the name method i m not sure which of the two i d expect cc mpvl as per the owners doc cc adg bradfitz since they added the name method,1 71632,9531775812.0,IssuesEvent,2019-04-29 16:50:43,golang/go,https://api.github.com/repos/golang/go,closed,net: incorrect docs on KeepAlive field of Dialer,Documentation NeedsFix help wanted," ### What version of Go are you using (`go version`)? tip ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? doesn't matter ### What did you do? Run ""go doc net Dialer"" and took a look at the output ### What did you expect to see? At least the docs introduced by #23459 never uses the phrase ""keep-alive period"" because the existing implementation tries to tweak the keepalive idle and probe intervals, not the entire keepalive period. ### What did you see instead?` ``` // KeepAlive specifies the keep-alive period for an active // network connection. // If zero, keep-alives are enabled if supported by the protocol // and operating system. Network protocols or operating systems // that do not support keep-alives ignore this field. // If negative, keep-alives are disabled. KeepAlive time.Duration ``` FWIW, SetKeepAlivePeriod on TCPConn says: ``` // SetKeepAlivePeriod sets period between keep alives. func (c *TCPConn) SetKeepAlivePeriod(d time.Duration) error { ```",1.0,"net: incorrect docs on KeepAlive field of Dialer - ### What version of Go are you using (`go version`)? tip ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? doesn't matter ### What did you do? Run ""go doc net Dialer"" and took a look at the output ### What did you expect to see? At least the docs introduced by #23459 never uses the phrase ""keep-alive period"" because the existing implementation tries to tweak the keepalive idle and probe intervals, not the entire keepalive period. ### What did you see instead?` ``` // KeepAlive specifies the keep-alive period for an active // network connection. // If zero, keep-alives are enabled if supported by the protocol // and operating system. Network protocols or operating systems // that do not support keep-alives ignore this field. // If negative, keep-alives are disabled. KeepAlive time.Duration ``` FWIW, SetKeepAlivePeriod on TCPConn says: ``` // SetKeepAlivePeriod sets period between keep alives. func (c *TCPConn) SetKeepAlivePeriod(d time.Duration) error { ```",1,net incorrect docs on keepalive field of dialer what version of go are you using go version tip does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env doesn t matter 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 run go doc net dialer and took a look at the output what did you expect to see at least the docs introduced by never uses the phrase keep alive period because the existing implementation tries to tweak the keepalive idle and probe intervals not the entire keepalive period what did you see instead keepalive specifies the keep alive period for an active network connection if zero keep alives are enabled if supported by the protocol and operating system network protocols or operating systems that do not support keep alives ignore this field if negative keep alives are disabled keepalive time duration fwiw setkeepaliveperiod on tcpconn says setkeepaliveperiod sets period between keep alives func c tcpconn setkeepaliveperiod d time duration error ,1 33831,6263943490.0,IssuesEvent,2017-07-16 01:44:13,golang/go,https://api.github.com/repos/golang/go,closed,go/ast: CommentMap example does not compile,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/ritesh/code/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5x/m5n_f_wj6fngljvf9g7y3mp4qphpn9/T/go-build111820297=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ### What did you do? Tried to run the example in https://golang.org/pkg/go/ast/#example_CommentMap. A link to the full program, with imports, is here: https://play.golang.org/p/5DA91qtnm4 ### What did you expect to see? Expected the example to run, without any errors. ### What did you see instead? tmp/sandbox659516205/main.go:44: undefined: removeFirstVarDecl ",1.0,"go/ast: CommentMap example does not compile - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/ritesh/code/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5x/m5n_f_wj6fngljvf9g7y3mp4qphpn9/T/go-build111820297=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ### What did you do? Tried to run the example in https://golang.org/pkg/go/ast/#example_CommentMap. A link to the full program, with imports, is here: https://play.golang.org/p/5DA91qtnm4 ### What did you expect to see? Expected the example to run, without any errors. ### What did you see instead? tmp/sandbox659516205/main.go:44: undefined: removeFirstVarDecl ",1,go ast commentmap example does not compile please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users ritesh code go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders f t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do tried to run the example in a link to the full program with imports is here what did you expect to see expected the example to run without any errors what did you see instead tmp main go undefined removefirstvardecl ,1 174045,14445062248.0,IssuesEvent,2020-12-07 22:17:12,golang/go,https://api.github.com/repos/golang/go,closed,reflect: update StructTag documentation to describe multiple space-separated keys,Documentation NeedsFix okay-after-beta1 release-blocker,"Proposal #40281 was accepted and implemented for Go 1.16 in [CL 248341](https://golang.org/cl/248341). It seems the public documentation of [`reflect.StructTag`](https://tip.golang.org/pkg/reflect/#StructTag) was not updated as part of the implementation. It still says: > Each key is a non-empty string consisting of non-control characters other than space (U+0020 ' '), quote (U+0022 '""'), and colon (U+003A ':'). That is no longer accurate/complete. It needs to be updated to describe the new behavior. CC @bynov, @deven96, @rsc, @ianlancetaylor.",1.0,"reflect: update StructTag documentation to describe multiple space-separated keys - Proposal #40281 was accepted and implemented for Go 1.16 in [CL 248341](https://golang.org/cl/248341). It seems the public documentation of [`reflect.StructTag`](https://tip.golang.org/pkg/reflect/#StructTag) was not updated as part of the implementation. It still says: > Each key is a non-empty string consisting of non-control characters other than space (U+0020 ' '), quote (U+0022 '""'), and colon (U+003A ':'). That is no longer accurate/complete. It needs to be updated to describe the new behavior. CC @bynov, @deven96, @rsc, @ianlancetaylor.",1,reflect update structtag documentation to describe multiple space separated keys proposal was accepted and implemented for go in it seems the public documentation of was not updated as part of the implementation it still says each key is a non empty string consisting of non control characters other than space u quote u and colon u that is no longer accurate complete it needs to be updated to describe the new behavior cc bynov rsc ianlancetaylor ,1 73559,9670579630.0,IssuesEvent,2019-05-21 20:16:47,golang/go,https://api.github.com/repos/golang/go,closed,"math/bits: guarantee Add, Sub, Mul, RotateLeft, ReverseBytes to be constant-time operations",Documentation NeedsFix Proposal Proposal-Accepted,"I'm a heavy non-crypto user of `bits.*` and I'm afraid changes like #31229 will effect my performance. One way of keeping crypto people happy and users like me would be to have separate functions for both non-constant time and constant time addition, multiplication, ... In the issue above I was reminded that the change affects only the fallbacks. I'm afraid promising that the fallbacks are constant time will later lead to constant time native implementations which could very well be slower than their non-constant time alternatives. For example, platforms which don't support carry flag are RISC-V and WebAssembly and it could happened that ""a branch works out better"" [1]. [1] https://gmplib.org/manual/Assembly-Carry-Propagation.html",1.0,"math/bits: guarantee Add, Sub, Mul, RotateLeft, ReverseBytes to be constant-time operations - I'm a heavy non-crypto user of `bits.*` and I'm afraid changes like #31229 will effect my performance. One way of keeping crypto people happy and users like me would be to have separate functions for both non-constant time and constant time addition, multiplication, ... In the issue above I was reminded that the change affects only the fallbacks. I'm afraid promising that the fallbacks are constant time will later lead to constant time native implementations which could very well be slower than their non-constant time alternatives. For example, platforms which don't support carry flag are RISC-V and WebAssembly and it could happened that ""a branch works out better"" [1]. [1] https://gmplib.org/manual/Assembly-Carry-Propagation.html",1,math bits guarantee add sub mul rotateleft reversebytes to be constant time operations i m a heavy non crypto user of bits and i m afraid changes like will effect my performance one way of keeping crypto people happy and users like me would be to have separate functions for both non constant time and constant time addition multiplication in the issue above i was reminded that the change affects only the fallbacks i m afraid promising that the fallbacks are constant time will later lead to constant time native implementations which could very well be slower than their non constant time alternatives for example platforms which don t support carry flag are risc v and webassembly and it could happened that a branch works out better ,1 130078,10596123060.0,IssuesEvent,2019-10-09 20:31:22,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: all.bash test failure in the terminal test from commit 1fba10c999,NeedsInvestigation Soon Testing release-blocker,"### What version of Go are you using (`go version`)? 
$ go version
go version devel +1fba10c999 Wed Oct 9 15:07:29 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? No. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/homes/hawklords/cks/.cache/go-build""
GOENV=""/homes/hawklords/cks/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/homes/hawklords/cks/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/data/code/go-lang/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/data/code/go-lang/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/data/code/go-lang/go/src/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=/tmpfs/go-build183007954=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Starting with commit 1fba10c999 (which is to fix issue #29062), running `all.bash` in a terminal causes the TestIsTerminal test to fail: ```` $ ./all.bash [...] ##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick ok runtime 9.289s ##### cmd/go terminal test --- FAIL: TestIsTerminal (0.00s) terminal_test.go:34: stdout is not a terminal terminal_test.go:37: stderr is not a terminal FAIL exit status 1 FAIL cmd/go/testdata/testterminal18153 0.001s 2019/10/09 11:54:08 Failed: exit status 1 ```` Running `all.bash` in a context where it doesn't have a terminal (pty) available causes this test to be skipped, resulting in no failure, which may be why the builders aren't picking up on this test failure.",1.0,"cmd/go: all.bash test failure in the terminal test from commit 1fba10c999 - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +1fba10c999 Wed Oct 9 15:07:29 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? No. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/homes/hawklords/cks/.cache/go-build""
GOENV=""/homes/hawklords/cks/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/homes/hawklords/cks/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/data/code/go-lang/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/data/code/go-lang/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/data/code/go-lang/go/src/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=/tmpfs/go-build183007954=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Starting with commit 1fba10c999 (which is to fix issue #29062), running `all.bash` in a terminal causes the TestIsTerminal test to fail: ```` $ ./all.bash [...] ##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick ok runtime 9.289s ##### cmd/go terminal test --- FAIL: TestIsTerminal (0.00s) terminal_test.go:34: stdout is not a terminal terminal_test.go:37: stderr is not a terminal FAIL exit status 1 FAIL cmd/go/testdata/testterminal18153 0.001s 2019/10/09 11:54:08 Failed: exit status 1 ```` Running `all.bash` in a context where it doesn't have a terminal (pty) available causes this test to be skipped, resulting in no failure, which may be why the builders aren't picking up on this test failure.",0,cmd go all bash test failure in the terminal test from commit what version of go are you using go version go version go version devel wed oct linux does this issue reproduce with the latest release no what operating system and processor architecture are you using go env go env output go env goarch gobin gocache homes hawklords cks cache go build goenv homes hawklords cks config go env goexe goflags gohostarch gohostos linux gonoproxy gonosumdb goos linux gopath homes hawklords cks go goprivate goproxy goroot data code go lang go gosumdb sum golang org gotmpdir gotooldir data code go lang go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod data code go lang go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmpfs go tmp go build gno record gcc switches what did you do starting with commit which is to fix issue running all bash in a terminal causes the testisterminal test to fail all bash gomaxprocs runtime cpu quick ok runtime cmd go terminal test fail testisterminal terminal test go stdout is not a terminal terminal test go stderr is not a terminal fail exit status fail cmd go testdata failed exit status running all bash in a context where it doesn t have a terminal pty available causes this test to be skipped resulting in no failure which may be why the builders aren t picking up on this test failure ,0 182162,14901663565.0,IssuesEvent,2021-01-21 16:42:50,golang/go,https://api.github.com/repos/golang/go,closed,x/blog:Only direct dependencies are recorded in the go.mod file: needs a recheck.,Documentation WaitingForInfo," ### What version of Go are you using (`go version`)? 
$ 1.15.6 darwin/amd64
### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ N/A
### What did you do? cat go. mod ### What did you expect to see? Only direct dependencies ### What did you see instead? Both direct and indirect dependency. ### Update the go blog Udert the Sub-heading ""Adding a dependency"", I think the statement ""Only direct dependencies are recorded in the go.mod file"" is misleading or contradictory. A better explanation should be found for this. Thanks.",1.0,"x/blog:Only direct dependencies are recorded in the go.mod file: needs a recheck. - ### What version of Go are you using (`go version`)? 
$ 1.15.6 darwin/amd64
### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ N/A
### What did you do? cat go. mod ### What did you expect to see? Only direct dependencies ### What did you see instead? Both direct and indirect dependency. ### Update the go blog Udert the Sub-heading ""Adding a dependency"", I think the statement ""Only direct dependencies are recorded in the go.mod file"" is misleading or contradictory. A better explanation should be found for this. Thanks.",1,x blog only direct dependencies are recorded in the go mod file needs a recheck please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version darwin does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env go env output n a what did you do cat go mod if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see only direct dependencies what did you see instead both direct and indirect dependency update the go blog udert the sub heading adding a dependency i think the statement only direct dependencies are recorded in the go mod file is misleading or contradictory a better explanation should be found for this thanks ,1 21895,4757258989.0,IssuesEvent,2016-10-24 16:05:41,golang/go,https://api.github.com/repos/golang/go,closed,doc: FAQ states copies of an interface results in copies of underlying data.,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.7 ### What operating system and processor architecture are you using (`go env`)? nacl amd64p32 (go playground https://play.golang.org/p/BRJAYJccog) ### What did you do? The FAQ states that ""Copying an interface value makes a copy of the thing stored in the interface value. If the interface value holds a struct, copying the interface value makes a copy of the struct."" After having been told that this was wrong on the #go-nuts irc, I did some testing, and discovered that while a copy is made when the interface value is first ""created"", from then on further copies of the interface value retain the same underlying struct. Example playground: https://play.golang.org/p/s0A35084oY To my mind this is an understandable change, as it is pretty much impossible to change the underlying struct without the use of the unsafe package. The main issue is that this leaves the FAQ at https://golang.org/doc/faq#pass_by_value out of date, so I am requesting that the FAQ be updated. ### What did you expect to see? Expected to see the ""copies"" of the interface value to have different ""value"" pointers. ### What did you see instead? All copies of the interface value have the same ""value"" pointer, while obviously being copies due to different addresses. ",1.0,"doc: FAQ states copies of an interface results in copies of underlying data. - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.7 ### What operating system and processor architecture are you using (`go env`)? nacl amd64p32 (go playground https://play.golang.org/p/BRJAYJccog) ### What did you do? The FAQ states that ""Copying an interface value makes a copy of the thing stored in the interface value. If the interface value holds a struct, copying the interface value makes a copy of the struct."" After having been told that this was wrong on the #go-nuts irc, I did some testing, and discovered that while a copy is made when the interface value is first ""created"", from then on further copies of the interface value retain the same underlying struct. Example playground: https://play.golang.org/p/s0A35084oY To my mind this is an understandable change, as it is pretty much impossible to change the underlying struct without the use of the unsafe package. The main issue is that this leaves the FAQ at https://golang.org/doc/faq#pass_by_value out of date, so I am requesting that the FAQ be updated. ### What did you expect to see? Expected to see the ""copies"" of the interface value to have different ""value"" pointers. ### What did you see instead? All copies of the interface value have the same ""value"" pointer, while obviously being copies due to different addresses. ",1,doc faq states copies of an interface results in copies of underlying data please answer these questions before submitting your issue thanks what version of go are you using go version what operating system and processor architecture are you using go env nacl go playground what did you do the faq states that copying an interface value makes a copy of the thing stored in the interface value if the interface value holds a struct copying the interface value makes a copy of the struct after having been told that this was wrong on the go nuts irc i did some testing and discovered that while a copy is made when the interface value is first created from then on further copies of the interface value retain the same underlying struct example playground to my mind this is an understandable change as it is pretty much impossible to change the underlying struct without the use of the unsafe package the main issue is that this leaves the faq at out of date so i am requesting that the faq be updated what did you expect to see expected to see the copies of the interface value to have different value pointers what did you see instead all copies of the interface value have the same value pointer while obviously being copies due to different addresses ,1 81458,10238938901.0,IssuesEvent,2019-08-19 17:00:58,golang/go,https://api.github.com/repos/golang/go,opened,"doc/go1.13: missing note about ""go build -o"" directory targets",Documentation NeedsFix release-blocker,"In b48bda9 (#14295) `go build -o` was made to accept directory targets, and to build multiple binaries in that case. The behavior was updated in 081bc62 (#31296). This is still described in `gotip help build`. > The -o flag forces build to write the resulting executable or object to the named output file or directory, instead of the default behavior described in the last two paragraphs. If the named output is a directory that exists, then any resulting executables will be written to that directory. This is missing from the release notes AFAICT.",1.0,"doc/go1.13: missing note about ""go build -o"" directory targets - In b48bda9 (#14295) `go build -o` was made to accept directory targets, and to build multiple binaries in that case. The behavior was updated in 081bc62 (#31296). This is still described in `gotip help build`. > The -o flag forces build to write the resulting executable or object to the named output file or directory, instead of the default behavior described in the last two paragraphs. If the named output is a directory that exists, then any resulting executables will be written to that directory. This is missing from the release notes AFAICT.",1,doc missing note about go build o directory targets in go build o was made to accept directory targets and to build multiple binaries in that case the behavior was updated in this is still described in gotip help build the o flag forces build to write the resulting executable or object to the named output file or directory instead of the default behavior described in the last two paragraphs if the named output is a directory that exists then any resulting executables will be written to that directory this is missing from the release notes afaict ,1 32074,6029119750.0,IssuesEvent,2017-06-08 17:16:09,golang/go,https://api.github.com/repos/golang/go,closed,bufio: Reader.WriteTo documentation should clarify that multiple calls to the upstream Reader may be made,Documentation,"I am unsure if this is intended behavior (in which case this is a documentation problem), or a bug (in which case it may be a bug and a documentation problem :) ). Please advise (or perhaps it's neither, of course); I have patches for both I can submit. ### What version of Go are you using (`go version`)? go version devel +d2fea0447f Tue Feb 14 19:44:35 2017 +0000 linux/amd64 ### What did you do? * Create a `net.Conn` that receives some bytes on the first call to Read, and then holds the connection open (so that you do not receive an io.EOF from a call to Read). * Now wrap it in a `bufio.Reader`. * Call `io.Copy` on the new buffered reader and copy it somewhere else (into a bytes.Buffer, for example). ### What did you expect to see? I expected the bufio.Reader's `WriteTo` method to be called, proxy a single call to `conn.Read`, write that data, and then return. ### What did you see instead? Instead, it attempts to call `conn.Read` a second time (the behavior is to read until EOF or an error is returned). This may not be an issue; the documentation for [`io.WriterTo`](https://godoc.org/io#WriterTo) says: > WriteTo writes data to w until there's no more data to write or when an error occurs. However, it is unclear to me if ""no more data to write"" means ""until EOF"" in the case of the `bufio.Reader` implementation, or if it means ""the buffer was flushed"" or, if the buffer was empty, ""a successful proxied read call had the read data written"". Personally I expected this to call Read at most once, much like the bufio.Reader's Read method. I think that this behavior should either be changed to not use `fill()` (and I am happy to make this change), or the documentation should explicitly say that `bufio.Reader`'s `WriteTo` method writes until EOF or an error is returned from an upstream Read call. ",1.0,"bufio: Reader.WriteTo documentation should clarify that multiple calls to the upstream Reader may be made - I am unsure if this is intended behavior (in which case this is a documentation problem), or a bug (in which case it may be a bug and a documentation problem :) ). Please advise (or perhaps it's neither, of course); I have patches for both I can submit. ### What version of Go are you using (`go version`)? go version devel +d2fea0447f Tue Feb 14 19:44:35 2017 +0000 linux/amd64 ### What did you do? * Create a `net.Conn` that receives some bytes on the first call to Read, and then holds the connection open (so that you do not receive an io.EOF from a call to Read). * Now wrap it in a `bufio.Reader`. * Call `io.Copy` on the new buffered reader and copy it somewhere else (into a bytes.Buffer, for example). ### What did you expect to see? I expected the bufio.Reader's `WriteTo` method to be called, proxy a single call to `conn.Read`, write that data, and then return. ### What did you see instead? Instead, it attempts to call `conn.Read` a second time (the behavior is to read until EOF or an error is returned). This may not be an issue; the documentation for [`io.WriterTo`](https://godoc.org/io#WriterTo) says: > WriteTo writes data to w until there's no more data to write or when an error occurs. However, it is unclear to me if ""no more data to write"" means ""until EOF"" in the case of the `bufio.Reader` implementation, or if it means ""the buffer was flushed"" or, if the buffer was empty, ""a successful proxied read call had the read data written"". Personally I expected this to call Read at most once, much like the bufio.Reader's Read method. I think that this behavior should either be changed to not use `fill()` (and I am happy to make this change), or the documentation should explicitly say that `bufio.Reader`'s `WriteTo` method writes until EOF or an error is returned from an upstream Read call. ",1,bufio reader writeto documentation should clarify that multiple calls to the upstream reader may be made i am unsure if this is intended behavior in which case this is a documentation problem or a bug in which case it may be a bug and a documentation problem please advise or perhaps it s neither of course i have patches for both i can submit what version of go are you using go version go version devel tue feb linux what did you do create a net conn that receives some bytes on the first call to read and then holds the connection open so that you do not receive an io eof from a call to read now wrap it in a bufio reader call io copy on the new buffered reader and copy it somewhere else into a bytes buffer for example what did you expect to see i expected the bufio reader s writeto method to be called proxy a single call to conn read write that data and then return what did you see instead instead it attempts to call conn read a second time the behavior is to read until eof or an error is returned this may not be an issue the documentation for says writeto writes data to w until there s no more data to write or when an error occurs however it is unclear to me if no more data to write means until eof in the case of the bufio reader implementation or if it means the buffer was flushed or if the buffer was empty a successful proxied read call had the read data written personally i expected this to call read at most once much like the bufio reader s read method i think that this behavior should either be changed to not use fill and i am happy to make this change or the documentation should explicitly say that bufio reader s writeto method writes until eof or an error is returned from an upstream read call ,1 33098,6155926769.0,IssuesEvent,2017-06-28 15:39:18,golang/go,https://api.github.com/repos/golang/go,closed,Website documentation,Documentation WaitingForInfo,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8.3 windows/amd64 ### What operating system and processor architecture are you using (`go env`)? set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=Z:\GoPath set GORACE= set GOROOT=E:\Program Fles\Go set GOTOOLDIR=E:\Program Fles\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 set PKG_CONFIG=pkg-config set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 ### What did you do? Try to find documentation on website about: ""go:integrate"" ""go:generate"" and etc... ### What did you expect to see? Don`t foud one atricle or one part of documentation about all allowable features. ### What did you see instead? Special part on page https://golang.org/doc/ with common and clear information about that annotations. ",1.0,"Website documentation - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8.3 windows/amd64 ### What operating system and processor architecture are you using (`go env`)? set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=Z:\GoPath set GORACE= set GOROOT=E:\Program Fles\Go set GOTOOLDIR=E:\Program Fles\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 set PKG_CONFIG=pkg-config set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 ### What did you do? Try to find documentation on website about: ""go:integrate"" ""go:generate"" and etc... ### What did you expect to see? Don`t foud one atricle or one part of documentation about all allowable features. ### What did you see instead? Special part on page https://golang.org/doc/ with common and clear information about that annotations. ",1,website documentation please answer these questions before submitting your issue thanks what version of go are you using go version go version windows what operating system and processor architecture are you using go env set goarch set gobin set goexe exe set gohostarch set gohostos windows set goos windows set gopath z gopath set gorace set goroot e program fles go set gotooldir e program fles go pkg tool windows set gccgo gccgo set cc gcc set gogccflags mthreads fmessage length set cxx g set cgo enabled set pkg config pkg config set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g what did you do try to find documentation on website about go integrate go generate and etc what did you expect to see don t foud one atricle or one part of documentation about all allowable features what did you see instead special part on page with common and clear information about that annotations ,1 25485,5169270239.0,IssuesEvent,2017-01-18 00:14:20,golang/go,https://api.github.com/repos/golang/go,closed,doc: mention required OS changes in the release notes,Documentation OS-Plan9,"### What version of Go are you using (`go version`)? Go 1.8 release candidate 1. ### What operating system and processor architecture are you using (`go env`)? Plan 9 from Bell Labs, any supported architecture. ### What did you do? Attempted to run net_test.go ### What did you expect to see? Overwhelming and unrelenting success ### What did you see instead? FAIL: TestConnClose because of an unknown control request ### Epilogue In the draft release notes for Go 1.8[1], we get the following: > The Plan 9 port's networking support is now much more complete and matches the behavior of Unix and Windows with respect to deadlines and cancelation. Sounds great! but it fails to mention that this change requires modification of the OS itself; specifically, as described in a Go commit message[2], which refers to (but does not specify) a different Github repository entirely, as 'the' Plan 9 kernel[3]. This change is not present in the latest ISO made available by Bell Labs. In the end, it's a simple change that other Plan 9 kernels can easily accomodate, but it would be very kind of you if this sort of OS-scope change were at least mentioned somewhere in the release notes, even if it's just a tiny asterisk with an href to a changelog somewhere. It would save us some detective work, and make it easier for us to use Go. [1] https://beta.golang.org/doc/go1.8 [2] https://github.com/golang/go/commit/3d1ae4b75c77a88ba3b20ada874f1027365a8060 [3] https://github.com/0intro/plan9-contrib/commit/390a902aece1c009c614d3fdb3757e0470a93304",1.0,"doc: mention required OS changes in the release notes - ### What version of Go are you using (`go version`)? Go 1.8 release candidate 1. ### What operating system and processor architecture are you using (`go env`)? Plan 9 from Bell Labs, any supported architecture. ### What did you do? Attempted to run net_test.go ### What did you expect to see? Overwhelming and unrelenting success ### What did you see instead? FAIL: TestConnClose because of an unknown control request ### Epilogue In the draft release notes for Go 1.8[1], we get the following: > The Plan 9 port's networking support is now much more complete and matches the behavior of Unix and Windows with respect to deadlines and cancelation. Sounds great! but it fails to mention that this change requires modification of the OS itself; specifically, as described in a Go commit message[2], which refers to (but does not specify) a different Github repository entirely, as 'the' Plan 9 kernel[3]. This change is not present in the latest ISO made available by Bell Labs. In the end, it's a simple change that other Plan 9 kernels can easily accomodate, but it would be very kind of you if this sort of OS-scope change were at least mentioned somewhere in the release notes, even if it's just a tiny asterisk with an href to a changelog somewhere. It would save us some detective work, and make it easier for us to use Go. [1] https://beta.golang.org/doc/go1.8 [2] https://github.com/golang/go/commit/3d1ae4b75c77a88ba3b20ada874f1027365a8060 [3] https://github.com/0intro/plan9-contrib/commit/390a902aece1c009c614d3fdb3757e0470a93304",1,doc mention required os changes in the release notes what version of go are you using go version go release candidate what operating system and processor architecture are you using go env plan from bell labs any supported architecture what did you do attempted to run net test go what did you expect to see overwhelming and unrelenting success what did you see instead fail testconnclose because of an unknown control request epilogue in the draft release notes for go we get the following the plan port s networking support is now much more complete and matches the behavior of unix and windows with respect to deadlines and cancelation sounds great but it fails to mention that this change requires modification of the os itself specifically as described in a go commit message which refers to but does not specify a different github repository entirely as the plan kernel this change is not present in the latest iso made available by bell labs in the end it s a simple change that other plan kernels can easily accomodate but it would be very kind of you if this sort of os scope change were at least mentioned somewhere in the release notes even if it s just a tiny asterisk with an href to a changelog somewhere it would save us some detective work and make it easier for us to use go ,1 19235,4357258516.0,IssuesEvent,2016-08-02 00:47:06,golang/go,https://api.github.com/repos/golang/go,closed,doc: specify new automatic HTTP/2 behavior of net/http.Server.Serve,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.7rc3 linux/amd64 2. What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" 3. What did you do? Compile github.com/mholt/caddy 4. What did you expect to see? Caddy serves HTTP/2. 5. What did you see instead? Caddy serves HTTP/1.1 only. The semantics of net/http/(*Server).Serve() [have changed](https://tip.golang.org/pkg/net/http/#Server.Serve): > If srv.TLSConfig is non-nil and doesn't include the string ""h2"" in Config.NextProtos, HTTP/2 support is not enabled. Apparently that was not the case with Go 1.6. Caddy used to use (or still uses) an empty slice for NextProtos and HTTP/2 worked fine. Adding ""h2"" works. **I did not expect this change**, as it is not mentioned in the Go 1.7 Release Notes DRAFT. Please add a note about that changed behaviour. Thanks See also mholt/caddy#975.",1.0,"doc: specify new automatic HTTP/2 behavior of net/http.Server.Serve - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.7rc3 linux/amd64 2. What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" 3. What did you do? Compile github.com/mholt/caddy 4. What did you expect to see? Caddy serves HTTP/2. 5. What did you see instead? Caddy serves HTTP/1.1 only. The semantics of net/http/(*Server).Serve() [have changed](https://tip.golang.org/pkg/net/http/#Server.Serve): > If srv.TLSConfig is non-nil and doesn't include the string ""h2"" in Config.NextProtos, HTTP/2 support is not enabled. Apparently that was not the case with Go 1.6. Caddy used to use (or still uses) an empty slice for NextProtos and HTTP/2 worked fine. Adding ""h2"" works. **I did not expect this change**, as it is not mentioned in the Go 1.7 Release Notes DRAFT. Please add a note about that changed behaviour. Thanks See also mholt/caddy#975.",1,doc specify new automatic http behavior of net http server serve please answer these questions before submitting your issue thanks what version of go are you using go version go version linux what operating system and processor architecture are you using go env gohostarch gohostos linux what did you do compile github com mholt caddy what did you expect to see caddy serves http what did you see instead caddy serves http only the semantics of net http server serve if srv tlsconfig is non nil and doesn t include the string in config nextprotos http support is not enabled apparently that was not the case with go caddy used to use or still uses an empty slice for nextprotos and http worked fine adding works i did not expect this change as it is not mentioned in the go release notes draft please add a note about that changed behaviour thanks see also mholt caddy ,1 244686,18765454547.0,IssuesEvent,2021-11-05 22:57:12,golang/go,https://api.github.com/repos/golang/go,closed,net/netip: zero value of Addr is undocumented,Documentation NeedsFix release-blocker,"The zero value of Addr is not documented (is it 0.0.0.0? is it invalid?) but is referred to in some docs. > If slice's length is not 4 or 16, AddrFromSlice returns Addr{}, false. ",1.0,"net/netip: zero value of Addr is undocumented - The zero value of Addr is not documented (is it 0.0.0.0? is it invalid?) but is referred to in some docs. > If slice's length is not 4 or 16, AddrFromSlice returns Addr{}, false. ",1,net netip zero value of addr is undocumented the zero value of addr is not documented is it is it invalid but is referred to in some docs if slice s length is not or addrfromslice returns addr false ,1 90950,26226111393.0,IssuesEvent,2023-01-04 18:51:13,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env/linux-arm64/aws: remove Linux ARM64 host on AWS,Builders NeedsFix,"We should remove the host-linux-arm64-aws host. The host-linux-arm64-bullseye host has been running without issue for a couple of weeks now. @golang/release @cherrymui ",1.0,"x/build/env/linux-arm64/aws: remove Linux ARM64 host on AWS - We should remove the host-linux-arm64-aws host. The host-linux-arm64-bullseye host has been running without issue for a couple of weeks now. @golang/release @cherrymui ",0,x build env linux aws remove linux host on aws we should remove the host linux aws host the host linux bullseye host has been running without issue for a couple of weeks now golang release cherrymui ,0 141621,12974005215.0,IssuesEvent,2020-07-21 14:49:53,golang/go,https://api.github.com/repos/golang/go,closed,x/text/language: possible error in the handler example of the package documentation,Documentation NeedsInvestigation,"On line [36](https://github.com/golang/text/blob/master/language/doc.go#L36) of the documentation the cookie value is passed using `lang.String()` to `language.MatchStrings` . I assume it should be `lang.Value` instead. Current documentation: ```go lang, _ := r.Cookie(""lang"") ... tag, _ := language.MatchStrings(matcher, lang.String(), accept) ``` Proposed fix: ```go lang, _ := r.Cookie(""lang"") ... tag, _ := language.MatchStrings(matcher, lang.Value, accept) ``` If my proposed solution is right I can provide CL to fix the documentation.",1.0,"x/text/language: possible error in the handler example of the package documentation - On line [36](https://github.com/golang/text/blob/master/language/doc.go#L36) of the documentation the cookie value is passed using `lang.String()` to `language.MatchStrings` . I assume it should be `lang.Value` instead. Current documentation: ```go lang, _ := r.Cookie(""lang"") ... tag, _ := language.MatchStrings(matcher, lang.String(), accept) ``` Proposed fix: ```go lang, _ := r.Cookie(""lang"") ... tag, _ := language.MatchStrings(matcher, lang.Value, accept) ``` If my proposed solution is right I can provide CL to fix the documentation.",1,x text language possible error in the handler example of the package documentation on line of the documentation the cookie value is passed using lang string to language matchstrings i assume it should be lang value instead current documentation go lang r cookie lang tag language matchstrings matcher lang string accept proposed fix go lang r cookie lang tag language matchstrings matcher lang value accept if my proposed solution is right i can provide cl to fix the documentation ,1 21888,4757087245.0,IssuesEvent,2016-10-24 15:39:20,golang/go,https://api.github.com/repos/golang/go,closed,log: document Print and Printf adding newlines more,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6.3 linux/386 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""386"" GOBIN="""" GOEXE="""" GOHOSTARCH=""386"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr2/ps/isp/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_386"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m32 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" 3. What did you do? https://play.golang.org/p/qF9NrwS_2Y 4. What did you expect to see? 2009/11/10 23:00:00 1st Line. 2009/11/10 23:00:00 2nd Line. I want on 2nd line as well. 2009/11/10 23:00:00 3rd Line.I want on the 3rd line 5. What did you see instead? 2009/11/10 23:00:00 1st Line. 2009/11/10 23:00:00 2nd Line. 2009/11/10 23:00:00 I want on 2nd line as well. 2009/11/10 23:00:00 3rd Line. 2009/11/10 23:00:00 I want on the 3rd line ",1.0,"log: document Print and Printf adding newlines more - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6.3 linux/386 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""386"" GOBIN="""" GOEXE="""" GOHOSTARCH=""386"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr2/ps/isp/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_386"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m32 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" 3. What did you do? https://play.golang.org/p/qF9NrwS_2Y 4. What did you expect to see? 2009/11/10 23:00:00 1st Line. 2009/11/10 23:00:00 2nd Line. I want on 2nd line as well. 2009/11/10 23:00:00 3rd Line.I want on the 3rd line 5. What did you see instead? 2009/11/10 23:00:00 1st Line. 2009/11/10 23:00:00 2nd Line. 2009/11/10 23:00:00 I want on 2nd line as well. 2009/11/10 23:00:00 3rd Line. 2009/11/10 23:00:00 I want on the 3rd line ",1,log document print and printf adding newlines more please answer these questions before submitting your issue thanks what version of go are you using go version go version linux what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath ps isp go gorace goroot usr local go gotooldir usr local go pkg tool linux cc gcc gogccflags fpic pthread fmessage length cxx g cgo enabled what did you do what did you expect to see line line i want on line as well line i want on the line what did you see instead line line i want on line as well line i want on the line ,1 5758,2967596508.0,IssuesEvent,2015-07-13 01:35:47,golang/go,https://api.github.com/repos/golang/go,closed,time: document that time.Tick causes a resource leak,Documentation,"Calling `time.Tick` causes a `Ticker` to leak because there is no interface to `Stop()` it. Here is a demonstration which starts 100,000 go routines each of which calls `time.Tick` then closes the go routines down again in an orderly fashion http://play.golang.org/p/zy5X4hAq0I It sleeps at the end so you can run top or equivalent and see that it will be using 100% of a CPU core keeping the `Ticker`s up to date even though the user no longer has access to them. This is unfortunate but it was decided in #8001 that it was too difficicult to `Stop` the `Ticker`s when they are garbage collected. The documentation for `NewTicker` got changed after this, but not the documentation for `Tick`. It currently reads > Tick is a convenience wrapper for NewTicker providing access to the ticking channel only. Useful for clients that have no need to shut down the ticker. It doesn't say why you might want to shut the Ticker down. My suggestion for a re-word is this > Tick is a convenience wrapper for NewTicker providing access to the ticking channel only. Note that this leaks associated resources; use NewTicker and Stop to avoid that. That is possibly too alarmist, but I wanted the docs to note clearly that using `time.Tick` is leaking something which can't be recovered. ",1.0,"time: document that time.Tick causes a resource leak - Calling `time.Tick` causes a `Ticker` to leak because there is no interface to `Stop()` it. Here is a demonstration which starts 100,000 go routines each of which calls `time.Tick` then closes the go routines down again in an orderly fashion http://play.golang.org/p/zy5X4hAq0I It sleeps at the end so you can run top or equivalent and see that it will be using 100% of a CPU core keeping the `Ticker`s up to date even though the user no longer has access to them. This is unfortunate but it was decided in #8001 that it was too difficicult to `Stop` the `Ticker`s when they are garbage collected. The documentation for `NewTicker` got changed after this, but not the documentation for `Tick`. It currently reads > Tick is a convenience wrapper for NewTicker providing access to the ticking channel only. Useful for clients that have no need to shut down the ticker. It doesn't say why you might want to shut the Ticker down. My suggestion for a re-word is this > Tick is a convenience wrapper for NewTicker providing access to the ticking channel only. Note that this leaks associated resources; use NewTicker and Stop to avoid that. That is possibly too alarmist, but I wanted the docs to note clearly that using `time.Tick` is leaking something which can't be recovered. ",1,time document that time tick causes a resource leak calling time tick causes a ticker to leak because there is no interface to stop it here is a demonstration which starts go routines each of which calls time tick then closes the go routines down again in an orderly fashion it sleeps at the end so you can run top or equivalent and see that it will be using of a cpu core keeping the ticker s up to date even though the user no longer has access to them this is unfortunate but it was decided in that it was too difficicult to stop the ticker s when they are garbage collected the documentation for newticker got changed after this but not the documentation for tick it currently reads tick is a convenience wrapper for newticker providing access to the ticking channel only useful for clients that have no need to shut down the ticker it doesn t say why you might want to shut the ticker down my suggestion for a re word is this tick is a convenience wrapper for newticker providing access to the ticking channel only note that this leaks associated resources use newticker and stop to avoid that that is possibly too alarmist but i wanted the docs to note clearly that using time tick is leaking something which can t be recovered ,1 13996,3790734864.0,IssuesEvent,2016-03-21 22:39:49,golang/go,https://api.github.com/repos/golang/go,closed,website: establish a no-me-too policy,Documentation,"@adg and I realized our ""no-me-too"" policy has only ever been ""documented"" in the golang-dev mailing list. Let's make it more official. ",1.0,"website: establish a no-me-too policy - @adg and I realized our ""no-me-too"" policy has only ever been ""documented"" in the golang-dev mailing list. Let's make it more official. ",1,website establish a no me too policy adg and i realized our no me too policy has only ever been documented in the golang dev mailing list let s make it more official ,1 33404,6201010290.0,IssuesEvent,2017-07-06 03:53:22,golang/go,https://api.github.com/repos/golang/go,closed,cmd/internal/dwarf: Can't run executables w/ debug info on FreeBSD 9.1,Documentation NeedsInvestigation OS-FreeBSD,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? master from https://go.googlesource.com/go + go version go1.4-bootstrap-20170531 freebsd/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOCHAR=""6"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""freebsd"" GOOS=""freebsd"" GOPATH="""" GORACE="""" GOROOT=""/usr/home/xxx/go1.4"" GOTOOLDIR=""/usr/home/xxx/go1.4/pkg/tool/freebsd_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? Try to install go from source. ### What did you expect to see? Successful installation ### What did you see instead? xxx@xxx/home/xxx/go/src>./all.bash ##### Building Go bootstrap tool. cmd/dist ##### Building Go toolchain using /home/xxx/go1.4. bootstrap/cmd/internal/dwarf bootstrap/cmd/internal/objabi bootstrap/cmd/internal/src bootstrap/cmd/internal/sys bootstrap/cmd/asm/internal/flags bootstrap/cmd/internal/bio bootstrap/math/bits bootstrap/cmd/internal/gcprog bootstrap/cmd/compile/internal/syntax bootstrap/debug/pe bootstrap/math/big bootstrap/cmd/internal/obj bootstrap/cmd/asm/internal/lex bootstrap/cmd/link/internal/ld bootstrap/cmd/internal/obj/arm bootstrap/cmd/internal/obj/arm64 bootstrap/cmd/internal/obj/mips bootstrap/cmd/internal/obj/ppc64 bootstrap/cmd/internal/obj/s390x bootstrap/cmd/internal/obj/x86 bootstrap/cmd/compile/internal/types bootstrap/cmd/asm/internal/arch bootstrap/cmd/compile/internal/ssa bootstrap/cmd/asm/internal/asm bootstrap/cmd/asm bootstrap/cmd/link/internal/amd64 bootstrap/cmd/link/internal/arm bootstrap/cmd/link/internal/arm64 bootstrap/cmd/link/internal/mips bootstrap/cmd/link/internal/mips64 bootstrap/cmd/link/internal/ppc64 bootstrap/cmd/link/internal/s390x bootstrap/cmd/link/internal/x86 bootstrap/cmd/link bootstrap/cmd/compile/internal/gc bootstrap/cmd/compile/internal/amd64 bootstrap/cmd/compile/internal/arm bootstrap/cmd/compile/internal/arm64 bootstrap/cmd/compile/internal/mips bootstrap/cmd/compile/internal/mips64 bootstrap/cmd/compile/internal/ppc64 bootstrap/cmd/compile/internal/s390x bootstrap/cmd/compile/internal/x86 bootstrap/cmd/compile ##### Building go_bootstrap for host, freebsd/amd64. runtime/internal/sys runtime/internal/atomic runtime encoding errors internal/cpu internal/race internal/syscall/windows/sysdll math/bits sync/atomic unicode unicode/utf16 unicode/utf8 math sync internal/singleflight io syscall cmd/go/internal/web hash bytes strings hash/adler32 bufio strconv path internal/syscall/windows internal/syscall/windows/registry time reflect encoding/base64 crypto crypto/sha1 internal/poll os os/signal sort encoding/binary fmt container/heap regexp/syntax path/filepath io/ioutil context flag go/token log cmd/go/internal/str net/url text/template/parse compress/flate encoding/xml encoding/json debug/dwarf os/exec go/scanner regexp cmd/internal/objabi go/ast compress/zlib text/template debug/macho debug/elf go/parser go/doc go/build cmd/go/internal/cfg cmd/go/internal/base cmd/go/internal/buildid cmd/go/internal/cmdflag cmd/go/internal/doc cmd/go/internal/help cmd/go/internal/load cmd/go/internal/tool cmd/go/internal/version cmd/go/internal/fix cmd/go/internal/fmtcmd cmd/go/internal/work cmd/go/internal/clean cmd/go/internal/envcmd cmd/go/internal/generate cmd/go/internal/get cmd/go/internal/list cmd/go/internal/run cmd/go/internal/test cmd/go/internal/vet cmd/go/internal/bug cmd/go ##### Building packages and commands for freebsd/amd64. runtime/internal/sys runtime/internal/atomic runtime errors internal/cpu internal/race unicode sync/atomic unicode/utf8 container/list math/bits container/ring crypto/subtle math crypto/internal/cipherhw internal/nettrace sync vendor/golang_org/x/crypto/poly1305 vendor/golang_org/x/crypto/curve25519 encoding unicode/utf16 image/color internal/syscall/windows internal/syscall/windows/registry internal/syscall/windows/sysdll plugin runtime/race vendor/golang_org/x/text/secure vendor/golang_org/x/text/unicode cmd/compile/internal/test cmd/vet/internal/whitelist image/color/palette io syscall internal/singleflight bytes strings hash crypto/cipher runtime/trace hash/adler32 hash/crc32 crypto/hmac strconv math/rand hash/crc64 hash/fnv math/cmplx path html bufio text/tabwriter vendor/golang_org/x/text/transform reflect cmd/internal/src encoding/base64 crypto/rc4 crypto crypto/aes encoding/ascii85 encoding/base32 crypto/sha512 crypto/md5 crypto/sha1 crypto/sha256 image time image/internal/imageutil image/draw image/jpeg internal/poll os sort encoding/binary regexp/syntax compress/bzip2 encoding/pem container/heap fmt path/filepath vendor/golang_org/x/net/route os/signal runtime/debug cmd/internal/sys crypto/des vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20 io/ioutil vendor/golang_org/x/crypto/chacha20poly1305 regexp flag log debug/dwarf compress/flate debug/gosym debug/plan9obj cmd/vendor/golang.org/x/arch/arm/armasm cmd/vendor/golang.org/x/arch/ppc64/ppc64asm cmd/vendor/golang.org/x/arch/x86/x86asm archive/tar cmd/internal/objabi cmd/internal/goobj compress/lzw compress/zlib archive/zip compress/gzip context math/big encoding/hex go/token encoding/csv os/exec go/scanner database/sql/driver encoding/gob debug/elf debug/macho debug/pe go/ast database/sql encoding/json encoding/xml vendor/golang_org/x/net/http2/hpack cmd/internal/objfile go/parser crypto/dsa crypto/elliptic encoding/asn1 crypto/rand go/printer crypto/rsa vendor/golang_org/x/text/unicode/bidi cmd/addr2line vendor/golang_org/x/text/unicode/norm crypto/ecdsa crypto/x509/pkix net/url mime mime/quotedprintable net/http/internal text/template/parse vendor/golang_org/x/text/secure/bidirule go/constant text/scanner image/gif image/png index/suffixarray cmd/cgo go/format testing go/types internal/trace runtime/pprof text/template vendor/golang_org/x/net/idna net/internal/socktest runtime/pprof/internal/profile testing/internal/testdeps testing/iotest testing/quick internal/testenv cmd/internal/dwarf cmd/asm/internal/flags cmd/internal/bio cmd/asm/internal/lex cmd/internal/obj cmd/compile/internal/syntax cmd/internal/gcprog cmd/internal/browser cmd/dist cmd/fix go/doc html/template cmd/internal/obj/arm go/build cmd/internal/obj/arm64 cmd/internal/obj/mips cmd/internal/obj/ppc64 cmd/internal/obj/s390x cmd/internal/obj/x86 cmd/compile/internal/types runtime/cgo go/internal/gccgoimporter go/internal/gcimporter go/internal/srcimporter cmd/api cmd/cover cmd/doc cmd/go/internal/cfg cmd/go/internal/str go/importer cmd/go/internal/base cmd/go/internal/buildid cmd/gofmt cmd/go/internal/doc cmd/go/internal/load cmd/go/internal/help cmd/go/internal/cmdflag cmd/go/internal/tool cmd/go/internal/version cmd/link/internal/ld cmd/asm/internal/arch cmd/asm/internal/asm cmd/compile/internal/ssa cmd/go/internal/work net os/user cmd/go/internal/fix cmd/go/internal/fmtcmd cmd/nm cmd/objdump cmd/asm cmd/pack cmd/vendor/github.com/google/pprof/internal/elfexec cmd/vendor/github.com/google/pprof/profile cmd/vendor/github.com/ianlancetaylor/demangle cmd/vendor/github.com/google/pprof/third_party/svg cmd/vendor/github.com/google/pprof/internal/proftest cmd/vet/internal/cfg cmd/vet cmd/go/internal/envcmd cmd/go/internal/clean cmd/go/internal/generate cmd/go/internal/list cmd/go/internal/run cmd/go/internal/test cmd/go/internal/vet cmd/vendor/github.com/google/pprof/internal/plugin cmd/vendor/github.com/google/pprof/internal/measurement cmd/vendor/github.com/google/pprof/internal/symbolz cmd/vendor/github.com/google/pprof/internal/graph cmd/vendor/github.com/google/pprof/internal/binutils cmd/vendor/github.com/google/pprof/internal/report vendor/golang_org/x/net/lex/httplex vendor/golang_org/x/net/proxy crypto/x509 net/textproto log/syslog vendor/golang_org/x/net/nettest mime/multipart net/mail crypto/tls cmd/link/internal/amd64 cmd/link/internal/arm cmd/link/internal/arm64 cmd/link/internal/mips cmd/link/internal/mips64 cmd/link/internal/ppc64 cmd/link/internal/s390x cmd/link/internal/x86 cmd/link net/http/httptrace net/smtp net/http net/http/cgi net/http/cookiejar expvar net/http/httptest net/http/httputil net/http/pprof net/rpc cmd/go/internal/web cmd/vendor/github.com/google/pprof/internal/symbolizer cmd/trace net/rpc/jsonrpc net/http/fcgi cmd/go/internal/bug cmd/go/internal/get cmd/vendor/github.com/google/pprof/internal/driver cmd/go cmd/vendor/github.com/google/pprof/driver cmd/pprof cmd/compile/internal/gc cmd/compile/internal/arm cmd/compile/internal/mips cmd/compile/internal/arm64 cmd/compile/internal/amd64 cmd/compile/internal/mips64 cmd/compile/internal/ppc64 cmd/compile/internal/s390x cmd/compile/internal/x86 cmd/compile run.bash: line 8: /home/xxx/go/bin/go: cannot execute binary file: Exec format error run.bash: line 47: /home/xxx/go/bin/go: cannot execute binary file: Exec format error run.bash: line 47: /home/xxx/go/bin/go: No error: 0 xxx@xxx/home/xxx/go/src> ",1.0,"cmd/internal/dwarf: Can't run executables w/ debug info on FreeBSD 9.1 - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? master from https://go.googlesource.com/go + go version go1.4-bootstrap-20170531 freebsd/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOCHAR=""6"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""freebsd"" GOOS=""freebsd"" GOPATH="""" GORACE="""" GOROOT=""/usr/home/xxx/go1.4"" GOTOOLDIR=""/usr/home/xxx/go1.4/pkg/tool/freebsd_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? Try to install go from source. ### What did you expect to see? Successful installation ### What did you see instead? xxx@xxx/home/xxx/go/src>./all.bash ##### Building Go bootstrap tool. cmd/dist ##### Building Go toolchain using /home/xxx/go1.4. bootstrap/cmd/internal/dwarf bootstrap/cmd/internal/objabi bootstrap/cmd/internal/src bootstrap/cmd/internal/sys bootstrap/cmd/asm/internal/flags bootstrap/cmd/internal/bio bootstrap/math/bits bootstrap/cmd/internal/gcprog bootstrap/cmd/compile/internal/syntax bootstrap/debug/pe bootstrap/math/big bootstrap/cmd/internal/obj bootstrap/cmd/asm/internal/lex bootstrap/cmd/link/internal/ld bootstrap/cmd/internal/obj/arm bootstrap/cmd/internal/obj/arm64 bootstrap/cmd/internal/obj/mips bootstrap/cmd/internal/obj/ppc64 bootstrap/cmd/internal/obj/s390x bootstrap/cmd/internal/obj/x86 bootstrap/cmd/compile/internal/types bootstrap/cmd/asm/internal/arch bootstrap/cmd/compile/internal/ssa bootstrap/cmd/asm/internal/asm bootstrap/cmd/asm bootstrap/cmd/link/internal/amd64 bootstrap/cmd/link/internal/arm bootstrap/cmd/link/internal/arm64 bootstrap/cmd/link/internal/mips bootstrap/cmd/link/internal/mips64 bootstrap/cmd/link/internal/ppc64 bootstrap/cmd/link/internal/s390x bootstrap/cmd/link/internal/x86 bootstrap/cmd/link bootstrap/cmd/compile/internal/gc bootstrap/cmd/compile/internal/amd64 bootstrap/cmd/compile/internal/arm bootstrap/cmd/compile/internal/arm64 bootstrap/cmd/compile/internal/mips bootstrap/cmd/compile/internal/mips64 bootstrap/cmd/compile/internal/ppc64 bootstrap/cmd/compile/internal/s390x bootstrap/cmd/compile/internal/x86 bootstrap/cmd/compile ##### Building go_bootstrap for host, freebsd/amd64. runtime/internal/sys runtime/internal/atomic runtime encoding errors internal/cpu internal/race internal/syscall/windows/sysdll math/bits sync/atomic unicode unicode/utf16 unicode/utf8 math sync internal/singleflight io syscall cmd/go/internal/web hash bytes strings hash/adler32 bufio strconv path internal/syscall/windows internal/syscall/windows/registry time reflect encoding/base64 crypto crypto/sha1 internal/poll os os/signal sort encoding/binary fmt container/heap regexp/syntax path/filepath io/ioutil context flag go/token log cmd/go/internal/str net/url text/template/parse compress/flate encoding/xml encoding/json debug/dwarf os/exec go/scanner regexp cmd/internal/objabi go/ast compress/zlib text/template debug/macho debug/elf go/parser go/doc go/build cmd/go/internal/cfg cmd/go/internal/base cmd/go/internal/buildid cmd/go/internal/cmdflag cmd/go/internal/doc cmd/go/internal/help cmd/go/internal/load cmd/go/internal/tool cmd/go/internal/version cmd/go/internal/fix cmd/go/internal/fmtcmd cmd/go/internal/work cmd/go/internal/clean cmd/go/internal/envcmd cmd/go/internal/generate cmd/go/internal/get cmd/go/internal/list cmd/go/internal/run cmd/go/internal/test cmd/go/internal/vet cmd/go/internal/bug cmd/go ##### Building packages and commands for freebsd/amd64. runtime/internal/sys runtime/internal/atomic runtime errors internal/cpu internal/race unicode sync/atomic unicode/utf8 container/list math/bits container/ring crypto/subtle math crypto/internal/cipherhw internal/nettrace sync vendor/golang_org/x/crypto/poly1305 vendor/golang_org/x/crypto/curve25519 encoding unicode/utf16 image/color internal/syscall/windows internal/syscall/windows/registry internal/syscall/windows/sysdll plugin runtime/race vendor/golang_org/x/text/secure vendor/golang_org/x/text/unicode cmd/compile/internal/test cmd/vet/internal/whitelist image/color/palette io syscall internal/singleflight bytes strings hash crypto/cipher runtime/trace hash/adler32 hash/crc32 crypto/hmac strconv math/rand hash/crc64 hash/fnv math/cmplx path html bufio text/tabwriter vendor/golang_org/x/text/transform reflect cmd/internal/src encoding/base64 crypto/rc4 crypto crypto/aes encoding/ascii85 encoding/base32 crypto/sha512 crypto/md5 crypto/sha1 crypto/sha256 image time image/internal/imageutil image/draw image/jpeg internal/poll os sort encoding/binary regexp/syntax compress/bzip2 encoding/pem container/heap fmt path/filepath vendor/golang_org/x/net/route os/signal runtime/debug cmd/internal/sys crypto/des vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20 io/ioutil vendor/golang_org/x/crypto/chacha20poly1305 regexp flag log debug/dwarf compress/flate debug/gosym debug/plan9obj cmd/vendor/golang.org/x/arch/arm/armasm cmd/vendor/golang.org/x/arch/ppc64/ppc64asm cmd/vendor/golang.org/x/arch/x86/x86asm archive/tar cmd/internal/objabi cmd/internal/goobj compress/lzw compress/zlib archive/zip compress/gzip context math/big encoding/hex go/token encoding/csv os/exec go/scanner database/sql/driver encoding/gob debug/elf debug/macho debug/pe go/ast database/sql encoding/json encoding/xml vendor/golang_org/x/net/http2/hpack cmd/internal/objfile go/parser crypto/dsa crypto/elliptic encoding/asn1 crypto/rand go/printer crypto/rsa vendor/golang_org/x/text/unicode/bidi cmd/addr2line vendor/golang_org/x/text/unicode/norm crypto/ecdsa crypto/x509/pkix net/url mime mime/quotedprintable net/http/internal text/template/parse vendor/golang_org/x/text/secure/bidirule go/constant text/scanner image/gif image/png index/suffixarray cmd/cgo go/format testing go/types internal/trace runtime/pprof text/template vendor/golang_org/x/net/idna net/internal/socktest runtime/pprof/internal/profile testing/internal/testdeps testing/iotest testing/quick internal/testenv cmd/internal/dwarf cmd/asm/internal/flags cmd/internal/bio cmd/asm/internal/lex cmd/internal/obj cmd/compile/internal/syntax cmd/internal/gcprog cmd/internal/browser cmd/dist cmd/fix go/doc html/template cmd/internal/obj/arm go/build cmd/internal/obj/arm64 cmd/internal/obj/mips cmd/internal/obj/ppc64 cmd/internal/obj/s390x cmd/internal/obj/x86 cmd/compile/internal/types runtime/cgo go/internal/gccgoimporter go/internal/gcimporter go/internal/srcimporter cmd/api cmd/cover cmd/doc cmd/go/internal/cfg cmd/go/internal/str go/importer cmd/go/internal/base cmd/go/internal/buildid cmd/gofmt cmd/go/internal/doc cmd/go/internal/load cmd/go/internal/help cmd/go/internal/cmdflag cmd/go/internal/tool cmd/go/internal/version cmd/link/internal/ld cmd/asm/internal/arch cmd/asm/internal/asm cmd/compile/internal/ssa cmd/go/internal/work net os/user cmd/go/internal/fix cmd/go/internal/fmtcmd cmd/nm cmd/objdump cmd/asm cmd/pack cmd/vendor/github.com/google/pprof/internal/elfexec cmd/vendor/github.com/google/pprof/profile cmd/vendor/github.com/ianlancetaylor/demangle cmd/vendor/github.com/google/pprof/third_party/svg cmd/vendor/github.com/google/pprof/internal/proftest cmd/vet/internal/cfg cmd/vet cmd/go/internal/envcmd cmd/go/internal/clean cmd/go/internal/generate cmd/go/internal/list cmd/go/internal/run cmd/go/internal/test cmd/go/internal/vet cmd/vendor/github.com/google/pprof/internal/plugin cmd/vendor/github.com/google/pprof/internal/measurement cmd/vendor/github.com/google/pprof/internal/symbolz cmd/vendor/github.com/google/pprof/internal/graph cmd/vendor/github.com/google/pprof/internal/binutils cmd/vendor/github.com/google/pprof/internal/report vendor/golang_org/x/net/lex/httplex vendor/golang_org/x/net/proxy crypto/x509 net/textproto log/syslog vendor/golang_org/x/net/nettest mime/multipart net/mail crypto/tls cmd/link/internal/amd64 cmd/link/internal/arm cmd/link/internal/arm64 cmd/link/internal/mips cmd/link/internal/mips64 cmd/link/internal/ppc64 cmd/link/internal/s390x cmd/link/internal/x86 cmd/link net/http/httptrace net/smtp net/http net/http/cgi net/http/cookiejar expvar net/http/httptest net/http/httputil net/http/pprof net/rpc cmd/go/internal/web cmd/vendor/github.com/google/pprof/internal/symbolizer cmd/trace net/rpc/jsonrpc net/http/fcgi cmd/go/internal/bug cmd/go/internal/get cmd/vendor/github.com/google/pprof/internal/driver cmd/go cmd/vendor/github.com/google/pprof/driver cmd/pprof cmd/compile/internal/gc cmd/compile/internal/arm cmd/compile/internal/mips cmd/compile/internal/arm64 cmd/compile/internal/amd64 cmd/compile/internal/mips64 cmd/compile/internal/ppc64 cmd/compile/internal/s390x cmd/compile/internal/x86 cmd/compile run.bash: line 8: /home/xxx/go/bin/go: cannot execute binary file: Exec format error run.bash: line 47: /home/xxx/go/bin/go: cannot execute binary file: Exec format error run.bash: line 47: /home/xxx/go/bin/go: No error: 0 xxx@xxx/home/xxx/go/src> ",1,cmd internal dwarf can t run executables w debug info on freebsd please answer these questions before submitting your issue thanks what version of go are you using go version master from go version bootstrap freebsd what operating system and processor architecture are you using go env goarch gobin gochar goexe gohostarch gohostos freebsd goos freebsd gopath gorace goroot usr home xxx gotooldir usr home xxx pkg tool freebsd cc gcc gogccflags fpic pthread fmessage length cxx g cgo enabled what did you do try to install go from source what did you expect to see successful installation what did you see instead xxx xxx home xxx go src all bash building go bootstrap tool cmd dist building go toolchain using home xxx bootstrap cmd internal dwarf bootstrap cmd internal objabi bootstrap cmd internal src bootstrap cmd internal sys bootstrap cmd asm internal flags bootstrap cmd internal bio bootstrap math bits bootstrap cmd internal gcprog bootstrap cmd compile internal syntax bootstrap debug pe bootstrap math big bootstrap cmd internal obj bootstrap cmd asm internal lex bootstrap cmd link internal ld bootstrap cmd internal obj arm bootstrap cmd internal obj bootstrap cmd internal obj mips bootstrap cmd internal obj bootstrap cmd internal obj bootstrap cmd internal obj bootstrap cmd compile internal types bootstrap cmd asm internal arch bootstrap cmd compile internal ssa bootstrap cmd asm internal asm bootstrap cmd asm bootstrap cmd link internal bootstrap cmd link internal arm bootstrap cmd link internal bootstrap cmd link internal mips bootstrap cmd link internal bootstrap cmd link internal bootstrap cmd link internal bootstrap cmd link internal bootstrap cmd link bootstrap cmd compile internal gc bootstrap cmd compile internal bootstrap cmd compile internal arm bootstrap cmd compile internal bootstrap cmd compile internal mips bootstrap cmd compile internal bootstrap cmd compile internal bootstrap cmd compile internal bootstrap cmd compile internal bootstrap cmd compile building go bootstrap for host freebsd runtime internal sys runtime internal atomic runtime encoding errors internal cpu internal race internal syscall windows sysdll math bits sync atomic unicode unicode unicode math sync internal singleflight io syscall cmd go internal web hash bytes strings hash bufio strconv path internal syscall windows internal syscall windows registry time reflect encoding crypto crypto internal poll os os signal sort encoding binary fmt container heap regexp syntax path filepath io ioutil context flag go token log cmd go internal str net url text template parse compress flate encoding xml encoding json debug dwarf os exec go scanner regexp cmd internal objabi go ast compress zlib text template debug macho debug elf go parser go doc go build cmd go internal cfg cmd go internal base cmd go internal buildid cmd go internal cmdflag cmd go internal doc cmd go internal help cmd go internal load cmd go internal tool cmd go internal version cmd go internal fix cmd go internal fmtcmd cmd go internal work cmd go internal clean cmd go internal envcmd cmd go internal generate cmd go internal get cmd go internal list cmd go internal run cmd go internal test cmd go internal vet cmd go internal bug cmd go building packages and commands for freebsd runtime internal sys runtime internal atomic runtime errors internal cpu internal race unicode sync atomic unicode container list math bits container ring crypto subtle math crypto internal cipherhw internal nettrace sync vendor golang org x crypto vendor golang org x crypto encoding unicode image color internal syscall windows internal syscall windows registry internal syscall windows sysdll plugin runtime race vendor golang org x text secure vendor golang org x text unicode cmd compile internal test cmd vet internal whitelist image color palette io syscall internal singleflight bytes strings hash crypto cipher runtime trace hash hash crypto hmac strconv math rand hash hash fnv math cmplx path html bufio text tabwriter vendor golang org x text transform reflect cmd internal src encoding crypto crypto crypto aes encoding encoding crypto crypto crypto crypto image time image internal imageutil image draw image jpeg internal poll os sort encoding binary regexp syntax compress encoding pem container heap fmt path filepath vendor golang org x net route os signal runtime debug cmd internal sys crypto des vendor golang org x crypto internal io ioutil vendor golang org x crypto regexp flag log debug dwarf compress flate debug gosym debug cmd vendor golang org x arch arm armasm cmd vendor golang org x arch cmd vendor golang org x arch archive tar cmd internal objabi cmd internal goobj compress lzw compress zlib archive zip compress gzip context math big encoding hex go token encoding csv os exec go scanner database sql driver encoding gob debug elf debug macho debug pe go ast database sql encoding json encoding xml vendor golang org x net hpack cmd internal objfile go parser crypto dsa crypto elliptic encoding crypto rand go printer crypto rsa vendor golang org x text unicode bidi cmd vendor golang org x text unicode norm crypto ecdsa crypto pkix net url mime mime quotedprintable net http internal text template parse vendor golang org x text secure bidirule go constant text scanner image gif image png index suffixarray cmd cgo go format testing go types internal trace runtime pprof text template vendor golang org x net idna net internal socktest runtime pprof internal profile testing internal testdeps testing iotest testing quick internal testenv cmd internal dwarf cmd asm internal flags cmd internal bio cmd asm internal lex cmd internal obj cmd compile internal syntax cmd internal gcprog cmd internal browser cmd dist cmd fix go doc html template cmd internal obj arm go build cmd internal obj cmd internal obj mips cmd internal obj cmd internal obj cmd internal obj cmd compile internal types runtime cgo go internal gccgoimporter go internal gcimporter go internal srcimporter cmd api cmd cover cmd doc cmd go internal cfg cmd go internal str go importer cmd go internal base cmd go internal buildid cmd gofmt cmd go internal doc cmd go internal load cmd go internal help cmd go internal cmdflag cmd go internal tool cmd go internal version cmd link internal ld cmd asm internal arch cmd asm internal asm cmd compile internal ssa cmd go internal work net os user cmd go internal fix cmd go internal fmtcmd cmd nm cmd objdump cmd asm cmd pack cmd vendor github com google pprof internal elfexec cmd vendor github com google pprof profile cmd vendor github com ianlancetaylor demangle cmd vendor github com google pprof third party svg cmd vendor github com google pprof internal proftest cmd vet internal cfg cmd vet cmd go internal envcmd cmd go internal clean cmd go internal generate cmd go internal list cmd go internal run cmd go internal test cmd go internal vet cmd vendor github com google pprof internal plugin cmd vendor github com google pprof internal measurement cmd vendor github com google pprof internal symbolz cmd vendor github com google pprof internal graph cmd vendor github com google pprof internal binutils cmd vendor github com google pprof internal report vendor golang org x net lex httplex vendor golang org x net proxy crypto net textproto log syslog vendor golang org x net nettest mime multipart net mail crypto tls cmd link internal cmd link internal arm cmd link internal cmd link internal mips cmd link internal cmd link internal cmd link internal cmd link internal cmd link net http httptrace net smtp net http net http cgi net http cookiejar expvar net http httptest net http httputil net http pprof net rpc cmd go internal web cmd vendor github com google pprof internal symbolizer cmd trace net rpc jsonrpc net http fcgi cmd go internal bug cmd go internal get cmd vendor github com google pprof internal driver cmd go cmd vendor github com google pprof driver cmd pprof cmd compile internal gc cmd compile internal arm cmd compile internal mips cmd compile internal cmd compile internal cmd compile internal cmd compile internal cmd compile internal cmd compile internal cmd compile run bash line home xxx go bin go cannot execute binary file exec format error run bash line home xxx go bin go cannot execute binary file exec format error run bash line home xxx go bin go no error xxx xxx home xxx go src ,1 136521,12717504131.0,IssuesEvent,2020-06-24 05:21:54,golang/go,https://api.github.com/repos/golang/go,closed,"x/tools/internal/gocommand: documentation doesn't state what Run{,Piped,Raw} do and what they returns",Documentation NeedsInvestigation Tools,"There are 3 exported identifiers with the word ""Run"" in package [`golang.org/x/tools/internal/gocommand`](https://pkg.go.dev/golang.org/x/tools/internal/gocommand). None of them say what the identifiers do and what they return. Each one says ""it's like this other Run variant"". This makes it hard to know how to use the API of `gocommand` package. ```Go // RunPiped is like Run, but relies on the given stdout/stderr func (i *Invocation) RunPiped(ctx context.Context, stdout, stderr io.Writer) error // Run calls Runner.RunRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) Run(ctx context.Context, inv Invocation) (*bytes.Buffer, error) // RunRaw calls Invocation.runRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) RunRaw(ctx context.Context, inv Invocation) (*bytes.Buffer, *bytes.Buffer, error, error) ``` Documentation for `Invocation.runRaw` isn't readily visible because it's an unexported identifier: ```Go // RunRaw is like RunPiped, but also returns the raw stderr and error for callers // that want to do low-level error handling/recovery. func (i *Invocation) runRaw(ctx context.Context) (stdout *bytes.Buffer, stderr *bytes.Buffer, friendlyError error, rawError error) ``` It has named return values that help. The `Runner` type is documented as follows: ``` // An Runner will run go command invocations and serialize them if it sees a concurrency error. ``` Perhaps that should be made more visible on the methods, and their `*bytes.Buffer` and `error` results can be given names like `stdout`, `stderr` to help clarify what's what. /cc @heschik",1.0,"x/tools/internal/gocommand: documentation doesn't state what Run{,Piped,Raw} do and what they returns - There are 3 exported identifiers with the word ""Run"" in package [`golang.org/x/tools/internal/gocommand`](https://pkg.go.dev/golang.org/x/tools/internal/gocommand). None of them say what the identifiers do and what they return. Each one says ""it's like this other Run variant"". This makes it hard to know how to use the API of `gocommand` package. ```Go // RunPiped is like Run, but relies on the given stdout/stderr func (i *Invocation) RunPiped(ctx context.Context, stdout, stderr io.Writer) error // Run calls Runner.RunRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) Run(ctx context.Context, inv Invocation) (*bytes.Buffer, error) // RunRaw calls Invocation.runRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) RunRaw(ctx context.Context, inv Invocation) (*bytes.Buffer, *bytes.Buffer, error, error) ``` Documentation for `Invocation.runRaw` isn't readily visible because it's an unexported identifier: ```Go // RunRaw is like RunPiped, but also returns the raw stderr and error for callers // that want to do low-level error handling/recovery. func (i *Invocation) runRaw(ctx context.Context) (stdout *bytes.Buffer, stderr *bytes.Buffer, friendlyError error, rawError error) ``` It has named return values that help. The `Runner` type is documented as follows: ``` // An Runner will run go command invocations and serialize them if it sees a concurrency error. ``` Perhaps that should be made more visible on the methods, and their `*bytes.Buffer` and `error` results can be given names like `stdout`, `stderr` to help clarify what's what. /cc @heschik",1,x tools internal gocommand documentation doesn t state what run piped raw do and what they returns there are exported identifiers with the word run in package none of them say what the identifiers do and what they return each one says it s like this other run variant this makes it hard to know how to use the api of gocommand package go runpiped is like run but relies on the given stdout stderr func i invocation runpiped ctx context context stdout stderr io writer error run calls runner runraw serializing requests if they fight over go mod changes func runner runner run ctx context context inv invocation bytes buffer error runraw calls invocation runraw serializing requests if they fight over go mod changes func runner runner runraw ctx context context inv invocation bytes buffer bytes buffer error error documentation for invocation runraw isn t readily visible because it s an unexported identifier go runraw is like runpiped but also returns the raw stderr and error for callers that want to do low level error handling recovery func i invocation runraw ctx context context stdout bytes buffer stderr bytes buffer friendlyerror error rawerror error it has named return values that help the runner type is documented as follows an runner will run go command invocations and serialize them if it sees a concurrency error perhaps that should be made more visible on the methods and their bytes buffer and error results can be given names like stdout stderr to help clarify what s what cc heschik,1 267654,20239268418.0,IssuesEvent,2022-02-14 07:30:06,golang/go,https://api.github.com/repos/golang/go,opened,spec: Method sets section doesn't seem quite right for interfaces with type lists,Documentation,"https://tip.golang.org/ref/spec#Method_sets says the following: > The method set of an [interface type](https://tip.golang.org/ref/spec#Interface_types) is the intersection of the method sets of each type in the interface's [type set](https://tip.golang.org/ref/spec#Interface_types) (the resulting method set is usually just the set of declared methods in the interface). AFAIU, per > - The type set of a non-empty interface is the intersection of the type sets of its interface elements. > - The type set of a non-interface type term is the set consisting of just that type. the type set of `interface { S }` for concrete type S is {S}. The intersection of the method sets is thus the method set of S. But that doesn't seem quite right. `func foo[T S](x T) { x.Foo() }` certainly doesn't compile. Was the intention to have an implicit, empty method set for the absent list of methods in the interface? /cc @griesemer @findleyr ",1.0,"spec: Method sets section doesn't seem quite right for interfaces with type lists - https://tip.golang.org/ref/spec#Method_sets says the following: > The method set of an [interface type](https://tip.golang.org/ref/spec#Interface_types) is the intersection of the method sets of each type in the interface's [type set](https://tip.golang.org/ref/spec#Interface_types) (the resulting method set is usually just the set of declared methods in the interface). AFAIU, per > - The type set of a non-empty interface is the intersection of the type sets of its interface elements. > - The type set of a non-interface type term is the set consisting of just that type. the type set of `interface { S }` for concrete type S is {S}. The intersection of the method sets is thus the method set of S. But that doesn't seem quite right. `func foo[T S](x T) { x.Foo() }` certainly doesn't compile. Was the intention to have an implicit, empty method set for the absent list of methods in the interface? /cc @griesemer @findleyr ",1,spec method sets section doesn t seem quite right for interfaces with type lists says the following the method set of an is the intersection of the method sets of each type in the interface s the resulting method set is usually just the set of declared methods in the interface afaiu per the type set of a non empty interface is the intersection of the type sets of its interface elements the type set of a non interface type term is the set consisting of just that type the type set of interface s for concrete type s is s the intersection of the method sets is thus the method set of s but that doesn t seem quite right func foo x t x foo certainly doesn t compile was the intention to have an implicit empty method set for the absent list of methods in the interface cc griesemer findleyr ,1 72506,9595901689.0,IssuesEvent,2019-05-09 17:12:21,golang/go,https://api.github.com/repos/golang/go,closed,vendor: no docs on how to update a module in std,Documentation NeedsFix modules release-blocker,"I've been flailing around all morning fighting the new system of updating modules in std. I want to update x/net in std because the golang.org/x/net/http/httpproxy we have in std is old and doesn't support `ALL_PROXY`. Note that all_proxy is present in golang.org/x/net: ``` bradfitz@go:~/src/golang.org/x/net$ git show-ref HEAD 9ce7a6920f093fc0b908c4a5f66ae049110f417e refs/remotes/origin/HEAD bradfitz@go:~/src/golang.org/x/net$ git grep -i all_proxy proxy/proxy.go: names: []string{""ALL_PROXY"", ""all_proxy""}, proxy/proxy_test.go: fmt.Fprintf(&buf, ""all_proxy=%q"", t.allProxyEnv) proxy/proxy_test.go: os.Setenv(""ALL_PROXY"", tt.allProxyEnv) ``` But it's not present in std: ``` bradfitz@go:~$ cd $GOROOT/src/ bradfitz@go:~/go/src$ git grep -i all_proxy ``` So, let's update it... ``` bradfitz@go:~/go/src$ go get -u golang.org/x/net/...@latest go: finding golang.org/x/net latest go: finding golang.org/x/sys latest go: finding golang.org/x/crypto latest bradfitz@go:~/go/src$ git diff go.mod diff --git a/src/go.mod b/src/go.mod index a527f9a244..047e43f864 100644 --- a/src/go.mod +++ b/src/go.mod @@ -3,9 +3,9 @@ module std go 1.12 require ( - golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d - golang.org/x/net v0.0.0-20190424112056-4829fb13d2c6 - golang.org/x/sys v0.0.0-20190425145619-16072639606e // indirect + golang.org/x/crypto v0.0.0-20190426145343-a29dc8fdc734 + golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09 + golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd // indirect golang.org/x/text v0.3.2 // indirect - golang.org/x/tools v0.0.0-20190425214124-2d660fb8a000 // indirect + golang.org/x/tools v0.0.0-20190501045030-23463209683d // indirect ) ``` And `go mod vendor` perhaps? ``` bradfitz@go:~/go/src$ go mod vendor bradfitz@go:~/go/src$ git grep -i all_proxy ``` Nope. Still not present. What changed? ``` bradfitz@go:~/go/src$ git diff --stat src/go.mod | 8 ++--- src/go.sum | 7 ++++ src/vendor/golang.org/x/sys/unix/mkall.sh | 14 +++++--- src/vendor/golang.org/x/sys/unix/mksysctl_openbsd.pl | 265 ---------------------------------------------------------------------------------------------------------------------------------------------------- src/vendor/golang.org/x/sys/unix/sockcmsg_unix.go | 8 ++--- src/vendor/golang.org/x/sys/unix/syscall.go | 1 - src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_386.go | 2 ++ src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_amd64.go | 2 +- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm.go | 4 ++- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm64.go | 2 +- src/vendor/modules.txt | 14 ++++---- 11 files changed, 39 insertions(+), 288 deletions(-) ``` ... other stuff changed, but not `golang.org/x/net/...` I tried to get get a specific version rather than ""latest"" ``` bradfitz@go:~/go/src$ go get -u golang.org/x/net/http/httpproxy@v0.0.0-20190501004415-9ce7a6920f09 go: finding golang.org/x/net/http/httpproxy v0.0.0-20190501004415-9ce7a6920f09 go: finding golang.org/x/net/http v0.0.0-20190501004415-9ce7a6920f09 bradfitz@go:~/go/src$ go mod vendor bradfitz@go:~/go/src$ git grep -i all_proxy bradfitz@go:~/go/src$ git di --stat src/go.mod | 8 ++--- src/go.sum | 7 ++++ src/vendor/golang.org/x/sys/unix/mkall.sh | 14 +++++--- src/vendor/golang.org/x/sys/unix/mksysctl_openbsd.pl | 265 ---------------------------------------------------------------------------------------------------------------------------------------------------- src/vendor/golang.org/x/sys/unix/sockcmsg_unix.go | 8 ++--- src/vendor/golang.org/x/sys/unix/syscall.go | 1 - src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_386.go | 2 ++ src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_amd64.go | 2 +- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm.go | 4 ++- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm64.go | 2 +- src/vendor/modules.txt | 14 ++++---- 11 files changed, 39 insertions(+), 288 deletions(-) ``` Still no good. A README.txt would really help. Also, what is vendor/modules.txt? What role does it play and is it hand maintained or tool maintained and where is it documented? Does it support comments? Could it have some comments saying what it is? Please help. (and document) ",1.0,"vendor: no docs on how to update a module in std - I've been flailing around all morning fighting the new system of updating modules in std. I want to update x/net in std because the golang.org/x/net/http/httpproxy we have in std is old and doesn't support `ALL_PROXY`. Note that all_proxy is present in golang.org/x/net: ``` bradfitz@go:~/src/golang.org/x/net$ git show-ref HEAD 9ce7a6920f093fc0b908c4a5f66ae049110f417e refs/remotes/origin/HEAD bradfitz@go:~/src/golang.org/x/net$ git grep -i all_proxy proxy/proxy.go: names: []string{""ALL_PROXY"", ""all_proxy""}, proxy/proxy_test.go: fmt.Fprintf(&buf, ""all_proxy=%q"", t.allProxyEnv) proxy/proxy_test.go: os.Setenv(""ALL_PROXY"", tt.allProxyEnv) ``` But it's not present in std: ``` bradfitz@go:~$ cd $GOROOT/src/ bradfitz@go:~/go/src$ git grep -i all_proxy ``` So, let's update it... ``` bradfitz@go:~/go/src$ go get -u golang.org/x/net/...@latest go: finding golang.org/x/net latest go: finding golang.org/x/sys latest go: finding golang.org/x/crypto latest bradfitz@go:~/go/src$ git diff go.mod diff --git a/src/go.mod b/src/go.mod index a527f9a244..047e43f864 100644 --- a/src/go.mod +++ b/src/go.mod @@ -3,9 +3,9 @@ module std go 1.12 require ( - golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d - golang.org/x/net v0.0.0-20190424112056-4829fb13d2c6 - golang.org/x/sys v0.0.0-20190425145619-16072639606e // indirect + golang.org/x/crypto v0.0.0-20190426145343-a29dc8fdc734 + golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09 + golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd // indirect golang.org/x/text v0.3.2 // indirect - golang.org/x/tools v0.0.0-20190425214124-2d660fb8a000 // indirect + golang.org/x/tools v0.0.0-20190501045030-23463209683d // indirect ) ``` And `go mod vendor` perhaps? ``` bradfitz@go:~/go/src$ go mod vendor bradfitz@go:~/go/src$ git grep -i all_proxy ``` Nope. Still not present. What changed? ``` bradfitz@go:~/go/src$ git diff --stat src/go.mod | 8 ++--- src/go.sum | 7 ++++ src/vendor/golang.org/x/sys/unix/mkall.sh | 14 +++++--- src/vendor/golang.org/x/sys/unix/mksysctl_openbsd.pl | 265 ---------------------------------------------------------------------------------------------------------------------------------------------------- src/vendor/golang.org/x/sys/unix/sockcmsg_unix.go | 8 ++--- src/vendor/golang.org/x/sys/unix/syscall.go | 1 - src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_386.go | 2 ++ src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_amd64.go | 2 +- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm.go | 4 ++- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm64.go | 2 +- src/vendor/modules.txt | 14 ++++---- 11 files changed, 39 insertions(+), 288 deletions(-) ``` ... other stuff changed, but not `golang.org/x/net/...` I tried to get get a specific version rather than ""latest"" ``` bradfitz@go:~/go/src$ go get -u golang.org/x/net/http/httpproxy@v0.0.0-20190501004415-9ce7a6920f09 go: finding golang.org/x/net/http/httpproxy v0.0.0-20190501004415-9ce7a6920f09 go: finding golang.org/x/net/http v0.0.0-20190501004415-9ce7a6920f09 bradfitz@go:~/go/src$ go mod vendor bradfitz@go:~/go/src$ git grep -i all_proxy bradfitz@go:~/go/src$ git di --stat src/go.mod | 8 ++--- src/go.sum | 7 ++++ src/vendor/golang.org/x/sys/unix/mkall.sh | 14 +++++--- src/vendor/golang.org/x/sys/unix/mksysctl_openbsd.pl | 265 ---------------------------------------------------------------------------------------------------------------------------------------------------- src/vendor/golang.org/x/sys/unix/sockcmsg_unix.go | 8 ++--- src/vendor/golang.org/x/sys/unix/syscall.go | 1 - src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_386.go | 2 ++ src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_amd64.go | 2 +- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm.go | 4 ++- src/vendor/golang.org/x/sys/unix/zsysctl_openbsd_arm64.go | 2 +- src/vendor/modules.txt | 14 ++++---- 11 files changed, 39 insertions(+), 288 deletions(-) ``` Still no good. A README.txt would really help. Also, what is vendor/modules.txt? What role does it play and is it hand maintained or tool maintained and where is it documented? Does it support comments? Could it have some comments saying what it is? Please help. (and document) ",1,vendor no docs on how to update a module in std i ve been flailing around all morning fighting the new system of updating modules in std i want to update x net in std because the golang org x net http httpproxy we have in std is old and doesn t support all proxy note that all proxy is present in golang org x net bradfitz go src golang org x net git show ref head refs remotes origin head bradfitz go src golang org x net git grep i all proxy proxy proxy go names string all proxy all proxy proxy proxy test go fmt fprintf buf all proxy q t allproxyenv proxy proxy test go os setenv all proxy tt allproxyenv but it s not present in std bradfitz go cd goroot src bradfitz go go src git grep i all proxy so let s update it bradfitz go go src go get u golang org x net latest go finding golang org x net latest go finding golang org x sys latest go finding golang org x crypto latest bradfitz go go src git diff go mod diff git a src go mod b src go mod index a src go mod b src go mod module std go require golang org x crypto golang org x net golang org x sys indirect golang org x crypto golang org x net golang org x sys indirect golang org x text indirect golang org x tools indirect golang org x tools indirect and go mod vendor perhaps bradfitz go go src go mod vendor bradfitz go go src git grep i all proxy nope still not present what changed bradfitz go go src git diff stat src go mod src go sum src vendor golang org x sys unix mkall sh src vendor golang org x sys unix mksysctl openbsd pl src vendor golang org x sys unix sockcmsg unix go src vendor golang org x sys unix syscall go src vendor golang org x sys unix zsysctl openbsd go src vendor golang org x sys unix zsysctl openbsd go src vendor golang org x sys unix zsysctl openbsd arm go src vendor golang org x sys unix zsysctl openbsd go src vendor modules txt files changed insertions deletions other stuff changed but not golang org x net i tried to get get a specific version rather than latest bradfitz go go src go get u golang org x net http httpproxy go finding golang org x net http httpproxy go finding golang org x net http bradfitz go go src go mod vendor bradfitz go go src git grep i all proxy bradfitz go go src git di stat src go mod src go sum src vendor golang org x sys unix mkall sh src vendor golang org x sys unix mksysctl openbsd pl src vendor golang org x sys unix sockcmsg unix go src vendor golang org x sys unix syscall go src vendor golang org x sys unix zsysctl openbsd go src vendor golang org x sys unix zsysctl openbsd go src vendor golang org x sys unix zsysctl openbsd arm go src vendor golang org x sys unix zsysctl openbsd go src vendor modules txt files changed insertions deletions still no good a readme txt would really help also what is vendor modules txt what role does it play and is it hand maintained or tool maintained and where is it documented does it support comments could it have some comments saying what it is please help and document ,1 49895,7545566991.0,IssuesEvent,2018-04-17 22:08:30,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: documented behavior unmarshaling JSON null into json.Unmarshaler is unclear,Documentation,"### What version of Go are you using (`go version`)? 1.10.1 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? I read the documentation for `json.Unmarshal` and `json.Unmarshaler.UnmarshalJSON`, and the relevant code: https://github.com/golang/go/blob/568d4848f672ecec3f9199452e9da1776a9fbba9/src/encoding/json/decode.go#L482-L494 ### What did you expect to see? A statement to the effect that `json.Unmarshal` will zero the value before calling `json.Unmarshaler.UnmarshalJSON`. ### What did you see instead? According to the documentation, `json.Unmarshal` passes `null` to `json.Unmarshaler.UnmarshalJSON`. However, it doesn't explain that, prior to making the call, it sets the field to the zero value. This is hinted at in the documentation for `json.Unmarshaler`, wherein it requires treating null inputs as a no-op, but this leaves the reader wondering what state the field is left in if it wasn't already the zero value.",1.0,"encoding/json: documented behavior unmarshaling JSON null into json.Unmarshaler is unclear - ### What version of Go are you using (`go version`)? 1.10.1 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? I read the documentation for `json.Unmarshal` and `json.Unmarshaler.UnmarshalJSON`, and the relevant code: https://github.com/golang/go/blob/568d4848f672ecec3f9199452e9da1776a9fbba9/src/encoding/json/decode.go#L482-L494 ### What did you expect to see? A statement to the effect that `json.Unmarshal` will zero the value before calling `json.Unmarshaler.UnmarshalJSON`. ### What did you see instead? According to the documentation, `json.Unmarshal` passes `null` to `json.Unmarshaler.UnmarshalJSON`. However, it doesn't explain that, prior to making the call, it sets the field to the zero value. This is hinted at in the documentation for `json.Unmarshaler`, wherein it requires treating null inputs as a no-op, but this leaves the reader wondering what state the field is left in if it wasn't already the zero value.",1,encoding json documented behavior unmarshaling json null into json unmarshaler is unclear what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env n a what did you do i read the documentation for json unmarshal and json unmarshaler unmarshaljson and the relevant code what did you expect to see a statement to the effect that json unmarshal will zero the value before calling json unmarshaler unmarshaljson what did you see instead according to the documentation json unmarshal passes null to json unmarshaler unmarshaljson however it doesn t explain that prior to making the call it sets the field to the zero value this is hinted at in the documentation for json unmarshaler wherein it requires treating null inputs as a no op but this leaves the reader wondering what state the field is left in if it wasn t already the zero value ,1 17103,4127803243.0,IssuesEvent,2016-06-10 01:00:48,golang/go,https://api.github.com/repos/golang/go,closed,"encoding/csv: document that comments must begin at start of line, even when TrimLeadingSpace is true",Documentation NeedsDecision,"In looking at the docs and in the official example for csv.ReadAll() it's not clear what order TrimLeadingSpace processing occurs (i.e., prior to parsing for comments). It appears that comments are recognized *only* if they have no leading spaces. See test case here: https://play.golang.org/p/m8GfvFWiEc This is a modified version of the ReadAll() example: https://golang.org/pkg/encoding/csv/#example_Reader_ReadAll If this is expected/defined behavior, it might be worth adding a note to the documentation or example on golang.org. ",1.0,"encoding/csv: document that comments must begin at start of line, even when TrimLeadingSpace is true - In looking at the docs and in the official example for csv.ReadAll() it's not clear what order TrimLeadingSpace processing occurs (i.e., prior to parsing for comments). It appears that comments are recognized *only* if they have no leading spaces. See test case here: https://play.golang.org/p/m8GfvFWiEc This is a modified version of the ReadAll() example: https://golang.org/pkg/encoding/csv/#example_Reader_ReadAll If this is expected/defined behavior, it might be worth adding a note to the documentation or example on golang.org. ",1,encoding csv document that comments must begin at start of line even when trimleadingspace is true in looking at the docs and in the official example for csv readall it s not clear what order trimleadingspace processing occurs i e prior to parsing for comments it appears that comments are recognized only if they have no leading spaces see test case here this is a modified version of the readall example if this is expected defined behavior it might be worth adding a note to the documentation or example on golang org ,1 27068,5311814303.0,IssuesEvent,2017-02-13 06:10:50,golang/go,https://api.github.com/repos/golang/go,closed,runtime: Frames.Next is confusing,Documentation NeedsDecision,"### What version of Go are you using (`go version`)? play.golang.org ### What operating system and processor architecture are you using (`go env`)? play.golang.org ### What did you do? Sample program: https://play.golang.org/p/5ckof3s_kJ ### What did you expect to see? The documentation for [Frames.Next](https://golang.org/pkg/runtime/#Frames.Next) says ""Next returns frame information for the next caller. If more is false, there are no more callers (the Frame value is valid)."" Reading that I would expect that more return this sort of thing ``` -> valid_frame, true -> valid_frame, true -> valid_frame, false -> invalid_frame, false -> etc. ``` Where `invalid_frame` is the default-valued frame. ### What did you see instead? ``` -> valid_frame, true -> valid_frame, true -> valid_frame, true -> invalid_frame, true -> etc. -> invalid_frame, false -> etc. ``` ### So what? This behavior of returning `more=true` and spitting out invalid `Frame`s seems pretty weird. But I assume that changing the behavior of `Next` is out of the question. So I propose the documentation be updated by someone who knows how this thing works. The docs could read ""Next returns frame information for the next caller. If `more` is `false`, no further calls to `Next` should be made. If `frame` is nil-valued, no further frames will be non-nil valued."" And an example in the docs of how to go from a `Frames` to a complete `[]Frame` would be great!",1.0,"runtime: Frames.Next is confusing - ### What version of Go are you using (`go version`)? play.golang.org ### What operating system and processor architecture are you using (`go env`)? play.golang.org ### What did you do? Sample program: https://play.golang.org/p/5ckof3s_kJ ### What did you expect to see? The documentation for [Frames.Next](https://golang.org/pkg/runtime/#Frames.Next) says ""Next returns frame information for the next caller. If more is false, there are no more callers (the Frame value is valid)."" Reading that I would expect that more return this sort of thing ``` -> valid_frame, true -> valid_frame, true -> valid_frame, false -> invalid_frame, false -> etc. ``` Where `invalid_frame` is the default-valued frame. ### What did you see instead? ``` -> valid_frame, true -> valid_frame, true -> valid_frame, true -> invalid_frame, true -> etc. -> invalid_frame, false -> etc. ``` ### So what? This behavior of returning `more=true` and spitting out invalid `Frame`s seems pretty weird. But I assume that changing the behavior of `Next` is out of the question. So I propose the documentation be updated by someone who knows how this thing works. The docs could read ""Next returns frame information for the next caller. If `more` is `false`, no further calls to `Next` should be made. If `frame` is nil-valued, no further frames will be non-nil valued."" And an example in the docs of how to go from a `Frames` to a complete `[]Frame` would be great!",1,runtime frames next is confusing what version of go are you using go version play golang org what operating system and processor architecture are you using go env play golang org what did you do sample program what did you expect to see the documentation for says next returns frame information for the next caller if more is false there are no more callers the frame value is valid reading that i would expect that more return this sort of thing valid frame true valid frame true valid frame false invalid frame false etc where invalid frame is the default valued frame what did you see instead valid frame true valid frame true valid frame true invalid frame true etc invalid frame false etc so what this behavior of returning more true and spitting out invalid frame s seems pretty weird but i assume that changing the behavior of next is out of the question so i propose the documentation be updated by someone who knows how this thing works the docs could read next returns frame information for the next caller if more is false no further calls to next should be made if frame is nil valued no further frames will be non nil valued and an example in the docs of how to go from a frames to a complete frame would be great ,1 52984,7801957352.0,IssuesEvent,2018-06-10 05:50:41,golang/go,https://api.github.com/repos/golang/go,closed,net/http/httptest: Explicitly discourage using ResponseRecorder.HeaderMap,Documentation,"(This is basically #16717 again.) Quick background: if you write a header after the body has been written and status has been set in an HTTP handler, that's a bug because it has no effect. If you're testing using an httptest.ResponseRecorder, its HeaderMap will record the header and might make you think that your code is working when it's not. This is #8857. In response to that bug the behavior was changed to snapshot the headers instead, but that caused another problem (#15560) so it was reverted. Instead, you're now supposed to use Result to get an http.Response and then look at resp.Header. The documentation is not clear enough about this. I previously filed #16717 and 8e4ea2f5e8ee2b9c455adb329d96fb13cd3c64da added the following documentation to ResponseRecorder.HeaderMap: ``` // HeaderMap contains the headers explicitly set by the Handler. // // To get the implicit headers set by the server (such as // automatic Content-Type), use the Result method. HeaderMap http.Header ``` I think we need to be clearer and explicitly discourage looking at HeaderMap. I've recently fixed a production bug where headers weren't being set and the tests specifically looked for them using HeaderMap. Then I found a whole bunch more places across many code bases where tests looked for headers to be set in HeaderMap. None of those would have caught headers written after Write. /cc @bradfitz ",1.0,"net/http/httptest: Explicitly discourage using ResponseRecorder.HeaderMap - (This is basically #16717 again.) Quick background: if you write a header after the body has been written and status has been set in an HTTP handler, that's a bug because it has no effect. If you're testing using an httptest.ResponseRecorder, its HeaderMap will record the header and might make you think that your code is working when it's not. This is #8857. In response to that bug the behavior was changed to snapshot the headers instead, but that caused another problem (#15560) so it was reverted. Instead, you're now supposed to use Result to get an http.Response and then look at resp.Header. The documentation is not clear enough about this. I previously filed #16717 and 8e4ea2f5e8ee2b9c455adb329d96fb13cd3c64da added the following documentation to ResponseRecorder.HeaderMap: ``` // HeaderMap contains the headers explicitly set by the Handler. // // To get the implicit headers set by the server (such as // automatic Content-Type), use the Result method. HeaderMap http.Header ``` I think we need to be clearer and explicitly discourage looking at HeaderMap. I've recently fixed a production bug where headers weren't being set and the tests specifically looked for them using HeaderMap. Then I found a whole bunch more places across many code bases where tests looked for headers to be set in HeaderMap. None of those would have caught headers written after Write. /cc @bradfitz ",1,net http httptest explicitly discourage using responserecorder headermap this is basically again quick background if you write a header after the body has been written and status has been set in an http handler that s a bug because it has no effect if you re testing using an httptest responserecorder its headermap will record the header and might make you think that your code is working when it s not this is in response to that bug the behavior was changed to snapshot the headers instead but that caused another problem so it was reverted instead you re now supposed to use result to get an http response and then look at resp header the documentation is not clear enough about this i previously filed and added the following documentation to responserecorder headermap headermap contains the headers explicitly set by the handler to get the implicit headers set by the server such as automatic content type use the result method headermap http header i think we need to be clearer and explicitly discourage looking at headermap i ve recently fixed a production bug where headers weren t being set and the tests specifically looked for them using headermap then i found a whole bunch more places across many code bases where tests looked for headers to be set in headermap none of those would have caught headers written after write cc bradfitz ,1 60042,8401708603.0,IssuesEvent,2018-10-11 02:33:11,golang/go,https://api.github.com/repos/golang/go,closed,"unsafe: document that the result of Alignof, Offsetof, and Sizeof are constant",Documentation,"The Go specification documents that these [""builtin"" functions are constants](https://golang.org/ref/spec#Constants). However, it is not clear from the [documentation of the `unsafe` package](https://golang.org/pkg/unsafe/) that these are constants. Perhaps we should document them as such?",1.0,"unsafe: document that the result of Alignof, Offsetof, and Sizeof are constant - The Go specification documents that these [""builtin"" functions are constants](https://golang.org/ref/spec#Constants). However, it is not clear from the [documentation of the `unsafe` package](https://golang.org/pkg/unsafe/) that these are constants. Perhaps we should document them as such?",1,unsafe document that the result of alignof offsetof and sizeof are constant the go specification documents that these however it is not clear from the that these are constants perhaps we should document them as such ,1 39896,6779848917.0,IssuesEvent,2017-10-29 06:04:21,golang/go,https://api.github.com/repos/golang/go,opened,doc: simplify contributing by offering clear plain git guidelines,Documentation,"### What Change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git? ### What it is not This issue is not a request or proposal to replace Gerrit or the review process. This issue is not a request or proposal to remove the `git-codereview` tool or to make drastic changes to how anyone on the Go team or existing contributors go about contributing. ### Why There are other open issues proposing a switch to GitHub, or adding the ability to support pushing to GitHub. Based on my own experience I think much of the friction that GitHub users are experiencing is caused by the contributing guidelines centering around `git-codereview`, which abstracts git away from the developer. Abstracting git away from developers is jarring when developers know how to use that tool already. It gives them the experience that they are using something that is entirely different to what they use today, even though it is not. ### Context I recently submitted my [first](https://go-review.googlesource.com/c/go/+/73890) [contribution](https://go-review.googlesource.com/c/go/+/73891) to Go and was surprised at how straight forward and refreshing Gerrit was in comparison to GitHub. I had delayed contributing because the process described at https://golang.org/doc/contribute.html appeared so different to what I was use to. In practice it wasn't. It only appeared that way because there was a layer of abstraction. Before contributing the main point of friction for me wasn't the use of Gerrit vs GitHub, but the fact that all of the examples centered around the use of `git-codereview`, a custom tool for interacting with the Go Gerrit instance. I realize this tool is optional, but it took time to read all of the text and note down which git commands each `git-codereview` command actually used. At the end it came down to: 1. Install two hooks 2. `git clone` 3. `git pull -r` 4. `git checkout -b ` 5. `git commit` 6. `git push -u origin HEAD:refs/for/master` (patch set 1) 7. `git commit --amend` 8. `git push -u origin HEAD:refs/for/master` (patch set 2) The above is almost identical to the workflows I use at work and on open source on GitHub, and it is instantly familiar to me as a git user. The contribution guidelines tell a different story: 1. `git codereview hooks` 2. `git clone` 3. `git sync` 4. `git change` 5. `git mail` (path set 1) 6. `git change` (to amend) 7. `git mail` (patch set 2) While the above is technically less commands, it's four new commands that I had never seen before and had to learn about. These commands abstract git away from plain git users, unnecessarily. ### How Some ideas for how the contributing guidelines document could be made more familiar to plain git users: * Replace examples using `git-codereview` with plain git commands where the corresponding git commands are simple and straight forward. e.g. `git sync` vs `git pull -r`, `git push` vs `git mail`, etc. * Display plain git commands side-by-side (not one after the other) in the same size, font, weight, etc. * Make `git-codereview` the recommended path for those not familiar with git, or power users. * Make plain git the recommended path for those familiar with git, with a suggestion to check out `git-codereview`. * Offer the pre-commit hook at a URL that can be curl'd like how the [commit-msg hook is available](http://go-review.googlesource.com/tools/hooks/commit-msg) so that it's simple for developers to install the commit hooks how they would any others for other projects. I've got a branch with changes to the contributing doc that I made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable. I'd love to be involved with improving the guidelines in this way if this is something that the community agrees with.",1.0,"doc: simplify contributing by offering clear plain git guidelines - ### What Change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git? ### What it is not This issue is not a request or proposal to replace Gerrit or the review process. This issue is not a request or proposal to remove the `git-codereview` tool or to make drastic changes to how anyone on the Go team or existing contributors go about contributing. ### Why There are other open issues proposing a switch to GitHub, or adding the ability to support pushing to GitHub. Based on my own experience I think much of the friction that GitHub users are experiencing is caused by the contributing guidelines centering around `git-codereview`, which abstracts git away from the developer. Abstracting git away from developers is jarring when developers know how to use that tool already. It gives them the experience that they are using something that is entirely different to what they use today, even though it is not. ### Context I recently submitted my [first](https://go-review.googlesource.com/c/go/+/73890) [contribution](https://go-review.googlesource.com/c/go/+/73891) to Go and was surprised at how straight forward and refreshing Gerrit was in comparison to GitHub. I had delayed contributing because the process described at https://golang.org/doc/contribute.html appeared so different to what I was use to. In practice it wasn't. It only appeared that way because there was a layer of abstraction. Before contributing the main point of friction for me wasn't the use of Gerrit vs GitHub, but the fact that all of the examples centered around the use of `git-codereview`, a custom tool for interacting with the Go Gerrit instance. I realize this tool is optional, but it took time to read all of the text and note down which git commands each `git-codereview` command actually used. At the end it came down to: 1. Install two hooks 2. `git clone` 3. `git pull -r` 4. `git checkout -b ` 5. `git commit` 6. `git push -u origin HEAD:refs/for/master` (patch set 1) 7. `git commit --amend` 8. `git push -u origin HEAD:refs/for/master` (patch set 2) The above is almost identical to the workflows I use at work and on open source on GitHub, and it is instantly familiar to me as a git user. The contribution guidelines tell a different story: 1. `git codereview hooks` 2. `git clone` 3. `git sync` 4. `git change` 5. `git mail` (path set 1) 6. `git change` (to amend) 7. `git mail` (patch set 2) While the above is technically less commands, it's four new commands that I had never seen before and had to learn about. These commands abstract git away from plain git users, unnecessarily. ### How Some ideas for how the contributing guidelines document could be made more familiar to plain git users: * Replace examples using `git-codereview` with plain git commands where the corresponding git commands are simple and straight forward. e.g. `git sync` vs `git pull -r`, `git push` vs `git mail`, etc. * Display plain git commands side-by-side (not one after the other) in the same size, font, weight, etc. * Make `git-codereview` the recommended path for those not familiar with git, or power users. * Make plain git the recommended path for those familiar with git, with a suggestion to check out `git-codereview`. * Offer the pre-commit hook at a URL that can be curl'd like how the [commit-msg hook is available](http://go-review.googlesource.com/tools/hooks/commit-msg) so that it's simple for developers to install the commit hooks how they would any others for other projects. I've got a branch with changes to the contributing doc that I made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable. I'd love to be involved with improving the guidelines in this way if this is something that the community agrees with.",1,doc simplify contributing by offering clear plain git guidelines what change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git what it is not this issue is not a request or proposal to replace gerrit or the review process this issue is not a request or proposal to remove the git codereview tool or to make drastic changes to how anyone on the go team or existing contributors go about contributing why there are other open issues proposing a switch to github or adding the ability to support pushing to github based on my own experience i think much of the friction that github users are experiencing is caused by the contributing guidelines centering around git codereview which abstracts git away from the developer abstracting git away from developers is jarring when developers know how to use that tool already it gives them the experience that they are using something that is entirely different to what they use today even though it is not context i recently submitted my to go and was surprised at how straight forward and refreshing gerrit was in comparison to github i had delayed contributing because the process described at appeared so different to what i was use to in practice it wasn t it only appeared that way because there was a layer of abstraction before contributing the main point of friction for me wasn t the use of gerrit vs github but the fact that all of the examples centered around the use of git codereview a custom tool for interacting with the go gerrit instance i realize this tool is optional but it took time to read all of the text and note down which git commands each git codereview command actually used at the end it came down to install two hooks git clone git pull r git checkout b git commit git push u origin head refs for master patch set git commit amend git push u origin head refs for master patch set the above is almost identical to the workflows i use at work and on open source on github and it is instantly familiar to me as a git user the contribution guidelines tell a different story git codereview hooks git clone git sync git change git mail path set git change to amend git mail patch set while the above is technically less commands it s four new commands that i had never seen before and had to learn about these commands abstract git away from plain git users unnecessarily how some ideas for how the contributing guidelines document could be made more familiar to plain git users replace examples using git codereview with plain git commands where the corresponding git commands are simple and straight forward e g git sync vs git pull r git push vs git mail etc display plain git commands side by side not one after the other in the same size font weight etc make git codereview the recommended path for those not familiar with git or power users make plain git the recommended path for those familiar with git with a suggestion to check out git codereview offer the pre commit hook at a url that can be curl d like how the so that it s simple for developers to install the commit hooks how they would any others for other projects i ve got a branch with changes to the contributing doc that i made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable i d love to be involved with improving the guidelines in this way if this is something that the community agrees with ,1 173105,14402445562.0,IssuesEvent,2020-12-03 14:54:55,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document os changes for Go 1.16,Documentation NeedsFix help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
os

TODO: https://golang.org/cl/242998: export errFinished as ErrProcessDone

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document os changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
os

TODO: https://golang.org/cl/242998: export errFinished as ErrProcessDone

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document os changes for go as of filing this issue the contained the following html os todo a href export errfinished as errprocessdone per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 333298,24370014352.0,IssuesEvent,2022-10-03 18:25:19,golang/go,https://api.github.com/repos/golang/go,closed,go/build: documentation for Context still mentions +build rather than go:build,Documentation NeedsFix,"I noticed that some of the internal commentary in `go/build/build.go` still refers (exclusively) to `+build` lines rather than `go:build`. In one place this leaks in external documentation: the documentation for [`go/build.Context`](https://pkg.go.dev/go/build#Context). We should update that to refer to `go:build`, to be consistent with the package documentation. Milestoning for 1.20 since it is not urgent. CC @bcmills ",1.0,"go/build: documentation for Context still mentions +build rather than go:build - I noticed that some of the internal commentary in `go/build/build.go` still refers (exclusively) to `+build` lines rather than `go:build`. In one place this leaks in external documentation: the documentation for [`go/build.Context`](https://pkg.go.dev/go/build#Context). We should update that to refer to `go:build`, to be consistent with the package documentation. Milestoning for 1.20 since it is not urgent. CC @bcmills ",1,go build documentation for context still mentions build rather than go build i noticed that some of the internal commentary in go build build go still refers exclusively to build lines rather than go build in one place this leaks in external documentation the documentation for we should update that to refer to go build to be consistent with the package documentation milestoning for since it is not urgent cc bcmills ,1 246169,20826720817.0,IssuesEvent,2022-03-18 22:06:45,golang/go,https://api.github.com/repos/golang/go,closed,misc/cgo/testsanitizers: testsanitizers/msan occasionally hangs,Testing NeedsInvestigation,"From the `linux-amd64-sid` builder (https://build.golang.org/log/7d292c10eb4cdda28eff9eb8041ad614d3365b44): ``` ##### ../misc/cgo/testasan ##### Test ""testsanitizers/msan"" ran over 20m0s limit (20m0.001476068s) ```",1.0,"misc/cgo/testsanitizers: testsanitizers/msan occasionally hangs - From the `linux-amd64-sid` builder (https://build.golang.org/log/7d292c10eb4cdda28eff9eb8041ad614d3365b44): ``` ##### ../misc/cgo/testasan ##### Test ""testsanitizers/msan"" ran over 20m0s limit (20m0.001476068s) ```",0,misc cgo testsanitizers testsanitizers msan occasionally hangs from the linux sid builder misc cgo testasan test testsanitizers msan ran over limit ,0 53776,7855804557.0,IssuesEvent,2018-06-21 04:11:22,golang/go,https://api.github.com/repos/golang/go,reopened,time: document Location's effect on Time more?,Documentation,"Using Go 1.9 Documenation states: ``` func (t Time) In(loc *Location) Time In returns t with the location information set to loc. ``` My interpretation is that the function `In` will change the location information but keep all other details the same. The consequence is that it will have a different Unix time usually since they represent different points in time. ``` startDate := .... //startDate (time.Time) 2018-01-01 00:00:00 +1100 AEDT _startDate := time.Date(startDate.Year(), startDate.Month(), startDate.Day(), startDate.Hour(), startDate.Minute(), startDate.Second(), startDate.Nanosecond(), time.UTC) fmt.Println(""startDate"", spew.Sdump(startDate), spew.Sdump(startDate.In(time.UTC)), spew.Sdump(_startDate)) ``` Output: ``` startDate (time.Time) 2018-01-01 00:00:00 +1100 AEDT (time.Time) 2017-12-31 13:00:00 +0000 UTC (time.Time) 2018-01-01 00:00:00 +0000 UTC ``` Expected output: `startDate.In(time.UTC))` and `_startDate` should produce same result ",1.0,"time: document Location's effect on Time more? - Using Go 1.9 Documenation states: ``` func (t Time) In(loc *Location) Time In returns t with the location information set to loc. ``` My interpretation is that the function `In` will change the location information but keep all other details the same. The consequence is that it will have a different Unix time usually since they represent different points in time. ``` startDate := .... //startDate (time.Time) 2018-01-01 00:00:00 +1100 AEDT _startDate := time.Date(startDate.Year(), startDate.Month(), startDate.Day(), startDate.Hour(), startDate.Minute(), startDate.Second(), startDate.Nanosecond(), time.UTC) fmt.Println(""startDate"", spew.Sdump(startDate), spew.Sdump(startDate.In(time.UTC)), spew.Sdump(_startDate)) ``` Output: ``` startDate (time.Time) 2018-01-01 00:00:00 +1100 AEDT (time.Time) 2017-12-31 13:00:00 +0000 UTC (time.Time) 2018-01-01 00:00:00 +0000 UTC ``` Expected output: `startDate.In(time.UTC))` and `_startDate` should produce same result ",1,time document location s effect on time more using go documenation states func t time in loc location time in returns t with the location information set to loc my interpretation is that the function in will change the location information but keep all other details the same the consequence is that it will have a different unix time usually since they represent different points in time startdate startdate time time aedt startdate time date startdate year startdate month startdate day startdate hour startdate minute startdate second startdate nanosecond time utc fmt println startdate spew sdump startdate spew sdump startdate in time utc spew sdump startdate output startdate time time aedt time time utc time time utc expected output startdate in time utc and startdate should produce same result ,1 271156,20624022062.0,IssuesEvent,2022-03-07 20:25:30,golang/go,https://api.github.com/repos/golang/go,closed,"go/types, types2: document predicates on generic types",Documentation NeedsInvestigation,"Right now, go/types has limited functionality for computing predicates ""modulo type parameters"": signatures are considered identical modulo renaming of type parameters in their type parameter list: ```go func F[A ~int](A) {} func G[B ~int](B) {} func H[C int](C) {} type T[D ~int] func(D) ``` In this example, the types of `F` and `G` are considered identical, because they have pairwise identical type parameter constraints and their signatures are identical after substituting type parameters. However, the signature of `F` is NOT identical to the signature of `H` (constraints don't match), and NOT identical to the underlying type of `T` (the signature itself does not have a type parameter list -- it uses type parameters from the declaration for `T`). [CL 379540](https://go.dev/cl/379540) was intended to clean up some logic that existed to work around an earlier limitation that we didn't have instantiated methods. However, it inadvertently removed a ""feature"" that APIs like `AssignableTo` would somewhat work with uninstantiated types: We ran into this example in kythe: ``` type Interface[T any] interface { Accept(T) } type Container[T any] struct { Element T } func (c Container[T]) Accept(t T) { c.Element = t } ``` Previously, we would report that `Container` is assignable to `Interface` (`AssignableTo(Container, Interface) == true`), because they would unify. However, this could be wrong, as in the following example: ``` type InterfaceInt[T ~int] interface { Accept(T) } type ContainerString[T ~string] struct { Element T } func (c ContainerString[T]) Accept(t T) { c.Element = t } ``` We would _also_ have `AssignableTo(ContainerString, InterfaceInt) == true`, even though there is no instantiation for which this holds. Related: - https://github.com/golang/go/issues/50658#issuecomment-1016975461. We don't expose any API for unification, and it would useful in several places. - #49912 -- an outstanding bug for comparing method signatures modulo type parameters. However, notably fixing this bug would **not** address the behavior with respect to the `Interface` type above: the methods on `Interface` are parameterized by the type declaration parameters, not receiver type parameters. ~Alternatively, callers could ""instantiate"" the types with identical arguments, but then the burden is pushed onto the caller to find type arguments that satisfy both type parameter lists, which is arbitrarily complicated.~ (EDIT: this wouldn't even really work: type parameters could be in arbitrary order, and so for the caller to even know which type parameters should correspond, they'd have to do the unification themselves). I don't believe this affects type-checking, but matters for the API and for tools. We need to reconsider what is most useful here. My initial thoughts are as follows: rather than what we currently do for function signatures, generalize to a limited form of unification in `Identical`, where type parameters are joined and then substituted in constraints. This runs into a problem of ""free type parameters"" ``` func _[A *C, B *C, C any]() { var X func(A) var Y func(B) } type I[P *Q, Q any] interface{ m(P) } ``` The type of `X` and `Y` should not be identical. What about the type of `X` and the signature of `I.m`? (EDIT: `X` and `Y` do NOT have identical types). CC @griesemer @mdempsky ",1.0,"go/types, types2: document predicates on generic types - Right now, go/types has limited functionality for computing predicates ""modulo type parameters"": signatures are considered identical modulo renaming of type parameters in their type parameter list: ```go func F[A ~int](A) {} func G[B ~int](B) {} func H[C int](C) {} type T[D ~int] func(D) ``` In this example, the types of `F` and `G` are considered identical, because they have pairwise identical type parameter constraints and their signatures are identical after substituting type parameters. However, the signature of `F` is NOT identical to the signature of `H` (constraints don't match), and NOT identical to the underlying type of `T` (the signature itself does not have a type parameter list -- it uses type parameters from the declaration for `T`). [CL 379540](https://go.dev/cl/379540) was intended to clean up some logic that existed to work around an earlier limitation that we didn't have instantiated methods. However, it inadvertently removed a ""feature"" that APIs like `AssignableTo` would somewhat work with uninstantiated types: We ran into this example in kythe: ``` type Interface[T any] interface { Accept(T) } type Container[T any] struct { Element T } func (c Container[T]) Accept(t T) { c.Element = t } ``` Previously, we would report that `Container` is assignable to `Interface` (`AssignableTo(Container, Interface) == true`), because they would unify. However, this could be wrong, as in the following example: ``` type InterfaceInt[T ~int] interface { Accept(T) } type ContainerString[T ~string] struct { Element T } func (c ContainerString[T]) Accept(t T) { c.Element = t } ``` We would _also_ have `AssignableTo(ContainerString, InterfaceInt) == true`, even though there is no instantiation for which this holds. Related: - https://github.com/golang/go/issues/50658#issuecomment-1016975461. We don't expose any API for unification, and it would useful in several places. - #49912 -- an outstanding bug for comparing method signatures modulo type parameters. However, notably fixing this bug would **not** address the behavior with respect to the `Interface` type above: the methods on `Interface` are parameterized by the type declaration parameters, not receiver type parameters. ~Alternatively, callers could ""instantiate"" the types with identical arguments, but then the burden is pushed onto the caller to find type arguments that satisfy both type parameter lists, which is arbitrarily complicated.~ (EDIT: this wouldn't even really work: type parameters could be in arbitrary order, and so for the caller to even know which type parameters should correspond, they'd have to do the unification themselves). I don't believe this affects type-checking, but matters for the API and for tools. We need to reconsider what is most useful here. My initial thoughts are as follows: rather than what we currently do for function signatures, generalize to a limited form of unification in `Identical`, where type parameters are joined and then substituted in constraints. This runs into a problem of ""free type parameters"" ``` func _[A *C, B *C, C any]() { var X func(A) var Y func(B) } type I[P *Q, Q any] interface{ m(P) } ``` The type of `X` and `Y` should not be identical. What about the type of `X` and the signature of `I.m`? (EDIT: `X` and `Y` do NOT have identical types). CC @griesemer @mdempsky ",1,go types document predicates on generic types right now go types has limited functionality for computing predicates modulo type parameters signatures are considered identical modulo renaming of type parameters in their type parameter list go func f a func g b func h c type t func d in this example the types of f and g are considered identical because they have pairwise identical type parameter constraints and their signatures are identical after substituting type parameters however the signature of f is not identical to the signature of h constraints don t match and not identical to the underlying type of t the signature itself does not have a type parameter list it uses type parameters from the declaration for t was intended to clean up some logic that existed to work around an earlier limitation that we didn t have instantiated methods however it inadvertently removed a feature that apis like assignableto would somewhat work with uninstantiated types we ran into this example in kythe type interface interface accept t type container struct element t func c container accept t t c element t previously we would report that container is assignable to interface assignableto container interface true because they would unify however this could be wrong as in the following example type interfaceint interface accept t type containerstring struct element t func c containerstring accept t t c element t we would also have assignableto containerstring interfaceint true even though there is no instantiation for which this holds related we don t expose any api for unification and it would useful in several places an outstanding bug for comparing method signatures modulo type parameters however notably fixing this bug would not address the behavior with respect to the interface type above the methods on interface are parameterized by the type declaration parameters not receiver type parameters alternatively callers could instantiate the types with identical arguments but then the burden is pushed onto the caller to find type arguments that satisfy both type parameter lists which is arbitrarily complicated edit this wouldn t even really work type parameters could be in arbitrary order and so for the caller to even know which type parameters should correspond they d have to do the unification themselves i don t believe this affects type checking but matters for the api and for tools we need to reconsider what is most useful here my initial thoughts are as follows rather than what we currently do for function signatures generalize to a limited form of unification in identical where type parameters are joined and then substituted in constraints this runs into a problem of free type parameters func var x func a var y func b type i interface m p the type of x and y should not be identical what about the type of x and the signature of i m edit x and y do not have identical types cc griesemer mdempsky ,1 71505,18763665053.0,IssuesEvent,2021-11-05 19:50:06,golang/go,https://api.github.com/repos/golang/go,opened,x/build: coordinator shouldn't wait forever for builders that do not snapshot,Builders,"In https://golang.org/cl/361754 (#49207), a builder was corrected to SkipSnapshot when it doesn't build the go repo. The following code will loop forever in this scenario, as a snapshot will never be uploaded for this configuration: https://cs.opensource.google/go/x/build/+/master:cmd/coordinator/coordinator.go;l=1016;drc=0f6a98d88fcd2f596743aecbdc5b3def2458eded A test should fail if this invalid configuration occurs. ",1.0,"x/build: coordinator shouldn't wait forever for builders that do not snapshot - In https://golang.org/cl/361754 (#49207), a builder was corrected to SkipSnapshot when it doesn't build the go repo. The following code will loop forever in this scenario, as a snapshot will never be uploaded for this configuration: https://cs.opensource.google/go/x/build/+/master:cmd/coordinator/coordinator.go;l=1016;drc=0f6a98d88fcd2f596743aecbdc5b3def2458eded A test should fail if this invalid configuration occurs. ",0,x build coordinator shouldn t wait forever for builders that do not snapshot in a builder was corrected to skipsnapshot when it doesn t build the go repo the following code will loop forever in this scenario as a snapshot will never be uploaded for this configuration a test should fail if this invalid configuration occurs ,0 132842,12519748930.0,IssuesEvent,2020-06-03 14:52:44,golang/go,https://api.github.com/repos/golang/go,closed,cmd/internal/obj/arm64: minor mistake in pre-increment example,Documentation NeedsFix arch-arm64,"The following URL contains a minor mistake: https://golang.org/pkg/cmd/internal/obj/arm64/ Under point 2 (""Go uses .P and .W suffixes to indicate post-increment and pre-increment."") there is a mismatch between the Go assembly and the GNU syntax (for the pre-increment with .W suffix). Specifically Go assembly loads a signed-byte with `MOVB` whereas the GNU syntax loads an (unsigned) 64-bit double-word with `ldr`. So either the example should be this ``` MOVB.W 16(R16), R10 <=> ldrsb x10, [x16,#16]! ``` or ``` MOVD.W 16(R16), R10 <=> ldr x10, [x16,#16]! ``` or even ``` MOVBU.W 16(R16), R10 <=> ldrb x10, [x16,#16]! ``` ",1.0,"cmd/internal/obj/arm64: minor mistake in pre-increment example - The following URL contains a minor mistake: https://golang.org/pkg/cmd/internal/obj/arm64/ Under point 2 (""Go uses .P and .W suffixes to indicate post-increment and pre-increment."") there is a mismatch between the Go assembly and the GNU syntax (for the pre-increment with .W suffix). Specifically Go assembly loads a signed-byte with `MOVB` whereas the GNU syntax loads an (unsigned) 64-bit double-word with `ldr`. So either the example should be this ``` MOVB.W 16(R16), R10 <=> ldrsb x10, [x16,#16]! ``` or ``` MOVD.W 16(R16), R10 <=> ldr x10, [x16,#16]! ``` or even ``` MOVBU.W 16(R16), R10 <=> ldrb x10, [x16,#16]! ``` ",1,cmd internal obj minor mistake in pre increment example the following url contains a minor mistake under point go uses p and w suffixes to indicate post increment and pre increment there is a mismatch between the go assembly and the gnu syntax for the pre increment with w suffix specifically go assembly loads a signed byte with movb whereas the gnu syntax loads an unsigned bit double word with ldr so either the example should be this movb w ldrsb or movd w ldr or even movbu w ldrb ,1 41588,6922201468.0,IssuesEvent,2017-11-30 01:47:26,golang/go,https://api.github.com/repos/golang/go,closed,strings: please improve documentation for strings.Builder,Documentation HelpWanted NeedsFix,"I think that the documentation of `strings.Builder` could be improved by adding a few sentences that compare it to `bytes.Buffer`. More exactly, I'd like to see: * a pointer to `bytes.Buffer`; * a list of the methods that `strings.Builder` is lacking as compared to `bytes.Buffer`. ",1.0,"strings: please improve documentation for strings.Builder - I think that the documentation of `strings.Builder` could be improved by adding a few sentences that compare it to `bytes.Buffer`. More exactly, I'd like to see: * a pointer to `bytes.Buffer`; * a list of the methods that `strings.Builder` is lacking as compared to `bytes.Buffer`. ",1,strings please improve documentation for strings builder i think that the documentation of strings builder could be improved by adding a few sentences that compare it to bytes buffer more exactly i d like to see a pointer to bytes buffer a list of the methods that strings builder is lacking as compared to bytes buffer ,1 324583,24008001258.0,IssuesEvent,2022-09-14 16:13:48,golang/go,https://api.github.com/repos/golang/go,closed,net/http: DefaultTransport documentation should describe HTTPS_PROXY,Documentation NeedsDecision," ### What version of Go are you using (`go version`)? 
go version go1.12.4 linux/amd64
### Does this issue reproduce with the latest release? Affirmative. ### What operating system and processor architecture are you using (`go env`)?
go env Output
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/howard/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/howard/gopath""
GOPROXY=""""
GORACE=""""
GOROOT=""/home/howard/go""
GOTMPDIR=""""
GOTOOLDIR=""/home/howard/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build043222332=/tmp/go-build -gno-record-gcc-switches""
### What did you do? In https://golang.org/pkg/net/http/#RoundTripper, the online manual explains the following for RoundTripper: > DefaultTransport is the default implementation of Transport and is used by DefaultClient. It establishes network connections as needed and caches them for reuse by subsequent calls. It uses HTTP proxies as directed by the $HTTP_PROXY and $NO_PROXY (or $http_proxy and $no_proxy) environment variables. Although DefaultTransport uses proxy settings from system environment via [ProxyFromEnvironment](https://golang.org/pkg/net/http/#ProxyFromEnvironment), which not even recognises HTTP proxy, but HTTPS proxy also: > ProxyFromEnvironment returns the URL of the proxy to use for a given request, as indicated by the environment variables HTTP_PROXY, HTTPS_PROXY and NO_PROXY (or the lowercase versions thereof). HTTPS_PROXY takes precedence over HTTP_PROXY for https requests. `DefaultTransport` indeed behaves correctly and recognises both HTTPS and HTTP proxy settings from system environment. Therefore, please elaborate about the support of HTTPS proxy in the documentation for `DefaultTransport`. Thanks!",1.0,"net/http: DefaultTransport documentation should describe HTTPS_PROXY - ### What version of Go are you using (`go version`)? 
go version go1.12.4 linux/amd64
### Does this issue reproduce with the latest release? Affirmative. ### What operating system and processor architecture are you using (`go env`)?
go env Output
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/howard/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/howard/gopath""
GOPROXY=""""
GORACE=""""
GOROOT=""/home/howard/go""
GOTMPDIR=""""
GOTOOLDIR=""/home/howard/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build043222332=/tmp/go-build -gno-record-gcc-switches""
### What did you do? In https://golang.org/pkg/net/http/#RoundTripper, the online manual explains the following for RoundTripper: > DefaultTransport is the default implementation of Transport and is used by DefaultClient. It establishes network connections as needed and caches them for reuse by subsequent calls. It uses HTTP proxies as directed by the $HTTP_PROXY and $NO_PROXY (or $http_proxy and $no_proxy) environment variables. Although DefaultTransport uses proxy settings from system environment via [ProxyFromEnvironment](https://golang.org/pkg/net/http/#ProxyFromEnvironment), which not even recognises HTTP proxy, but HTTPS proxy also: > ProxyFromEnvironment returns the URL of the proxy to use for a given request, as indicated by the environment variables HTTP_PROXY, HTTPS_PROXY and NO_PROXY (or the lowercase versions thereof). HTTPS_PROXY takes precedence over HTTP_PROXY for https requests. `DefaultTransport` indeed behaves correctly and recognises both HTTPS and HTTP proxy settings from system environment. Therefore, please elaborate about the support of HTTPS proxy in the documentation for `DefaultTransport`. Thanks!",1,net http defaulttransport documentation should describe https proxy what version of go are you using go version go version linux does this issue reproduce with the latest release affirmative what operating system and processor architecture are you using go env go env output goarch gobin gocache home howard cache go build goexe goflags gohostarch gohostos linux goos linux gopath home howard gopath goproxy gorace goroot home howard go gotmpdir gotooldir home howard go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do in the online manual explains the following for roundtripper defaulttransport is the default implementation of transport and is used by defaultclient it establishes network connections as needed and caches them for reuse by subsequent calls it uses http proxies as directed by the http proxy and no proxy or http proxy and no proxy environment variables although defaulttransport uses proxy settings from system environment via which not even recognises http proxy but https proxy also proxyfromenvironment returns the url of the proxy to use for a given request as indicated by the environment variables http proxy https proxy and no proxy or the lowercase versions thereof https proxy takes precedence over http proxy for https requests defaulttransport indeed behaves correctly and recognises both https and http proxy settings from system environment therefore please elaborate about the support of https proxy in the documentation for defaulttransport thanks ,1 52780,13050473908.0,IssuesEvent,2020-07-29 15:32:54,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/releasebot: remove obsolete check that the major version is listed on the project page,Builders NeedsFix release-blocker,"The https://golang.org/project/ page has a ""Version history"" section that lists major Go releases that have been released. Prior to [CL 229483](https://golang.org/cl/229483), it needed to be manually updated before each final major release, and so to catch potential mistakes releasebot has a safety check that aborts the release process if the major version isn't listed: ```Go func (w *Work) checkDocs() { // Check that the major version is listed on the project page. data, err := ioutil.ReadFile(filepath.Join(w.Dir, ""gitwork"", ""doc/contrib.html"")) if err != nil { w.log.Panic(err) } major := major(w.Version) if !strings.Contains(string(data), major) { w.logError(""doc/contrib.html does not list major version %s"", major) } } ``` _(Source: [golang.org/x/build/cmd/releasebot/main.go#L595-L605](https://github.com/golang/build/blob/b405858d836876f4a9391a8c61cb626a47a3fea1/cmd/releasebot/main.go#L595-L605).)_ The doc/contrib.html file no longer needs to be manually updated, and it [doesn't even exist](https://github.com/golang/go/tree/master/doc) in the main repo as it was moved to x/website in [CL 229485](https://golang.org/cl/229485). The check needs to be removed. /cc @toothrot @cagedmantis @andybons",1.0,"x/build/cmd/releasebot: remove obsolete check that the major version is listed on the project page - The https://golang.org/project/ page has a ""Version history"" section that lists major Go releases that have been released. Prior to [CL 229483](https://golang.org/cl/229483), it needed to be manually updated before each final major release, and so to catch potential mistakes releasebot has a safety check that aborts the release process if the major version isn't listed: ```Go func (w *Work) checkDocs() { // Check that the major version is listed on the project page. data, err := ioutil.ReadFile(filepath.Join(w.Dir, ""gitwork"", ""doc/contrib.html"")) if err != nil { w.log.Panic(err) } major := major(w.Version) if !strings.Contains(string(data), major) { w.logError(""doc/contrib.html does not list major version %s"", major) } } ``` _(Source: [golang.org/x/build/cmd/releasebot/main.go#L595-L605](https://github.com/golang/build/blob/b405858d836876f4a9391a8c61cb626a47a3fea1/cmd/releasebot/main.go#L595-L605).)_ The doc/contrib.html file no longer needs to be manually updated, and it [doesn't even exist](https://github.com/golang/go/tree/master/doc) in the main repo as it was moved to x/website in [CL 229485](https://golang.org/cl/229485). The check needs to be removed. /cc @toothrot @cagedmantis @andybons",0,x build cmd releasebot remove obsolete check that the major version is listed on the project page the page has a version history section that lists major go releases that have been released prior to it needed to be manually updated before each final major release and so to catch potential mistakes releasebot has a safety check that aborts the release process if the major version isn t listed go func w work checkdocs check that the major version is listed on the project page data err ioutil readfile filepath join w dir gitwork doc contrib html if err nil w log panic err major major w version if strings contains string data major w logerror doc contrib html does not list major version s major source the doc contrib html file no longer needs to be manually updated and it in the main repo as it was moved to x website in the check needs to be removed cc toothrot cagedmantis andybons,0 33469,6206524120.0,IssuesEvent,2017-07-06 18:37:34,golang/go,https://api.github.com/repos/golang/go,closed,runtime/pprof: document predefined profiles under Profiles,Documentation,"It is backwards for pprof.Profile to document the predefined profiles rather than pprof.Profiles or pprof.Lookup. Given the documentation of the predefined is required by multiple APIs under the pprof package, we might consider documenting them under the package doc. ",1.0,"runtime/pprof: document predefined profiles under Profiles - It is backwards for pprof.Profile to document the predefined profiles rather than pprof.Profiles or pprof.Lookup. Given the documentation of the predefined is required by multiple APIs under the pprof package, we might consider documenting them under the package doc. ",1,runtime pprof document predefined profiles under profiles it is backwards for pprof profile to document the predefined profiles rather than pprof profiles or pprof lookup given the documentation of the predefined is required by multiple apis under the pprof package we might consider documenting them under the package doc ,1 57941,8214682082.0,IssuesEvent,2018-09-05 00:49:09,golang/go,https://api.github.com/repos/golang/go,closed,go/ast: TypeSpec.Doc is nil? Have to grab documentation at GenDecl,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? 1.11 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin ### Question Noticed in the AST for type instantiated structures, that if I go to the `Doc` field in `ast.TypeSpec` the value is `nil`. I have to visit the `ast.GenDecl` node instead to grab doc fields. Is this intended? If so, why does `ast.TypeSpec` have a `Doc` field? Should `Doc` along with `Comment` be deprecated, as in mentioned in the docs, since comments/documentation really do not have anything to do with the type specification? This can reproduce by parsing the code sample below ```go package foo // documentation goes here type Foo struct{} func main() { f := Foo{} } ``` ### expectation `ast.TypeSpec` contain non-`nil` value for `Doc` when documentation is provided. ",1.0,"go/ast: TypeSpec.Doc is nil? Have to grab documentation at GenDecl - ### What version of Go are you using (`go version`)? 1.11 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin ### Question Noticed in the AST for type instantiated structures, that if I go to the `Doc` field in `ast.TypeSpec` the value is `nil`. I have to visit the `ast.GenDecl` node instead to grab doc fields. Is this intended? If so, why does `ast.TypeSpec` have a `Doc` field? Should `Doc` along with `Comment` be deprecated, as in mentioned in the docs, since comments/documentation really do not have anything to do with the type specification? This can reproduce by parsing the code sample below ```go package foo // documentation goes here type Foo struct{} func main() { f := Foo{} } ``` ### expectation `ast.TypeSpec` contain non-`nil` value for `Doc` when documentation is provided. ",1,go ast typespec doc is nil have to grab documentation at gendecl what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env darwin question noticed in the ast for type instantiated structures that if i go to the doc field in ast typespec the value is nil i have to visit the ast gendecl node instead to grab doc fields is this intended if so why does ast typespec have a doc field should doc along with comment be deprecated as in mentioned in the docs since comments documentation really do not have anything to do with the type specification this can reproduce by parsing the code sample below go package foo documentation goes here type foo struct func main f foo expectation ast typespec contain non nil value for doc when documentation is provided ,1 21594,4727235745.0,IssuesEvent,2016-10-18 12:56:51,golang/go,https://api.github.com/repos/golang/go,closed,testing: test.memprofilerate documentation is not accurate,Documentation NeedsFix,"The docs for the -test.memprofilerate flag say ""if >= 0"", but the code is simply greater, not greater than or equal: ``` ~/go/src/testing$ git grep memProfileRate testing.go: memProfileRate = flag.Int(""test.memprofilerate"", 0, ""if >=0, sets runtime.MemProfileRate"") testing.go: if *memProfileRate > 0 { testing.go: runtime.MemProfileRate = *memProfileRate ``` And the default is 512KB, not 0: https://golang.org/pkg/runtime/#pkg-variables ",1.0,"testing: test.memprofilerate documentation is not accurate - The docs for the -test.memprofilerate flag say ""if >= 0"", but the code is simply greater, not greater than or equal: ``` ~/go/src/testing$ git grep memProfileRate testing.go: memProfileRate = flag.Int(""test.memprofilerate"", 0, ""if >=0, sets runtime.MemProfileRate"") testing.go: if *memProfileRate > 0 { testing.go: runtime.MemProfileRate = *memProfileRate ``` And the default is 512KB, not 0: https://golang.org/pkg/runtime/#pkg-variables ",1,testing test memprofilerate documentation is not accurate the docs for the test memprofilerate flag say if but the code is simply greater not greater than or equal go src testing git grep memprofilerate testing go memprofilerate flag int test memprofilerate if sets runtime memprofilerate testing go if memprofilerate testing go runtime memprofilerate memprofilerate and the default is not ,1 93686,10773251761.0,IssuesEvent,2019-11-02 19:31:02,golang/go,https://api.github.com/repos/golang/go,closed,"doc: outdated assessment of ARCHs maturity in ""Installing Go from source"" list",Documentation NeedsFix,"The [Installing Go from source](https://golang.org/doc/install/source) document contains, in the [introduction section](https://golang.org/doc/install/source#introduction), a list of supported architectures. It says: > The Go compilers support nine instruction sets. There are important differences in the quality of the compilers for the different architectures. The assessment of the various ports' ""maturity grade"" is outdated and somewhat misleading. A few issues: - s390x is listed as ""new"" and ""not as well exercised as other ports.""; but in reality is probably one of the ports that receive the most attention. - the arm64 port is mature, but it is listed as ""not as well exercised as other ports""; it also says ""New in 1.5"", it seems unnecessary to note the newness of something that is 4 years old. - for 386 it says ""Comparable to the amd64 port"" (which is the most mature one), but in reality 386 is probably much less exercised than ports like arm / arm64 / s390x. - In general, the point of the list is not to present a chronological history of new ports, but to help the reader assess the newness and maturity of the archs. For this reason, mentioning that mips64 is ""New in 1.6"" is not useful (at this point, anything introduced in 1.6 is quite old). I suggest we update the list to reflect the current status of the various ports. I'll send a CL.",1.0,"doc: outdated assessment of ARCHs maturity in ""Installing Go from source"" list - The [Installing Go from source](https://golang.org/doc/install/source) document contains, in the [introduction section](https://golang.org/doc/install/source#introduction), a list of supported architectures. It says: > The Go compilers support nine instruction sets. There are important differences in the quality of the compilers for the different architectures. The assessment of the various ports' ""maturity grade"" is outdated and somewhat misleading. A few issues: - s390x is listed as ""new"" and ""not as well exercised as other ports.""; but in reality is probably one of the ports that receive the most attention. - the arm64 port is mature, but it is listed as ""not as well exercised as other ports""; it also says ""New in 1.5"", it seems unnecessary to note the newness of something that is 4 years old. - for 386 it says ""Comparable to the amd64 port"" (which is the most mature one), but in reality 386 is probably much less exercised than ports like arm / arm64 / s390x. - In general, the point of the list is not to present a chronological history of new ports, but to help the reader assess the newness and maturity of the archs. For this reason, mentioning that mips64 is ""New in 1.6"" is not useful (at this point, anything introduced in 1.6 is quite old). I suggest we update the list to reflect the current status of the various ports. I'll send a CL.",1,doc outdated assessment of archs maturity in installing go from source list the document contains in the a list of supported architectures it says the go compilers support nine instruction sets there are important differences in the quality of the compilers for the different architectures the assessment of the various ports maturity grade is outdated and somewhat misleading a few issues is listed as new and not as well exercised as other ports but in reality is probably one of the ports that receive the most attention the port is mature but it is listed as not as well exercised as other ports it also says new in it seems unnecessary to note the newness of something that is years old for it says comparable to the port which is the most mature one but in reality is probably much less exercised than ports like arm in general the point of the list is not to present a chronological history of new ports but to help the reader assess the newness and maturity of the archs for this reason mentioning that is new in is not useful at this point anything introduced in is quite old i suggest we update the list to reflect the current status of the various ports i ll send a cl ,1 43713,7059292736.0,IssuesEvent,2018-01-05 00:37:01,golang/go,https://api.github.com/repos/golang/go,closed,net/http: fix docs on Transport connection reuse specifics,Documentation,"### What version of Go are you using (`go version`)? go version go1.7 darwin/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ### What did you do? ``` package main import ( ""time"" ""fmt"" ""io/ioutil"" ""net/http"" ) func main() { resp, err := http.Get(""http://127.0.0.1:8588"") if err != nil { panic(err) } _, err = ioutil.ReadAll(resp.Body) if err != nil { panic(err) } resp2, err := http.Get(""http://127.0.0.1:8588"") if err != nil { panic(err) } _, err = ioutil.ReadAll(resp2.Body) if err != nil { panic(err) } fmt.Println(""before time sleep"") time.Sleep(time.Second * 35) } ``` in GO net/http Response Body annotation says: > It is the caller's responsibility to close Body. The default HTTP client's Transport does not attempt to reuse HTTP/1.0 or HTTP/1.1 TCP connections (""keep-alive"") unless the Body is read to completion and is closed. yeah, it say we must read body complete AND close body. in the above code, after read resp.Body I don't close the resp.Body. so, the http client should't reuse the tcp connection. so there will be two tcp connection handshark in wireshark, but I only see ONE. so, maybe the net/http's comment has something wrong? thank you. ",1.0,"net/http: fix docs on Transport connection reuse specifics - ### What version of Go are you using (`go version`)? go version go1.7 darwin/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ### What did you do? ``` package main import ( ""time"" ""fmt"" ""io/ioutil"" ""net/http"" ) func main() { resp, err := http.Get(""http://127.0.0.1:8588"") if err != nil { panic(err) } _, err = ioutil.ReadAll(resp.Body) if err != nil { panic(err) } resp2, err := http.Get(""http://127.0.0.1:8588"") if err != nil { panic(err) } _, err = ioutil.ReadAll(resp2.Body) if err != nil { panic(err) } fmt.Println(""before time sleep"") time.Sleep(time.Second * 35) } ``` in GO net/http Response Body annotation says: > It is the caller's responsibility to close Body. The default HTTP client's Transport does not attempt to reuse HTTP/1.0 or HTTP/1.1 TCP connections (""keep-alive"") unless the Body is read to completion and is closed. yeah, it say we must read body complete AND close body. in the above code, after read resp.Body I don't close the resp.Body. so, the http client should't reuse the tcp connection. so there will be two tcp connection handshark in wireshark, but I only see ONE. so, maybe the net/http's comment has something wrong? thank you. ",1,net http fix docs on transport connection reuse specifics what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env what did you do package main import time fmt io ioutil net http func main resp err http get if err nil panic err err ioutil readall resp body if err nil panic err err http get if err nil panic err err ioutil readall body if err nil panic err fmt println before time sleep time sleep time second in go net http response body annotation says it is the caller s responsibility to close body the default http client s transport does not attempt to reuse http or http tcp connections keep alive unless the body is read to completion and is closed yeah it say we must read body complete and close body in the above code after read resp body i don t close the resp body so the http client should t reuse the tcp connection so there will be two tcp connection handshark in wireshark but i only see one so maybe the net http s comment has something wrong thank you ,1 29573,14176309197.0,IssuesEvent,2020-11-12 23:16:57,golang/go,https://api.github.com/repos/golang/go,opened,"cmd/compile: notice when function variables are never reassigned, avoid indirect calls",Performance,"It's somewhat common for people to have package-level variables like: ``` var u64 = binary.BigEndian.Uint64 ``` So later in their code they can just write `u64(buf[8:])` many times without stuttering a loud `binary.BigEndian.Uint64` etc all over the page. But calling via such a func variable is ~7.5x slower than calling `binary.BigEndian.Uint64` directly: https://play.golang.org/p/eccPzwCSvfi It'd be nice if the compiler noticed that the `u64` variable was only initialized once and never reassigned to and never had its address taken (so it can't be mutated elsewhere), and did the fast thing automatically, not doing the indirect call. /cc @randall77 @mdempsky @ianlancetaylor @cherrymui @josharian @danderson",True,"cmd/compile: notice when function variables are never reassigned, avoid indirect calls - It's somewhat common for people to have package-level variables like: ``` var u64 = binary.BigEndian.Uint64 ``` So later in their code they can just write `u64(buf[8:])` many times without stuttering a loud `binary.BigEndian.Uint64` etc all over the page. But calling via such a func variable is ~7.5x slower than calling `binary.BigEndian.Uint64` directly: https://play.golang.org/p/eccPzwCSvfi It'd be nice if the compiler noticed that the `u64` variable was only initialized once and never reassigned to and never had its address taken (so it can't be mutated elsewhere), and did the fast thing automatically, not doing the indirect call. /cc @randall77 @mdempsky @ianlancetaylor @cherrymui @josharian @danderson",0,cmd compile notice when function variables are never reassigned avoid indirect calls it s somewhat common for people to have package level variables like var binary bigendian so later in their code they can just write buf many times without stuttering a loud binary bigendian etc all over the page but calling via such a func variable is slower than calling binary bigendian directly it d be nice if the compiler noticed that the variable was only initialized once and never reassigned to and never had its address taken so it can t be mutated elsewhere and did the fast thing automatically not doing the indirect call cc mdempsky ianlancetaylor cherrymui josharian danderson,0 273680,20811898403.0,IssuesEvent,2022-03-18 04:24:06,golang/go,https://api.github.com/repos/golang/go,closed,spec: document interface satisfaction more explicitly,Documentation,"
http://golang.org/ref/spec#Interface_types does not clearly spell out the requirements
for a type to implement an interface. It should.
",1.0,"spec: document interface satisfaction more explicitly - 
http://golang.org/ref/spec#Interface_types does not clearly spell out the requirements
for a type to implement an interface. It should.
",1,spec document interface satisfaction more explicitly a href does not clearly spell out the requirements for a type to implement an interface it should ,1 36321,9792748791.0,IssuesEvent,2019-06-10 18:11:44,golang/go,https://api.github.com/repos/golang/go,opened,x/build/cmd/gopherbot: should not consider backport requests inside backport issues,Builders NeedsFix help wanted,"A backport issue should never itself be backported, so gopherbot should reject requests to backport inside such issues. See https://github.com/golang/go/issues/32261#issuecomment-496157952 where it happened by accident and caused confusing backport-backport issues to be created.",1.0,"x/build/cmd/gopherbot: should not consider backport requests inside backport issues - A backport issue should never itself be backported, so gopherbot should reject requests to backport inside such issues. See https://github.com/golang/go/issues/32261#issuecomment-496157952 where it happened by accident and caused confusing backport-backport issues to be created.",0,x build cmd gopherbot should not consider backport requests inside backport issues a backport issue should never itself be backported so gopherbot should reject requests to backport inside such issues see where it happened by accident and caused confusing backport backport issues to be created ,0 433756,30348527179.0,IssuesEvent,2023-07-11 17:07:16,golang/go,https://api.github.com/repos/golang/go,closed,"log/slog: documentation passes nil contexts, which is discouraged",Documentation NeedsFix release-blocker,"The documentation of the slog package passes nil contexts, for example: ``` logger.LogAttrs(nil, slog.LevelInfo, ""hello"", slog.Int(""count"", 3)) ``` However, the context package discourages this: > Do not pass a nil Context, even if a function permits it. Pass context.TODO if you are unsure about which Context to use. slog internally turns nils into context.Background when calling methods on slog.Handler, which is probably good for resilience, but probably isn't something users should rely on. In particular, such calls will currently trigger Staticcheck's [SA1012](https://staticcheck.dev/docs/checks/#SA1012) and I'm not sure slog warrants an exception. I see from https://github.com/golang/exp/commit/f0f767cdffd6c3fe9fa17c685f39b1cf8e866c0c that this is intentional, so this issue might be contentious. However, I'm not sure the ""make them easier to write"" argument is as important now, considering there are helpers for pre-defined log levels that don't take context arguments, and it would be unfortunate for the standard library to ignore its own rules. /cc @jba ",1.0,"log/slog: documentation passes nil contexts, which is discouraged - The documentation of the slog package passes nil contexts, for example: ``` logger.LogAttrs(nil, slog.LevelInfo, ""hello"", slog.Int(""count"", 3)) ``` However, the context package discourages this: > Do not pass a nil Context, even if a function permits it. Pass context.TODO if you are unsure about which Context to use. slog internally turns nils into context.Background when calling methods on slog.Handler, which is probably good for resilience, but probably isn't something users should rely on. In particular, such calls will currently trigger Staticcheck's [SA1012](https://staticcheck.dev/docs/checks/#SA1012) and I'm not sure slog warrants an exception. I see from https://github.com/golang/exp/commit/f0f767cdffd6c3fe9fa17c685f39b1cf8e866c0c that this is intentional, so this issue might be contentious. However, I'm not sure the ""make them easier to write"" argument is as important now, considering there are helpers for pre-defined log levels that don't take context arguments, and it would be unfortunate for the standard library to ignore its own rules. /cc @jba ",1,log slog documentation passes nil contexts which is discouraged the documentation of the slog package passes nil contexts for example logger logattrs nil slog levelinfo hello slog int count however the context package discourages this do not pass a nil context even if a function permits it pass context todo if you are unsure about which context to use slog internally turns nils into context background when calling methods on slog handler which is probably good for resilience but probably isn t something users should rely on in particular such calls will currently trigger staticcheck s and i m not sure slog warrants an exception i see from that this is intentional so this issue might be contentious however i m not sure the make them easier to write argument is as important now considering there are helpers for pre defined log levels that don t take context arguments and it would be unfortunate for the standard library to ignore its own rules cc jba ,1 14586,3868515918.0,IssuesEvent,2016-04-10 00:35:30,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: fix documentation typo in findInternal,Documentation,`Four cases...` at https://github.com/golang/go/blob/c31fdd4ee9fccd24a274cebd82dcc7123ad43d0e/src/cmd/go/pkg.go#L563 should be `Three cases...`.,1.0,cmd/go: fix documentation typo in findInternal - `Four cases...` at https://github.com/golang/go/blob/c31fdd4ee9fccd24a274cebd82dcc7123ad43d0e/src/cmd/go/pkg.go#L563 should be `Three cases...`.,1,cmd go fix documentation typo in findinternal four cases at should be three cases ,1 105577,11454795771.0,IssuesEvent,2020-02-06 17:46:36,golang/go,https://api.github.com/repos/golang/go,closed,doc/install: update “Test your installation” step to be agnostic to module mode,Documentation NeedsFix modules," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.7 darwin/amd64
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/xxxx/Library/Caches/go-build""
GOENV=""/Users/xxxx/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/xxxx/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=""/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5k/x27nkdh9605dcjwmgmxbdr0c0000gn/T/go-build407033626=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I tried to create a go environment and proceeded according to the tutorial. https://golang.org/doc/install?download=go1.13.7.darwin-amd64.pkg Do you need `go mod init` before `go build`?? or execute `go build hello.go`. 
$ pwd
/Users/xxxx/go/src/hello
$ ls
hello.go
$ go build
go: cannot find main module; see 'go help modules'

$ cat hello.go
package main

import ""fmt""

func main() {
	fmt.Printf(""hello, world\n"")
}
",1.0,"doc/install: update “Test your installation” step to be agnostic to module mode - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.7 darwin/amd64
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/xxxx/Library/Caches/go-build""
GOENV=""/Users/xxxx/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/xxxx/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=""/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5k/x27nkdh9605dcjwmgmxbdr0c0000gn/T/go-build407033626=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I tried to create a go environment and proceeded according to the tutorial. https://golang.org/doc/install?download=go1.13.7.darwin-amd64.pkg Do you need `go mod init` before `go build`?? or execute `go build hello.go`. 
$ pwd
/Users/xxxx/go/src/hello
$ ls
hello.go
$ go build
go: cannot find main module; see 'go help modules'

$ cat hello.go
package main

import ""fmt""

func main() {
	fmt.Printf(""hello, world\n"")
}
",1,doc install update “test your installation” step to be agnostic to module mode please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin what operating system and processor architecture are you using go env go env output go env on goarch gobin gocache users xxxx library caches go build goenv users xxxx library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users xxxx go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do i tried to create a go environment and proceeded according to the tutorial do you need go mod init before go build or execute go build hello go pwd users xxxx go src hello ls hello go go build go cannot find main module see go help modules cat hello go package main import fmt func main fmt printf hello world n ,1 182948,14171248459.0,IssuesEvent,2020-11-12 15:29:27,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: the ""build_plugin_non_main"" test case cannot pass for linux/mips64le port",NeedsFix Testing," ### What version of Go are you using (`go version`)? 
$ go version
go1.15.3
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? linux/mips64le
go env Output
$ go env
### What did you do? run go command tests (cmd/go): ``` bash run.bash --no-rebuild --- FAIL: TestScript (0.03s) --- FAIL: TestScript/build_plugin_non_main (0.16s) script_test.go:210: # Plugins are only supported on linux,cgo and darwin,cgo. (0.152s) > [!linux] [!darwin] skip > [!cgo] skip > go build -n testdep/p2 [stderr] # # testdep/p2 # mkdir -p $WORK/b001/ cat >$WORK/b001/importcfg << 'EOF' # internal # import config EOF cd $WORK/gopath/src/testdep/p2 /usr/local/go/pkg/tool/linux_mips64le/compile -o $WORK/b001/_pkg_.a -trimpath ""$WORK/b001=>"" -p testdep/p2 -complete -buildid jfOUz6df0ldy6zplycX5/jfOUz6df0ldy6zplycX5 -goversion go1.15.3 -D """" -importcfg $WORK/b001/importcfg -pack -c=4 ./p2.go /usr/local/go/pkg/tool/linux_mips64le/buildid -w $WORK/b001/_pkg_.a # internal > ! go build -buildmode=plugin testdep/p2 [stderr] -buildmode=plugin not supported on linux/mips64le [exit status 1] > stderr '-buildmode=plugin requires exactly one main package' FAIL: testdata/script/build_plugin_non_main.txt:7: no match for `(?m)-buildmode=plugin requires exactly one main package` found in stderr FAIL FAIL cmd/go 133.150s ``` ### What did you expect to see? the ""build_plugin_non_main"" test case can pass for linux/mips64le port ### What did you see instead? the ""build_plugin_non_main"" test case can skip",1.0,"cmd/go: the ""build_plugin_non_main"" test case cannot pass for linux/mips64le port - ### What version of Go are you using (`go version`)? 
$ go version
go1.15.3
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? linux/mips64le
go env Output
$ go env
### What did you do? run go command tests (cmd/go): ``` bash run.bash --no-rebuild --- FAIL: TestScript (0.03s) --- FAIL: TestScript/build_plugin_non_main (0.16s) script_test.go:210: # Plugins are only supported on linux,cgo and darwin,cgo. (0.152s) > [!linux] [!darwin] skip > [!cgo] skip > go build -n testdep/p2 [stderr] # # testdep/p2 # mkdir -p $WORK/b001/ cat >$WORK/b001/importcfg << 'EOF' # internal # import config EOF cd $WORK/gopath/src/testdep/p2 /usr/local/go/pkg/tool/linux_mips64le/compile -o $WORK/b001/_pkg_.a -trimpath ""$WORK/b001=>"" -p testdep/p2 -complete -buildid jfOUz6df0ldy6zplycX5/jfOUz6df0ldy6zplycX5 -goversion go1.15.3 -D """" -importcfg $WORK/b001/importcfg -pack -c=4 ./p2.go /usr/local/go/pkg/tool/linux_mips64le/buildid -w $WORK/b001/_pkg_.a # internal > ! go build -buildmode=plugin testdep/p2 [stderr] -buildmode=plugin not supported on linux/mips64le [exit status 1] > stderr '-buildmode=plugin requires exactly one main package' FAIL: testdata/script/build_plugin_non_main.txt:7: no match for `(?m)-buildmode=plugin requires exactly one main package` found in stderr FAIL FAIL cmd/go 133.150s ``` ### What did you expect to see? the ""build_plugin_non_main"" test case can pass for linux/mips64le port ### What did you see instead? the ""build_plugin_non_main"" test case can skip",0,cmd go the build plugin non main test case cannot pass for linux port please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env linux go env output go env what did you do run go command tests cmd go bash run bash no rebuild fail testscript fail testscript build plugin non main script test go plugins are only supported on linux cgo and darwin cgo skip skip go build n testdep testdep mkdir p work cat work importcfg eof internal import config eof cd work gopath src testdep usr local go pkg tool linux compile o work pkg a trimpath work p testdep complete buildid goversion d importcfg work importcfg pack c go usr local go pkg tool linux buildid w work pkg a internal go build buildmode plugin testdep buildmode plugin not supported on linux stderr buildmode plugin requires exactly one main package fail testdata script build plugin non main txt no match for m buildmode plugin requires exactly one main package found in stderr fail fail cmd go if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see the build plugin non main test case can pass for linux port what did you see instead the build plugin non main test case can skip,0 76423,21409328295.0,IssuesEvent,2022-04-22 02:53:45,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gopherstats: reformat output for easier processing,Builders,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.11 darwin/amd64 ``` ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/ajstarks/Library/Caches/go-build"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/ajstarks/gowork"" GOPROXY="""" GORACE="""" GOROOT=""/Users/ajstarks/go"" GOTMPDIR="""" GOTOOLDIR=""/Users/ajstarks/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD="""" 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/ly/55wr2yk15r5bzxvvxxknvfr00000gn/T/go-build073726396=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### 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. ``` $ gopherstats -mode github-issue-close $ gopherstats -mode gerrit-cls ``` ### What did you expect to see? easier to parse fields ### What did you see instead? output lines like: ``` 2014q4 closed issues: 178 closes (79.21% goog 141; ext 37), 32 unique people (15 goog, 17 ext) ``` would be simpler to parse (for example with tools like awk), if they were reformatted something like this: ``` 2014q4 github-issue-close: 178 [ goog: 141 ext: 37 = 79.213/20.786% ] unique people: 32 [ goog: 15 ext: 17 = 46.875/53.125%] ``` for ```--gerrit-cls:``` ``` 2014q3 gerrit-cls: 638 [ goog: 462 ext: 176 = 74.413/27.586% ] ```",1.0,"x/build/cmd/gopherstats: reformat output for easier processing - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.11 darwin/amd64 ``` ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/ajstarks/Library/Caches/go-build"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/ajstarks/gowork"" GOPROXY="""" GORACE="""" GOROOT=""/Users/ajstarks/go"" GOTMPDIR="""" GOTOOLDIR=""/Users/ajstarks/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD="""" 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/ly/55wr2yk15r5bzxvvxxknvfr00000gn/T/go-build073726396=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### 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. ``` $ gopherstats -mode github-issue-close $ gopherstats -mode gerrit-cls ``` ### What did you expect to see? easier to parse fields ### What did you see instead? output lines like: ``` 2014q4 closed issues: 178 closes (79.21% goog 141; ext 37), 32 unique people (15 goog, 17 ext) ``` would be simpler to parse (for example with tools like awk), if they were reformatted something like this: ``` 2014q4 github-issue-close: 178 [ goog: 141 ext: 37 = 79.213/20.786% ] unique people: 32 [ goog: 15 ext: 17 = 46.875/53.125%] ``` for ```--gerrit-cls:``` ``` 2014q3 gerrit-cls: 638 [ goog: 462 ext: 176 = 74.413/27.586% ] ```",0,x build cmd gopherstats reformat output for easier processing please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache users ajstarks library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users ajstarks gowork goproxy gorace goroot users ajstarks go gotmpdir gotooldir users ajstarks go pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders ly t go tmp go build gno record gcc switches fno common 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 gopherstats mode github issue close gopherstats mode gerrit cls what did you expect to see easier to parse fields what did you see instead output lines like closed issues closes goog ext unique people goog ext would be simpler to parse for example with tools like awk if they were reformatted something like this github issue close unique people for gerrit cls gerrit cls ,0 55323,30694239926.0,IssuesEvent,2023-07-26 17:18:16,golang/go,https://api.github.com/repos/golang/go,closed,sort: slices.Sort is slightly slower than sort.Strings on some sorted inputs,Performance NeedsFix,"### What version of Go are you using (`go version`)? 
$ go version devel go1.21-39effbc105 Fri Jun 9 04:07:29 2023 +0000 windows/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GOOS=windows
set GOARCH=amd64
set GOAMD64=v2
### What did you do? Use the following benchmark code
code 
package main

import (
	//""slices""
	""sort""
	""strconv""
	""testing""
)

var s []string

func init() {
	const n = 10000000
	s = make([]string, n)
	for i := 0; i < n; i++ {
		s[i] = strconv.Itoa(i)
	}
}

func BenchmarkStringSort(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sort.Strings(s)
	}
}

// func BenchmarkStringSort(b *testing.B) {
// 	for i := 0; i < b.N; i++ {
// 		slices.Sort(s)
// 	}
// }
### What did you expect to see? Expected document to be successfully validated Note: consider using the new slices.Sort function, which runs faster ### What did you see instead? │ sort.txt │ slices.txt │ │ sec/op │ sec/op vs base │ StringSort-4 123.7m ± 2% 134.0m ± 1% +8.36% (p=0.002 n=10) The test results do not match the document, which says slices is faster, but the test found that sort is faster. ",True,"sort: slices.Sort is slightly slower than sort.Strings on some sorted inputs - ### What version of Go are you using (`go version`)? 
$ go version devel go1.21-39effbc105 Fri Jun 9 04:07:29 2023 +0000 windows/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GOOS=windows
set GOARCH=amd64
set GOAMD64=v2
### What did you do? Use the following benchmark code
code 
package main

import (
	//""slices""
	""sort""
	""strconv""
	""testing""
)

var s []string

func init() {
	const n = 10000000
	s = make([]string, n)
	for i := 0; i < n; i++ {
		s[i] = strconv.Itoa(i)
	}
}

func BenchmarkStringSort(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sort.Strings(s)
	}
}

// func BenchmarkStringSort(b *testing.B) {
// 	for i := 0; i < b.N; i++ {
// 		slices.Sort(s)
// 	}
// }
### What did you expect to see? Expected document to be successfully validated Note: consider using the new slices.Sort function, which runs faster ### What did you see instead? │ sort.txt │ slices.txt │ │ sec/op │ sec/op vs base │ StringSort-4 123.7m ± 2% 134.0m ± 1% +8.36% (p=0.002 n=10) The test results do not match the document, which says slices is faster, but the test found that sort is faster. ",0,sort slices sort is slightly slower than sort strings on some sorted inputs what version of go are you using go version go version devel fri jun windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env set goos windows set goarch set what did you do use the following benchmark code code package main import slices sort strconv testing var s string func init const n s make string n for i i n i s strconv itoa i func benchmarkstringsort b testing b for i i b n i sort strings s func benchmarkstringsort b testing b for i i b n i slices sort s what did you expect to see expected document to be successfully validated note consider using the new slices sort function which runs faster what did you see instead │ sort txt │ slices txt │ │ sec op │ sec op vs base │ stringsort ± ± p n the test results do not match the document which says slices is faster but the test found that sort is faster ,0 211781,16458122443.0,IssuesEvent,2021-05-21 15:04:47,golang/go,https://api.github.com/repos/golang/go,opened,net/http/pprof: add note about security implications to the docs,Documentation Security,"The net/http/pprof endpoints include stack traces with integer arguments, which can leak sensitive information depending on the settings. We should mention that in the docs.",1.0,"net/http/pprof: add note about security implications to the docs - The net/http/pprof endpoints include stack traces with integer arguments, which can leak sensitive information depending on the settings. We should mention that in the docs.",1,net http pprof add note about security implications to the docs the net http pprof endpoints include stack traces with integer arguments which can leak sensitive information depending on the settings we should mention that in the docs ,1 348273,24910256349.0,IssuesEvent,2022-10-29 19:23:59,golang/go,https://api.github.com/repos/golang/go,opened,x/website: newer examples for security policy PRIVATE issues,Documentation website,"The security policy page https://go.dev/security/policy lists examples of PRIVATE issues. These are examples listed in the new security policy discussion #44918 , before the policy was in place. I've witnessed confusion on what PRIVATE means, as some of the issues listed there were open for quite some time before being fixed. Newer PRIVATE issues follow a different process with placeholder issues linking to a private tracker that is updated when it becomes public, ex: #53416 #53616 #54658 #56284 . The security policy would benefit from newer examples that follow the process laid out by it. cc @golang/security ",1.0,"x/website: newer examples for security policy PRIVATE issues - The security policy page https://go.dev/security/policy lists examples of PRIVATE issues. These are examples listed in the new security policy discussion #44918 , before the policy was in place. I've witnessed confusion on what PRIVATE means, as some of the issues listed there were open for quite some time before being fixed. Newer PRIVATE issues follow a different process with placeholder issues linking to a private tracker that is updated when it becomes public, ex: #53416 #53616 #54658 #56284 . The security policy would benefit from newer examples that follow the process laid out by it. cc @golang/security ",1,x website newer examples for security policy private issues the security policy page lists examples of private issues these are examples listed in the new security policy discussion before the policy was in place i ve witnessed confusion on what private means as some of the issues listed there were open for quite some time before being fixed newer private issues follow a different process with placeholder issues linking to a private tracker that is updated when it becomes public ex the security policy would benefit from newer examples that follow the process laid out by it cc golang security ,1 221500,17019404340.0,IssuesEvent,2021-07-02 16:26:06,golang/go,https://api.github.com/repos/golang/go,closed,cmd/dist: typo in comment,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/home/vagrant/go/bin""
GOCACHE=""/home/vagrant/.cache/go-build""
GOENV=""/home/vagrant/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/vagrant/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/vagrant/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16""
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-build2823638017=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read the source code at https://github.com/golang/go/blob/master/src/cmd/dist/test.go#L784 I think `syscall.SysProcAttr`, not `syscall.SysProcAttri`. Sorry if I'm wrong. ### What did you expect to see? ``` // because syscall.SysProcAttri struct used in misc/cgo/testsanitizers is only built on linux. ``` ### What did you see instead? ``` // because syscall.SysProcAttr struct used in misc/cgo/testsanitizers is only built on linux. ``` ",1.0,"cmd/dist: typo in comment - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/home/vagrant/go/bin""
GOCACHE=""/home/vagrant/.cache/go-build""
GOENV=""/home/vagrant/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/vagrant/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/vagrant/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16""
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-build2823638017=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read the source code at https://github.com/golang/go/blob/master/src/cmd/dist/test.go#L784 I think `syscall.SysProcAttr`, not `syscall.SysProcAttri`. Sorry if I'm wrong. ### What did you expect to see? ``` // because syscall.SysProcAttri struct used in misc/cgo/testsanitizers is only built on linux. ``` ### What did you see instead? ``` // because syscall.SysProcAttr struct used in misc/cgo/testsanitizers is only built on linux. ``` ",1,cmd dist typo in comment please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release what operating system and processor architecture are you using go env go env output go env goarch gobin home vagrant go bin gocache home vagrant cache go build goenv home vagrant config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home vagrant go pkg mod gonoproxy gonosumdb goos linux gopath home vagrant go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do read the source code at i think syscall sysprocattr not syscall sysprocattri sorry if i m wrong if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see because syscall sysprocattri struct used in misc cgo testsanitizers is only built on linux what did you see instead because syscall sysprocattr struct used in misc cgo testsanitizers is only built on linux ,1 60997,8482677792.0,IssuesEvent,2018-10-25 19:14:08,golang/go,https://api.github.com/repos/golang/go,opened,text/template: documentation for IsTrue disagrees with its implementation for struct types,Documentation NeedsDecision,"As noted in #28391, the [documentation for `template.IsTrue`](https://tip.golang.org/pkg/text/template/#IsTrue) says: > IsTrue reports whether the value is 'true', in the sense of not the zero of its type, and whether the value has a meaningful truth value. The zero `time.Time` *is* the zero of its type, so according to the documentation it should be considered to be true, but the implementation clearly intends otherwise: https://github.com/golang/go/blob/f6b554fec75ff1a36c6204755db8c1f638255b64/src/text/template/exec.go#L326-L327 Either the documentation should be clarified, or the behavior of `IsTrue` should be fixed to match what is documented. Probably the former.",1.0,"text/template: documentation for IsTrue disagrees with its implementation for struct types - As noted in #28391, the [documentation for `template.IsTrue`](https://tip.golang.org/pkg/text/template/#IsTrue) says: > IsTrue reports whether the value is 'true', in the sense of not the zero of its type, and whether the value has a meaningful truth value. The zero `time.Time` *is* the zero of its type, so according to the documentation it should be considered to be true, but the implementation clearly intends otherwise: https://github.com/golang/go/blob/f6b554fec75ff1a36c6204755db8c1f638255b64/src/text/template/exec.go#L326-L327 Either the documentation should be clarified, or the behavior of `IsTrue` should be fixed to match what is documented. Probably the former.",1,text template documentation for istrue disagrees with its implementation for struct types as noted in the says istrue reports whether the value is true in the sense of not the zero of its type and whether the value has a meaningful truth value the zero time time is the zero of its type so according to the documentation it should be considered to be true but the implementation clearly intends otherwise either the documentation should be clarified or the behavior of istrue should be fixed to match what is documented probably the former ,1 21716,4734184741.0,IssuesEvent,2016-10-19 13:35:34,golang/go,https://api.github.com/repos/golang/go,closed,reflect: DeepEqual treats nil and empty map as not equal,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? Go tip (be91515) 2. What operating system and processor architecture are you using (`go env`)? linux/amd64 3. What did you do? https://play.golang.org/p/S_vq5DdCzu 4. What did you expect to see? `true` 5. What did you see instead? `false` The doc for `reflect.DeepEqual` says: > Map values are deeply equal if they are the same map object or if they have the same length and their corresponding keys (matched using Go equality) map to deeply equal values. Empty and nil maps both have a length of zero, so I would expect this to be true.",1.0,"reflect: DeepEqual treats nil and empty map as not equal - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? Go tip (be91515) 2. What operating system and processor architecture are you using (`go env`)? linux/amd64 3. What did you do? https://play.golang.org/p/S_vq5DdCzu 4. What did you expect to see? `true` 5. What did you see instead? `false` The doc for `reflect.DeepEqual` says: > Map values are deeply equal if they are the same map object or if they have the same length and their corresponding keys (matched using Go equality) map to deeply equal values. Empty and nil maps both have a length of zero, so I would expect this to be true.",1,reflect deepequal treats nil and empty map as not equal please answer these questions before submitting your issue thanks what version of go are you using go version go tip what operating system and processor architecture are you using go env linux what did you do what did you expect to see true what did you see instead false the doc for reflect deepequal says map values are deeply equal if they are the same map object or if they have the same length and their corresponding keys matched using go equality map to deeply equal values empty and nil maps both have a length of zero so i would expect this to be true ,1 302405,22822058608.0,IssuesEvent,2022-07-12 04:04:53,golang/go,https://api.github.com/repos/golang/go,closed,net/http: misleading documentation about the error returned by MaxBytesReader,Documentation NeedsInvestigation,"In Go 1.19, the `MaxBytesReader` method returns an error of type `*MaxBytesError` in case of a `Read` beyond the limit. But the [documentation suggests](https://pkg.go.dev/net/http@go1.19beta1#MaxBytesReader) that the type is `MaxBytesError` instead. You have to read the implementation code or deduce it from the `Error` method that uses a pointer receiver.",1.0,"net/http: misleading documentation about the error returned by MaxBytesReader - In Go 1.19, the `MaxBytesReader` method returns an error of type `*MaxBytesError` in case of a `Read` beyond the limit. But the [documentation suggests](https://pkg.go.dev/net/http@go1.19beta1#MaxBytesReader) that the type is `MaxBytesError` instead. You have to read the implementation code or deduce it from the `Error` method that uses a pointer receiver.",1,net http misleading documentation about the error returned by maxbytesreader in go the maxbytesreader method returns an error of type maxbyteserror in case of a read beyond the limit but the that the type is maxbyteserror instead you have to read the implementation code or deduce it from the error method that uses a pointer receiver ,1 62647,15306373297.0,IssuesEvent,2021-02-24 19:23:19,golang/go,https://api.github.com/repos/golang/go,closed,x/build/dashboard: remove darwin-386-10_14 builder when Go 1.14 stops being supported,Builders NeedsFix early-in-cycle,"On https://golang.org/cl/259903 I asked for a darwin-386 slowbot. I got one, but it doesn't work, presumably because the darwin/386 port has been removed (#37610). It seems to me that asking for a darwin-386 slowbot should simply ignore the request rather than run a broken slowbot. Thanks. CC @dmitshur @cagedmantis ",1.0,"x/build/dashboard: remove darwin-386-10_14 builder when Go 1.14 stops being supported - On https://golang.org/cl/259903 I asked for a darwin-386 slowbot. I got one, but it doesn't work, presumably because the darwin/386 port has been removed (#37610). It seems to me that asking for a darwin-386 slowbot should simply ignore the request rather than run a broken slowbot. Thanks. CC @dmitshur @cagedmantis ",0,x build dashboard remove darwin builder when go stops being supported on i asked for a darwin slowbot i got one but it doesn t work presumably because the darwin port has been removed it seems to me that asking for a darwin slowbot should simply ignore the request rather than run a broken slowbot thanks cc dmitshur cagedmantis ,0 14667,3873105535.0,IssuesEvent,2016-04-11 15:52:08,golang/go,https://api.github.com/repos/golang/go,reopened,net/http: document that Error() does not terminate the current handler,Documentation,"Using `go1.6` I recently saw code that did the following: ``` func serveHTTP(resp http.ResponseWriter, req *http.Request) { ... if err := foo(); err != nil { http.Error(resp, err.Error(), http.StatusInternalServerError) } if err := bar(); err != nil { http.Error(resp, err.Error(), http.StatusInternalServerError) } } ``` The assumption made was that http.Error() terminates the current handler in some magical way. Instead, Error simply sets the headers and writes the body message, and it is the programmer's responsibility to return. We should document this. ",1.0,"net/http: document that Error() does not terminate the current handler - Using `go1.6` I recently saw code that did the following: ``` func serveHTTP(resp http.ResponseWriter, req *http.Request) { ... if err := foo(); err != nil { http.Error(resp, err.Error(), http.StatusInternalServerError) } if err := bar(); err != nil { http.Error(resp, err.Error(), http.StatusInternalServerError) } } ``` The assumption made was that http.Error() terminates the current handler in some magical way. Instead, Error simply sets the headers and writes the body message, and it is the programmer's responsibility to return. We should document this. ",1,net http document that error does not terminate the current handler using i recently saw code that did the following func servehttp resp http responsewriter req http request if err foo err nil http error resp err error http statusinternalservererror if err bar err nil http error resp err error http statusinternalservererror the assumption made was that http error terminates the current handler in some magical way instead error simply sets the headers and writes the body message and it is the programmer s responsibility to return we should document this ,1 8246,6492783513.0,IssuesEvent,2017-08-21 14:38:57,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: unnecessary zero-extension of booleans on arm64,Performance,"Given the following Go code ``` func f(c int) int { ret := 0 if c < 0 { ret = 1 } return ret } ``` the compiler generates ``` genssa f 00000 (/home/phil/test.go:7) TEXT """".f(SB) 00001 (/home/phil/test.go:7) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB) 00002 (/home/phil/test.go:7) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) v7 00003 (/home/phil/test.go:7) MOVD """".c(RSP), R0 v9 00004 (/home/phil/test.go:9) CMP $0, R0 v8 00005 (/home/phil/test.go:9) CSET LT, R0 v10 00006 (/home/phil/test.go:12) MOVBU R0, R0 v13 00007 (/home/phil/test.go:12) MOVD R0, """".~r1+8(RSP) b3 00008 (/home/phil/test.go:12) RET 00009 () END ``` The MOVBU after the CSET is unnecessary. CSET sets the whole register. This is an easy rewrite rule fix. ",True,"cmd/compile: unnecessary zero-extension of booleans on arm64 - Given the following Go code ``` func f(c int) int { ret := 0 if c < 0 { ret = 1 } return ret } ``` the compiler generates ``` genssa f 00000 (/home/phil/test.go:7) TEXT """".f(SB) 00001 (/home/phil/test.go:7) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB) 00002 (/home/phil/test.go:7) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) v7 00003 (/home/phil/test.go:7) MOVD """".c(RSP), R0 v9 00004 (/home/phil/test.go:9) CMP $0, R0 v8 00005 (/home/phil/test.go:9) CSET LT, R0 v10 00006 (/home/phil/test.go:12) MOVBU R0, R0 v13 00007 (/home/phil/test.go:12) MOVD R0, """".~r1+8(RSP) b3 00008 (/home/phil/test.go:12) RET 00009 () END ``` The MOVBU after the CSET is unnecessary. CSET sets the whole register. This is an easy rewrite rule fix. ",0,cmd compile unnecessary zero extension of booleans on given the following go code func f c int int ret if c ret return ret the compiler generates genssa f home phil test go text f sb home phil test go funcdata gclocals· sb home phil test go funcdata gclocals· sb home phil test go movd c rsp home phil test go cmp home phil test go cset lt home phil test go movbu home phil test go movd rsp home phil test go ret end the movbu after the cset is unnecessary cset sets the whole register this is an easy rewrite rule fix ,0 28426,11626979926.0,IssuesEvent,2020-02-27 15:50:15,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go get -u behaves as if -f is always provided (for non-custom import paths),GoCommand NeedsInvestigation Security,"This is an issue since 2015. I discovered it on January 11, 2017, but I'm only getting around to reporting it now. I have a suggestion for resolution. `cmd/go` documents the flag `-f` for use with `go get -u` at https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies: > The -f flag, valid only when -u is set, forces get -u not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original. However, for packages with a non-custom import path (custom import path being one that is defined by HTML meta tags, see [`isCustom`](https://github.com/golang/go/blob/94e44a9c8edb64f514b6f3b7f7001db0cfeb2d70/src/cmd/go/internal/get/vcs.go#L536-L537)), `go get -u` now behaves as if `-f` is always provided. For custom import paths (e.g., `rsc.io/pdf`), there is no such issue. ### What version of Go are you using (`go version`)? ``` $ go version go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)?
``` $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/tmp/fresh"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build606008153=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ```
### What did you do? Everything works as expected for custom import paths: ``` $ export GOPATH=/tmp/fresh $ go get -u rsc.io/pdf $ cd $GOPATH/src/rsc.io/pdf $ git remote -v origin https://github.com/rsc/pdf (fetch) origin https://github.com/rsc/pdf (push) $ git remote set-url origin https://github.com/wrong/repo $ go get -u rsc.io/pdf package rsc.io/pdf: rsc.io/pdf is a custom import path for https://github.com/rsc/pdf, but /tmp/fresh/src/rsc.io/pdf is checked out from https://github.com/wrong/repo $ echo $? 1 $ go get -u -f rsc.io/pdf $ echo $? 0 ``` (For demonstration purposes, assume that https://github.com/wrong/repo contains arbitrary git history, such that it's `git pull --ff-only`-compatible with the repo I'm trying to update. I don't want to spend time creating GitHub repos that have this property, but it's possible.) However, this is what happens for a non-custom import path: ``` $ go get -u github.com/gorilla/mux $ cd $GOPATH/src/github.com/gorilla/mux $ git remote -v origin https://github.com/gorilla/mux (fetch) origin https://github.com/gorilla/mux (push) $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux $ echo $? 0 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ### What did you expect to see? ``` $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux package github.com/gorilla/mux: github.com/gorilla/mux is an import path for https://github.com/gorilla/mux, but /tmp/fresh/src/github.com/gorilla/mux is checked out from https://github.com/wrong/repo $ echo $? 1 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ### What did you see instead? ``` $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux $ echo $? 0 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ## Fix This regression was introduced while resolving another issue. I have a suggestion for how to fix it so both things are fixed. Details will follow in next comment.",True,"cmd/go: go get -u behaves as if -f is always provided (for non-custom import paths) - This is an issue since 2015. I discovered it on January 11, 2017, but I'm only getting around to reporting it now. I have a suggestion for resolution. `cmd/go` documents the flag `-f` for use with `go get -u` at https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies: > The -f flag, valid only when -u is set, forces get -u not to verify that each package has been checked out from the source control repository implied by its import path. This can be useful if the source is a local fork of the original. However, for packages with a non-custom import path (custom import path being one that is defined by HTML meta tags, see [`isCustom`](https://github.com/golang/go/blob/94e44a9c8edb64f514b6f3b7f7001db0cfeb2d70/src/cmd/go/internal/get/vcs.go#L536-L537)), `go get -u` now behaves as if `-f` is always provided. For custom import paths (e.g., `rsc.io/pdf`), there is no such issue. ### What version of Go are you using (`go version`)? ``` $ go version go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)?
``` $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/tmp/fresh"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build606008153=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ```
### What did you do? Everything works as expected for custom import paths: ``` $ export GOPATH=/tmp/fresh $ go get -u rsc.io/pdf $ cd $GOPATH/src/rsc.io/pdf $ git remote -v origin https://github.com/rsc/pdf (fetch) origin https://github.com/rsc/pdf (push) $ git remote set-url origin https://github.com/wrong/repo $ go get -u rsc.io/pdf package rsc.io/pdf: rsc.io/pdf is a custom import path for https://github.com/rsc/pdf, but /tmp/fresh/src/rsc.io/pdf is checked out from https://github.com/wrong/repo $ echo $? 1 $ go get -u -f rsc.io/pdf $ echo $? 0 ``` (For demonstration purposes, assume that https://github.com/wrong/repo contains arbitrary git history, such that it's `git pull --ff-only`-compatible with the repo I'm trying to update. I don't want to spend time creating GitHub repos that have this property, but it's possible.) However, this is what happens for a non-custom import path: ``` $ go get -u github.com/gorilla/mux $ cd $GOPATH/src/github.com/gorilla/mux $ git remote -v origin https://github.com/gorilla/mux (fetch) origin https://github.com/gorilla/mux (push) $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux $ echo $? 0 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ### What did you expect to see? ``` $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux package github.com/gorilla/mux: github.com/gorilla/mux is an import path for https://github.com/gorilla/mux, but /tmp/fresh/src/github.com/gorilla/mux is checked out from https://github.com/wrong/repo $ echo $? 1 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ### What did you see instead? ``` $ git remote set-url origin https://github.com/wrong/repo $ go get -u github.com/gorilla/mux $ echo $? 0 $ go get -u -f github.com/gorilla/mux $ echo $? 0 ``` ## Fix This regression was introduced while resolving another issue. I have a suggestion for how to fix it so both things are fixed. Details will follow in next comment.",0,cmd go go get u behaves as if f is always provided for non custom import paths this is an issue since i discovered it on january but i m only getting around to reporting it now i have a suggestion for resolution cmd go documents the flag f for use with go get u at the f flag valid only when u is set forces get u not to verify that each package has been checked out from the source control repository implied by its import path this can be useful if the source is a local fork of the original however for packages with a non custom import path custom import path being one that is defined by html meta tags see go get u now behaves as if f is always provided for custom import paths e g rsc io pdf there is no such issue what version of go are you using go version go version go version darwin what operating system and processor architecture are you using go env go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath tmp fresh gorace goroot usr local go gotooldir usr local go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders tw t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do everything works as expected for custom import paths export gopath tmp fresh go get u rsc io pdf cd gopath src rsc io pdf git remote v origin fetch origin push git remote set url origin go get u rsc io pdf package rsc io pdf rsc io pdf is a custom import path for but tmp fresh src rsc io pdf is checked out from echo go get u f rsc io pdf echo for demonstration purposes assume that contains arbitrary git history such that it s git pull ff only compatible with the repo i m trying to update i don t want to spend time creating github repos that have this property but it s possible however this is what happens for a non custom import path go get u github com gorilla mux cd gopath src github com gorilla mux git remote v origin fetch origin push git remote set url origin go get u github com gorilla mux echo go get u f github com gorilla mux echo what did you expect to see git remote set url origin go get u github com gorilla mux package github com gorilla mux github com gorilla mux is an import path for but tmp fresh src github com gorilla mux is checked out from echo go get u f github com gorilla mux echo what did you see instead git remote set url origin go get u github com gorilla mux echo go get u f github com gorilla mux echo fix this regression was introduced while resolving another issue i have a suggestion for how to fix it so both things are fixed details will follow in next comment ,0 92414,26680642644.0,IssuesEvent,2023-01-26 17:23:40,golang/go,https://api.github.com/repos/golang/go,closed,x/build: have darwin/amd64 builders on macOS 13 (Ventura),OS-Darwin Builders NeedsInvestigation new-builder,"This is the tracking issue like #55354, but for GOARCH=amd64. CC @golang/release, @golang/darwin.",2.0,"x/build: have darwin/amd64 builders on macOS 13 (Ventura) - This is the tracking issue like #55354, but for GOARCH=amd64. CC @golang/release, @golang/darwin.",0,x build have darwin builders on macos ventura this is the tracking issue like but for goarch cc golang release golang darwin ,0 214013,16544575177.0,IssuesEvent,2021-05-27 21:42:44,golang/go,https://api.github.com/repos/golang/go,closed,net/http: Client.Do documentation is incorrect about *url.Error.Timeout,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.4 linux/amd64
### Does this issue reproduce with the latest release? Yes. It also reproduces with go1.17 devel. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ 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=""*.local""
GOMODCACHE=""/home/manlio/.local/lib/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""*.local""
GOOS=""linux""
GOPATH=""/home/manlio/.local/lib/go:/home/manlio/src/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.4""
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-build1653706074=/tmp/go-build -gno-record-gcc-switches""
GOROOT/bin/go version: go version go1.16.4 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.16.4
uname -sr: Linux 5.12.5-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.33.
gdb --version: GNU gdb (GDB) 10.2
### What did you do? https://play.golang.org/p/YQH5oWtQWjC ### What did you expect to see? `timed out: true` As documented by https://golang.org/pkg/net/http/#Client.Do: ``` Any returned error will be of type *url.Error. The url.Error value's Timeout method will report true if request timed out or was canceled. ``` ### What did you see instead? `timed out: false` ",1.0,"net/http: Client.Do documentation is incorrect about *url.Error.Timeout - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.4 linux/amd64
### Does this issue reproduce with the latest release? Yes. It also reproduces with go1.17 devel. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ 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=""*.local""
GOMODCACHE=""/home/manlio/.local/lib/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""*.local""
GOOS=""linux""
GOPATH=""/home/manlio/.local/lib/go:/home/manlio/src/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.4""
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-build1653706074=/tmp/go-build -gno-record-gcc-switches""
GOROOT/bin/go version: go version go1.16.4 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.16.4
uname -sr: Linux 5.12.5-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.33.
gdb --version: GNU gdb (GDB) 10.2
### What did you do? https://play.golang.org/p/YQH5oWtQWjC ### What did you expect to see? `timed out: true` As documented by https://golang.org/pkg/net/http/#Client.Do: ``` Any returned error will be of type *url.Error. The url.Error value's Timeout method will report true if request timed out or was canceled. ``` ### What did you see instead? `timed out: false` ",1,net http client do documentation is incorrect about url error timeout what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes it also reproduces with devel what operating system and processor architecture are you using go env go env output go env on goarch gobin home manlio local bin gocache home manlio cache go build goenv home manlio config go env goexe goflags gohostarch gohostos linux goinsecure local gomodcache home manlio local lib go pkg mod gonoproxy gonosumdb local goos linux gopath home manlio local lib go home manlio src go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches goroot bin go version go version linux goroot bin go tool compile v compile version uname sr linux usr lib libc so gnu c library gnu libc release release version gdb version gnu gdb gdb what did you do what did you expect to see timed out true as documented by any returned error will be of type url error the url error value s timeout method will report true if request timed out or was canceled what did you see instead timed out false ,1 58775,14483536106.0,IssuesEvent,2020-12-10 15:16:37,golang/go,https://api.github.com/repos/golang/go,closed,x/build: failures due to antivirus software on windows-arm-zx2c4 builder,Builders NeedsInvestigation OS-Windows,"[2020-12-04T22:08:54-4de4480/windows-arm-zx2c4](https://build.golang.org/log/bac8c667f6a93b164215fcd6c9ce2dfac6e78a32) [2020-12-04T13:50:44-37588ff/windows-arm-zx2c4](https://build.golang.org/log/8712666db6c08a56dd4d7b6bfe5bc5a8b08772ca) [2020-12-03T01:27:00-78e442e/windows-arm-zx2c4](https://build.golang.org/log/9ccbe276cfdf0dd4fc1218a78952928690d2ec0c) ``` ##### ../test ##### go build command-line-arguments: open C:\Users\GOPHER~1.DES\AppData\Local\Temp\go-build061194467\b001\exe\a.out.exe: Operation did not complete successfully because the file contains a virus or potentially unwanted software. XXXBANNERXXX:../test go tool dist: Failed: exit status 1 ``` This looks like a probable builder configuration issue: perhaps the antivirus software installed on the builder is misconfigured or overly biased toward false-positives. CC @zx2c4 @golang/release ",1.0,"x/build: failures due to antivirus software on windows-arm-zx2c4 builder - [2020-12-04T22:08:54-4de4480/windows-arm-zx2c4](https://build.golang.org/log/bac8c667f6a93b164215fcd6c9ce2dfac6e78a32) [2020-12-04T13:50:44-37588ff/windows-arm-zx2c4](https://build.golang.org/log/8712666db6c08a56dd4d7b6bfe5bc5a8b08772ca) [2020-12-03T01:27:00-78e442e/windows-arm-zx2c4](https://build.golang.org/log/9ccbe276cfdf0dd4fc1218a78952928690d2ec0c) ``` ##### ../test ##### go build command-line-arguments: open C:\Users\GOPHER~1.DES\AppData\Local\Temp\go-build061194467\b001\exe\a.out.exe: Operation did not complete successfully because the file contains a virus or potentially unwanted software. XXXBANNERXXX:../test go tool dist: Failed: exit status 1 ``` This looks like a probable builder configuration issue: perhaps the antivirus software installed on the builder is misconfigured or overly biased toward false-positives. CC @zx2c4 @golang/release ",0,x build failures due to antivirus software on windows arm builder test go build command line arguments open c users gopher des appdata local temp go exe a out exe operation did not complete successfully because the file contains a virus or potentially unwanted software xxxbannerxxx test go tool dist failed exit status this looks like a probable builder configuration issue perhaps the antivirus software installed on the builder is misconfigured or overly biased toward false positives cc golang release ,0 33405,6201012868.0,IssuesEvent,2017-07-06 03:54:12,golang/go,https://api.github.com/repos/golang/go,closed,time: cannot roundtrip Parse the Time.String output,Documentation NeedsFix,"On tip, the documentation of `Time.String` says: > String returns the time formatted using the format string: ""2006-01-02 15:04:05.999999999 -0700 MST"" This is misleading since it suggests that the following should work: ```go time.Parse(""2006-01-02 15:04:05.999999999 -0700 MST"", time.Now().String()) ``` However, this does not work on Go1.9 since: ``` parsing time ""2017-06-30 17:31:36.969388848 -0700 PDT m=+0.004118679"": extra text: m=+0.004118679 ``` We should done one of the following: * Say that round-trip parsing does not work and fix the documentation on `Time.String` to not suggest that the format string is `""2006-01-02 15:04:05.999999999 -0700 MST""`. We can suggest that `String` is intended only for human consumption and is not meant to be machine readable. * Or fix the API for `Parse`, such that the monotonic timestamps can be ignored. \cc @bradfitz @rsc ",1.0,"time: cannot roundtrip Parse the Time.String output - On tip, the documentation of `Time.String` says: > String returns the time formatted using the format string: ""2006-01-02 15:04:05.999999999 -0700 MST"" This is misleading since it suggests that the following should work: ```go time.Parse(""2006-01-02 15:04:05.999999999 -0700 MST"", time.Now().String()) ``` However, this does not work on Go1.9 since: ``` parsing time ""2017-06-30 17:31:36.969388848 -0700 PDT m=+0.004118679"": extra text: m=+0.004118679 ``` We should done one of the following: * Say that round-trip parsing does not work and fix the documentation on `Time.String` to not suggest that the format string is `""2006-01-02 15:04:05.999999999 -0700 MST""`. We can suggest that `String` is intended only for human consumption and is not meant to be machine readable. * Or fix the API for `Parse`, such that the monotonic timestamps can be ignored. \cc @bradfitz @rsc ",1,time cannot roundtrip parse the time string output on tip the documentation of time string says string returns the time formatted using the format string mst this is misleading since it suggests that the following should work go time parse mst time now string however this does not work on since parsing time pdt m extra text m we should done one of the following say that round trip parsing does not work and fix the documentation on time string to not suggest that the format string is mst we can suggest that string is intended only for human consumption and is not meant to be machine readable or fix the api for parse such that the monotonic timestamps can be ignored cc bradfitz rsc ,1 73350,9660745838.0,IssuesEvent,2019-05-20 16:09:57,golang/go,https://api.github.com/repos/golang/go,closed,context: CancelFunc isn't documented to be safe for simultaneous use by multiple goroutines,Documentation NeedsFix,"There are two types defined in the `context` package. The documentation makes it very clear that the `context.Context` type and its methods are safe for simultaneous use by multiple goroutines: - In the [package comment](https://godoc.org/context): > The same Context may be passed to functions running in different goroutines; Contexts are safe for simultaneous use by multiple goroutines. - In the [`context.Context`](https://godoc.org/context#Context) type documentation: > Context's methods may be called by multiple goroutines simultaneously. There is another type in the context package, the [`context.CancelFunc`](https://godoc.org/context#CancelFunc) type. It is currently documented as: > A CancelFunc tells an operation to abandon its work. A CancelFunc does not wait for the work to stop. After the first call, subsequent calls to a CancelFunc do nothing. It states that after the first call, subsequent calls to a CancelFunc do nothing. The three `With*` methods that return a Context and CancelFunc say: > Canceling this context releases resources associated with it, so code should call cancel as soon as the operations running in this Context complete. As I understand it, the documentation does not state that ContextFunc is safe for simultaneous use by multiple goroutines. Is that a documentation bug? /cc @Sajmani, @bradfitz as [owners](https://dev.golang.org/owners); also /cc @mvdan",1.0,"context: CancelFunc isn't documented to be safe for simultaneous use by multiple goroutines - There are two types defined in the `context` package. The documentation makes it very clear that the `context.Context` type and its methods are safe for simultaneous use by multiple goroutines: - In the [package comment](https://godoc.org/context): > The same Context may be passed to functions running in different goroutines; Contexts are safe for simultaneous use by multiple goroutines. - In the [`context.Context`](https://godoc.org/context#Context) type documentation: > Context's methods may be called by multiple goroutines simultaneously. There is another type in the context package, the [`context.CancelFunc`](https://godoc.org/context#CancelFunc) type. It is currently documented as: > A CancelFunc tells an operation to abandon its work. A CancelFunc does not wait for the work to stop. After the first call, subsequent calls to a CancelFunc do nothing. It states that after the first call, subsequent calls to a CancelFunc do nothing. The three `With*` methods that return a Context and CancelFunc say: > Canceling this context releases resources associated with it, so code should call cancel as soon as the operations running in this Context complete. As I understand it, the documentation does not state that ContextFunc is safe for simultaneous use by multiple goroutines. Is that a documentation bug? /cc @Sajmani, @bradfitz as [owners](https://dev.golang.org/owners); also /cc @mvdan",1,context cancelfunc isn t documented to be safe for simultaneous use by multiple goroutines there are two types defined in the context package the documentation makes it very clear that the context context type and its methods are safe for simultaneous use by multiple goroutines in the the same context may be passed to functions running in different goroutines contexts are safe for simultaneous use by multiple goroutines in the type documentation context s methods may be called by multiple goroutines simultaneously there is another type in the context package the type it is currently documented as a cancelfunc tells an operation to abandon its work a cancelfunc does not wait for the work to stop after the first call subsequent calls to a cancelfunc do nothing it states that after the first call subsequent calls to a cancelfunc do nothing the three with methods that return a context and cancelfunc say canceling this context releases resources associated with it so code should call cancel as soon as the operations running in this context complete as i understand it the documentation does not state that contextfunc is safe for simultaneous use by multiple goroutines is that a documentation bug cc sajmani bradfitz as also cc mvdan,1 31312,5931393602.0,IssuesEvent,2017-05-24 06:11:39,golang/go,https://api.github.com/repos/golang/go,closed,"time: is documented as safe for concurrent use, but unmarshal methods do not synchronize",Documentation,"time.Time is documented as being safe for concurrent use, however, some methods modify it without synchronization: GobDecode, UnmarshalBinary, UnmarshalJSON, and UnmarshalText. It seems like we should update the documentation. What's the right way to document the goroutine-safety guarantee? Something like: ""A Time value can be used by multiple goroutines simultaneously so long as no goroutine calls an unmarshaler method (t.GobDecode, t.UnmarshalBinary, t.UnmarshalJSON, t.UnmarshalText)."" ? ",1.0,"time: is documented as safe for concurrent use, but unmarshal methods do not synchronize - time.Time is documented as being safe for concurrent use, however, some methods modify it without synchronization: GobDecode, UnmarshalBinary, UnmarshalJSON, and UnmarshalText. It seems like we should update the documentation. What's the right way to document the goroutine-safety guarantee? Something like: ""A Time value can be used by multiple goroutines simultaneously so long as no goroutine calls an unmarshaler method (t.GobDecode, t.UnmarshalBinary, t.UnmarshalJSON, t.UnmarshalText)."" ? ",1,time is documented as safe for concurrent use but unmarshal methods do not synchronize time time is documented as being safe for concurrent use however some methods modify it without synchronization gobdecode unmarshalbinary unmarshaljson and unmarshaltext it seems like we should update the documentation what s the right way to document the goroutine safety guarantee something like a time value can be used by multiple goroutines simultaneously so long as no goroutine calls an unmarshaler method t gobdecode t unmarshalbinary t unmarshaljson t unmarshaltext ,1 70500,9419186958.0,IssuesEvent,2019-04-10 21:12:32,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/internal/lsp: Wrong symbol kind for the `textDocument/symbol`.,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/henrywong/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/henrywong/workspace/gopath""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/Cellar/go/1.12/libexec""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/fm/bk0wqlkj523gdp9pbtnyvxmm0000gn/T/go-build954865857=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Get the `textDocument/symbol` for the go source file. ```go // The symbol kind for `int_basic_alias` should be `NumberSymbol`, not `StructSymbol`. type int_basic_alias = int ``` ### What did you expect to see? For the type alias, lsp should strip off the type alias to get the essential type. And compute the correct symbol based on the essential type. ```go // The symbol kind for `int_basic_alias` should be `NumberSymbol` type int_basic_alias = int ``` ### What did you see instead? ```go // The symbol kind for `int_basic_alias` is `StructSymbol` type int_basic_alias = int ```",1.0,"x/tools/internal/lsp: Wrong symbol kind for the `textDocument/symbol`. - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/henrywong/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/henrywong/workspace/gopath""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/Cellar/go/1.12/libexec""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/fm/bk0wqlkj523gdp9pbtnyvxmm0000gn/T/go-build954865857=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Get the `textDocument/symbol` for the go source file. ```go // The symbol kind for `int_basic_alias` should be `NumberSymbol`, not `StructSymbol`. type int_basic_alias = int ``` ### What did you expect to see? For the type alias, lsp should strip off the type alias to get the essential type. And compute the correct symbol based on the essential type. ```go // The symbol kind for `int_basic_alias` should be `NumberSymbol` type int_basic_alias = int ``` ### What did you see instead? ```go // The symbol kind for `int_basic_alias` is `StructSymbol` type int_basic_alias = int ```",1,x tools internal lsp wrong symbol kind for the textdocument symbol what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users henrywong library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users henrywong workspace gopath goproxy gorace goroot usr local cellar go libexec gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders fm t go tmp go build gno record gcc switches fno common what did you do get the textdocument symbol for the go source file if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best go the symbol kind for int basic alias should be numbersymbol not structsymbol type int basic alias int what did you expect to see for the type alias lsp should strip off the type alias to get the essential type and compute the correct symbol based on the essential type go the symbol kind for int basic alias should be numbersymbol type int basic alias int what did you see instead go the symbol kind for int basic alias is structsymbol type int basic alias int ,1 190501,15241005010.0,IssuesEvent,2021-02-19 07:43:29,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: ""Writing Web Applications"" Link in Go documentation is broken",Documentation," ### What version of Go are you using (`go version`)? 
$ go version
NA
### Does this issue reproduce with the latest release? NA ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
NA
### What did you do? 1. Go to https://golang.org/doc 2. Click on ""Writing Web Applications"" 3. It redirects to ""https://golang.org/doc/articles/wiki/"" where it simply says ""open REDACTED: file does not exist"" ### What did you expect to see? I expected a sample web application ### What did you see instead? Some random error message ""open REDACTED: file does not exist""",1.0,"x/website: ""Writing Web Applications"" Link in Go documentation is broken - ### What version of Go are you using (`go version`)? 
$ go version
NA
### Does this issue reproduce with the latest release? NA ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
NA
### What did you do? 1. Go to https://golang.org/doc 2. Click on ""Writing Web Applications"" 3. It redirects to ""https://golang.org/doc/articles/wiki/"" where it simply says ""open REDACTED: file does not exist"" ### What did you expect to see? I expected a sample web application ### What did you see instead? Some random error message ""open REDACTED: file does not exist""",1,x website writing web applications link in go documentation is broken please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version na does this issue reproduce with the latest release na what operating system and processor architecture are you using go env go env output go env na 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 go to click on writing web applications it redirects to where it simply says open redacted file does not exist what did you expect to see i expected a sample web application what did you see instead some random error message open redacted file does not exist ,1 173894,14441461608.0,IssuesEvent,2020-12-07 16:49:30,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: add release note for rejection of non-ASCII import paths in module mode,Documentation NeedsFix release-blocker,"In [CL 251878](https://golang.org/cl/251878) (for #29101), we tightened up the import-path check in module mode so that it now disallows all non-ASCII _package import_ paths, not just non-ASCII _module_ paths (see https://github.com/golang/go/issues/29101#issuecomment-639050809). Although we believe the number of affected packages to be very small, we should add a release note for this change so that users can easily verify that the change was intentional (see #43035). CC @jayconrod @matloob @maruel",1.0,"cmd/go: add release note for rejection of non-ASCII import paths in module mode - In [CL 251878](https://golang.org/cl/251878) (for #29101), we tightened up the import-path check in module mode so that it now disallows all non-ASCII _package import_ paths, not just non-ASCII _module_ paths (see https://github.com/golang/go/issues/29101#issuecomment-639050809). Although we believe the number of affected packages to be very small, we should add a release note for this change so that users can easily verify that the change was intentional (see #43035). CC @jayconrod @matloob @maruel",1,cmd go add release note for rejection of non ascii import paths in module mode in for we tightened up the import path check in module mode so that it now disallows all non ascii package import paths not just non ascii module paths see although we believe the number of affected packages to be very small we should add a release note for this change so that users can easily verify that the change was intentional see cc jayconrod matloob maruel,1 113785,11816310359.0,IssuesEvent,2020-03-20 08:43:54,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: Potential reference to wrong variable name ""TitleValidator""",Documentation NeedsFix help wanted,"While reading this article: https://golang.org/doc/articles/wiki/ I got to the point where the author is explaining how the `makeHandler` function uses the regex created earlier to validate the `title` provided by the user. > The closure extracts the title from the request path, and validates it with the `TitleValidator` regexp. The actual variable name is `validPath`. From the way the explanation is written, it seems that the text should instead be: > The closure extracts the title from the request path, and validates it with the `validPath` regexp. --- Many thanks for writing this article. I learned a lot and plan to reference it often as I continue to learn more about Go and writing web apps.",1.0,"x/website: Potential reference to wrong variable name ""TitleValidator"" - While reading this article: https://golang.org/doc/articles/wiki/ I got to the point where the author is explaining how the `makeHandler` function uses the regex created earlier to validate the `title` provided by the user. > The closure extracts the title from the request path, and validates it with the `TitleValidator` regexp. The actual variable name is `validPath`. From the way the explanation is written, it seems that the text should instead be: > The closure extracts the title from the request path, and validates it with the `validPath` regexp. --- Many thanks for writing this article. I learned a lot and plan to reference it often as I continue to learn more about Go and writing web apps.",1,x website potential reference to wrong variable name titlevalidator while reading this article i got to the point where the author is explaining how the makehandler function uses the regex created earlier to validate the title provided by the user the closure extracts the title from the request path and validates it with the titlevalidator regexp the actual variable name is validpath from the way the explanation is written it seems that the text should instead be the closure extracts the title from the request path and validates it with the validpath regexp many thanks for writing this article i learned a lot and plan to reference it often as i continue to learn more about go and writing web apps ,1 89837,10617592492.0,IssuesEvent,2019-10-12 20:13:29,golang/go,https://api.github.com/repos/golang/go,closed,doc:,Documentation,It would be nice for the JSON mode of golang.org/dl to be documented somewhere. I wasn't able to find it until after I built a project to recreate the same functionality and someone pointed it out.,1.0,doc: - It would be nice for the JSON mode of golang.org/dl to be documented somewhere. I wasn't able to find it until after I built a project to recreate the same functionality and someone pointed it out.,1,doc it would be nice for the json mode of golang org dl to be documented somewhere i wasn t able to find it until after i built a project to recreate the same functionality and someone pointed it out ,1 15654,6022465786.0,IssuesEvent,2017-06-07 21:07:37,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/relnotes: write release notes helper tool,Builders NeedsFix,"I previously wrote https://go-review.googlesource.com/c/30697/ to help write Go 1.8's release notes. For Go 1.9 we started leaving comments on Gerrit (or somethings Github?) with RELNOTE=(subject). But people have written different forms, e.g. RELNOTE=yes RELNOTES=yes REL_NOTES=1 So, support them all. /cc @kevinburke (this will need Gerrit comment parsing in maintner) ",1.0,"x/build/cmd/relnotes: write release notes helper tool - I previously wrote https://go-review.googlesource.com/c/30697/ to help write Go 1.8's release notes. For Go 1.9 we started leaving comments on Gerrit (or somethings Github?) with RELNOTE=(subject). But people have written different forms, e.g. RELNOTE=yes RELNOTES=yes REL_NOTES=1 So, support them all. /cc @kevinburke (this will need Gerrit comment parsing in maintner) ",0,x build cmd relnotes write release notes helper tool i previously wrote to help write go s release notes for go we started leaving comments on gerrit or somethings github with relnote subject but people have written different forms e g relnote yes relnotes yes rel notes so support them all cc kevinburke this will need gerrit comment parsing in maintner ,0 237686,18167765197.0,IssuesEvent,2021-09-27 16:17:36,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: remove references to 'go help fuzz',Documentation NeedsFix GoCommand fuzz," ### What version of Go are you using (`go version`)? tip 
$ go version
go version devel go1.18-8854368cb0 Sat Sep 25 01:24:46 2021 +0000 linux/amd64
### Does this issue reproduce with the latest release? I did not check for the release, but the tip of `master` branch [as of 25-Sep-2021] ### What operating system and processor architecture are you using (`go env`)?
go env Output 
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/mfrw/.cache/go-build""
GOENV=""/home/mfrw/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/mfrw/g/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/mfrw/g""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/mfrw/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/mfrw/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.18-8854368cb0 Sat Sep 25 01:24:46 2021 +0000""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/mfrw/go/src/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-build6268976=/tmp/go-build -gno-record-gcc-switches""
### What did you do? `go help fuzz` ### What did you expect to see? Help about fuzzing. ### What did you see instead? go help fuzz: unknown help topic. Run 'go help'. Although: git branch --contains [2212a1a339c7ac72ff2133855c97ae097444cb5c](https://go-review.googlesource.com/c/go/+/317973) has `master` Maybe I am missing something trivial :( Apologies in advance if its known already or if its by design.",1.0,"cmd/go: remove references to 'go help fuzz' - ### What version of Go are you using (`go version`)? tip 
$ go version
go version devel go1.18-8854368cb0 Sat Sep 25 01:24:46 2021 +0000 linux/amd64
### Does this issue reproduce with the latest release? I did not check for the release, but the tip of `master` branch [as of 25-Sep-2021] ### What operating system and processor architecture are you using (`go env`)?
go env Output 
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/mfrw/.cache/go-build""
GOENV=""/home/mfrw/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/mfrw/g/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/mfrw/g""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/mfrw/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/mfrw/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""devel go1.18-8854368cb0 Sat Sep 25 01:24:46 2021 +0000""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/mfrw/go/src/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-build6268976=/tmp/go-build -gno-record-gcc-switches""
### What did you do? `go help fuzz` ### What did you expect to see? Help about fuzzing. ### What did you see instead? go help fuzz: unknown help topic. Run 'go help'. Although: git branch --contains [2212a1a339c7ac72ff2133855c97ae097444cb5c](https://go-review.googlesource.com/c/go/+/317973) has `master` Maybe I am missing something trivial :( Apologies in advance if its known already or if its by design.",1,cmd go remove references to go help fuzz please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version tip go version go version devel sat sep linux does this issue reproduce with the latest release i did not check for the release but the tip of master branch what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home mfrw cache go build goenv home mfrw config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home mfrw g pkg mod gonoproxy gonosumdb goos linux gopath home mfrw g goprivate goproxy goroot home mfrw go gosumdb sum golang org gotmpdir gotooldir home mfrw go pkg tool linux govcs goversion devel sat sep gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home mfrw go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 go help fuzz what did you expect to see help about fuzzing what did you see instead go help fuzz unknown help topic run go help although git branch contains has master maybe i am missing something trivial apologies in advance if its known already or if its by design ,1 43594,7054602837.0,IssuesEvent,2018-01-04 01:57:03,golang/go,https://api.github.com/repos/golang/go,closed,testing: test naming guidelines are inconsistent with real-world practice,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 1.9.2 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? linux amd64 ### What did you do? ``` $ cat << EOF > foo_test.go package foo import ""testing"" func Test_Foo(t *testing.T) { println(""hello"") } EOF ``` ``` $ go test -v ./ ``` ### What did you expect to see? ``` ok _/some/dir 0.001s [no tests to run] ``` ### What did you see instead? ``` === RUN Test_Foo hello --- PASS: Test_Foo (0.00s) PASS ok _/some/dir 0.002s ``` Official documentation for Go [testing](https://golang.org/pkg/testing/) package states, that `go test` > automates execution of any function of the form `func TestXxx(*testing.T)` where `Xxx` can be any **alphanumeric** string (but the first letter must not be in [a-z]) and serves to identify the test routine. There are tons of open-source go projects that use `_` (underscore) in tests names (although all Google projects I've seen so far do follow these naming guidelines), yet `_` is not _alphanumeric_ and, according to the documentation, should not work. I believe either this statement in documentation has to be clarified or `go test` behavior has to be adjusted to conform to the documentation (unlikely, considering how ubiquitous `_` became) ",1.0,"testing: test naming guidelines are inconsistent with real-world practice - ### What version of Go are you using (`go version`)? 1.9.2 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? linux amd64 ### What did you do? ``` $ cat << EOF > foo_test.go package foo import ""testing"" func Test_Foo(t *testing.T) { println(""hello"") } EOF ``` ``` $ go test -v ./ ``` ### What did you expect to see? ``` ok _/some/dir 0.001s [no tests to run] ``` ### What did you see instead? ``` === RUN Test_Foo hello --- PASS: Test_Foo (0.00s) PASS ok _/some/dir 0.002s ``` Official documentation for Go [testing](https://golang.org/pkg/testing/) package states, that `go test` > automates execution of any function of the form `func TestXxx(*testing.T)` where `Xxx` can be any **alphanumeric** string (but the first letter must not be in [a-z]) and serves to identify the test routine. There are tons of open-source go projects that use `_` (underscore) in tests names (although all Google projects I've seen so far do follow these naming guidelines), yet `_` is not _alphanumeric_ and, according to the documentation, should not work. I believe either this statement in documentation has to be clarified or `go test` behavior has to be adjusted to conform to the documentation (unlikely, considering how ubiquitous `_` became) ",1,testing test naming guidelines are inconsistent with real world practice what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env linux what did you do cat foo test go package foo import testing func test foo t testing t println hello eof go test v what did you expect to see ok some dir what did you see instead run test foo hello pass test foo pass ok some dir official documentation for go package states that go test automates execution of any function of the form func testxxx testing t where xxx can be any alphanumeric string but the first letter must not be in and serves to identify the test routine there are tons of open source go projects that use underscore in tests names although all google projects i ve seen so far do follow these naming guidelines yet is not alphanumeric and according to the documentation should not work i believe either this statement in documentation has to be clarified or go test behavior has to be adjusted to conform to the documentation unlikely considering how ubiquitous became ,1 61447,8519434360.0,IssuesEvent,2018-11-01 14:42:43,golang/go,https://api.github.com/repos/golang/go,closed,doc: contribute: sending a change gerrit: incorrect language,Documentation,"### What did you do and see? https://golang.org/doc/contribute.html#sending_a_change_gerrit There is a sentence: > It's different but powerful and familiarity with help you understand the flow. ### What did you expect to see? > It's different but powerful and familiarity with it will help you understand the flow.",1.0,"doc: contribute: sending a change gerrit: incorrect language - ### What did you do and see? https://golang.org/doc/contribute.html#sending_a_change_gerrit There is a sentence: > It's different but powerful and familiarity with help you understand the flow. ### What did you expect to see? > It's different but powerful and familiarity with it will help you understand the flow.",1,doc contribute sending a change gerrit incorrect language what did you do and see there is a sentence it s different but powerful and familiarity with help you understand the flow what did you expect to see it s different but powerful and familiarity with it will help you understand the flow ,1 317318,23671736220.0,IssuesEvent,2022-08-27 13:11:59,golang/go,https://api.github.com/repos/golang/go,closed,site: https://golang.org/doc/install incorrectly lists minumum kernel version for linux/arm as 2.6.23,Documentation NeedsInvestigation,"https://golang.org/doc/install states that the minimum kernel version for all linux platform is 2.6.23. This is not correct. The minimum for linux/arm is 2.6.27 (possibly 28), however this contradicts information from the wiki, https://github.com/golang/go/wiki/Linux See #3897 See also https://codereview.appspot.com/7225047/ ",1.0,"site: https://golang.org/doc/install incorrectly lists minumum kernel version for linux/arm as 2.6.23 - https://golang.org/doc/install states that the minimum kernel version for all linux platform is 2.6.23. This is not correct. The minimum for linux/arm is 2.6.27 (possibly 28), however this contradicts information from the wiki, https://github.com/golang/go/wiki/Linux See #3897 See also https://codereview.appspot.com/7225047/ ",1,site incorrectly lists minumum kernel version for linux arm as states that the minimum kernel version for all linux platform is this is not correct the minimum for linux arm is possibly however this contradicts information from the wiki see see also ,1 123080,12191788361.0,IssuesEvent,2020-04-29 11:48:21,golang/go,https://api.github.com/repos/golang/go,closed,image: NewUniform doesn't have documentation,Documentation NeedsFix,"The [`image.NewUniform`](https://golang.org/pkg/image/#NewUniform) function is exported and should have a comment per https://golang.org/doc/effective_go.html#commentary. This came up when I realized it's not clear whether it's better to write `image.NewUniform(c)` or `&image.Uniform{c}`. I thought maybe `image.NewUniform` is deprecated like `image.ZP`, but that's not the case given it doesn't even have a comment. But it's not easy to feel confident using an exported method in the Go standard library when it's not documented. https://blog.golang.org/image-draw prefers `&image.Uniform{c}` style, but it's also from 2011. `NewUniform` was renamed from `NewColorImage` in 2011, so it has existed for quite a while. /cc @nigeltao @robpike",1.0,"image: NewUniform doesn't have documentation - The [`image.NewUniform`](https://golang.org/pkg/image/#NewUniform) function is exported and should have a comment per https://golang.org/doc/effective_go.html#commentary. This came up when I realized it's not clear whether it's better to write `image.NewUniform(c)` or `&image.Uniform{c}`. I thought maybe `image.NewUniform` is deprecated like `image.ZP`, but that's not the case given it doesn't even have a comment. But it's not easy to feel confident using an exported method in the Go standard library when it's not documented. https://blog.golang.org/image-draw prefers `&image.Uniform{c}` style, but it's also from 2011. `NewUniform` was renamed from `NewColorImage` in 2011, so it has existed for quite a while. /cc @nigeltao @robpike",1,image newuniform doesn t have documentation the function is exported and should have a comment per this came up when i realized it s not clear whether it s better to write image newuniform c or image uniform c i thought maybe image newuniform is deprecated like image zp but that s not the case given it doesn t even have a comment but it s not easy to feel confident using an exported method in the go standard library when it s not documented prefers image uniform c style but it s also from newuniform was renamed from newcolorimage in so it has existed for quite a while cc nigeltao robpike,1 444690,31142595228.0,IssuesEvent,2023-08-16 02:08:06,golang/go,https://api.github.com/repos/golang/go,closed,bufio: Scanner considers a buffer of length = len(token) as not enough,Documentation help wanted NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15 darwin/amd64
### Does this issue reproduce with the latest release? Haven't tried ### What operating system and processor architecture are you using (`go env`)?
go env Output
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/k0nst4nt1n/Library/Caches/go-build""
GOENV=""/Users/k0nst4nt1n/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/k0nst4nt1n/_gopath/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/k0nst4nt1n/_gopath""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.15/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.15/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/3q/jr3whwkn13ld3j1s1xms0v4w0000gp/T/go-build070878361=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Golang bufio.Scanner considers a buffer of length = len(token) as not enough, please see example below: (full code is here https://play.golang.org/p/3e95HG3j4H-) ``` func main() { d1 := ""12"" // data size == 2 r1 := strings.NewReader(d1) s1 := bufio.NewScanner(r1) s1.Split(bufio.ScanLines) s1.Buffer(make([]byte, len(d1)), len(d1)) // buf size == 2 _ = s1.Scan() fmt.Printf(""Token=%s, Err=%v\n"", s1.Text(), s1.Err()) } ``` ### What did you expect to see? No error (output: `Token=12, Err=`) ### What did you see instead? Error (output: `Token=, Err=bufio.Scanner: token too long`) ",1.0,"bufio: Scanner considers a buffer of length = len(token) as not enough - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15 darwin/amd64
### Does this issue reproduce with the latest release? Haven't tried ### What operating system and processor architecture are you using (`go env`)?
go env Output
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/k0nst4nt1n/Library/Caches/go-build""
GOENV=""/Users/k0nst4nt1n/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/k0nst4nt1n/_gopath/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/k0nst4nt1n/_gopath""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.15/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.15/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/3q/jr3whwkn13ld3j1s1xms0v4w0000gp/T/go-build070878361=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Golang bufio.Scanner considers a buffer of length = len(token) as not enough, please see example below: (full code is here https://play.golang.org/p/3e95HG3j4H-) ``` func main() { d1 := ""12"" // data size == 2 r1 := strings.NewReader(d1) s1 := bufio.NewScanner(r1) s1.Split(bufio.ScanLines) s1.Buffer(make([]byte, len(d1)), len(d1)) // buf size == 2 _ = s1.Scan() fmt.Printf(""Token=%s, Err=%v\n"", s1.Text(), s1.Err()) } ``` ### What did you expect to see? No error (output: `Token=12, Err=`) ### What did you see instead? Error (output: `Token=, Err=bufio.Scanner: token too long`) ",1,bufio scanner considers a buffer of length len token as not enough please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release haven t tried what operating system and processor architecture are you using go env go env output goarch gobin gocache users library caches go build goenv users library application support go env goexe goflags gohostarch gohostos darwin goinsecure gomodcache users gopath pkg mod gonoproxy gonosumdb goos darwin gopath users gopath goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common 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 golang bufio scanner considers a buffer of length len token as not enough please see example below full code is here func main data size strings newreader bufio newscanner split bufio scanlines buffer make byte len len buf size scan fmt printf token s err v n text err what did you expect to see no error output token err what did you see instead error output token err bufio scanner token too long ,1 126070,12281264895.0,IssuesEvent,2020-05-08 15:32:41,golang/go,https://api.github.com/repos/golang/go,reopened,cmd/go: document build constraints in 'go help',Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
go version devel +a50c3ffbd4 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/usr/local/google/home/pjw/.cache/go-build""
GOENV=""/usr/local/google/home/pjw/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
### What did you do? In x/tools/internal/lsp/span/uri_windows_test.go I removed // +build window, and renamed the test function to TestURIA (to avoid conflicts with uri_test.go) I then ran go test -run URI . ### What did you expect to see? I expected to see it run TestURI (from uri_test.go) and TestURIA (from uri_windows_test.go) ### What did you see instead? It just ran TestURI [If I rename uri_window_test.go then go test will run TestURIA]",1.0,"cmd/go: document build constraints in 'go help' - ### What version of Go are you using (`go version`)? 
go version devel +a50c3ffbd4 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/usr/local/google/home/pjw/.cache/go-build""
GOENV=""/usr/local/google/home/pjw/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
### What did you do? In x/tools/internal/lsp/span/uri_windows_test.go I removed // +build window, and renamed the test function to TestURIA (to avoid conflicts with uri_test.go) I then ran go test -run URI . ### What did you expect to see? I expected to see it run TestURI (from uri_test.go) and TestURIA (from uri_windows_test.go) ### What did you see instead? It just ran TestURI [If I rename uri_window_test.go then go test will run TestURIA]",1,cmd go document build constraints in go help please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version devel linux does this issue reproduce with the latest release what operating system and processor architecture are you using go env go env output goarch gobin gocache usr local google home pjw cache go build goenv usr local google home pjw config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux what did you do in x tools internal lsp span uri windows test go i removed build window and renamed the test function to testuria to avoid conflicts with uri test go i then ran go test run uri what did you expect to see i expected to see it run testuri from uri test go and testuria from uri windows test go what did you see instead it just ran testuri ,1 298089,25785753238.0,IssuesEvent,2022-12-09 20:13:33,golang/go,https://api.github.com/repos/golang/go,closed,net: reenable TestLookupDotsWithRemoteSource and TestLookupGoogleSRV with a different target [1.19 backport],Testing CherryPickApproved,"@mknyszek requested issue #56708 to be considered for backport to the next 1.19 minor release. > @gopherbot Please open backport a backport issue for Go 1.18 and Go 1.19 since the same workaround and test skips were applied there. ",1.0,"net: reenable TestLookupDotsWithRemoteSource and TestLookupGoogleSRV with a different target [1.19 backport] - @mknyszek requested issue #56708 to be considered for backport to the next 1.19 minor release. > @gopherbot Please open backport a backport issue for Go 1.18 and Go 1.19 since the same workaround and test skips were applied there. ",0,net reenable testlookupdotswithremotesource and testlookupgooglesrv with a different target mknyszek requested issue to be considered for backport to the next minor release gopherbot please open backport a backport issue for go and go since the same workaround and test skips were applied there ,0 65085,8787304684.0,IssuesEvent,2018-12-20 18:13:40,golang/go,https://api.github.com/repos/golang/go,closed,os: clarify documentation for O_TRUNC,Documentation NeedsInvestigation,"The comment for `os.O_TRUNC` currently says: https://github.com/golang/go/blob/78c0e1f81d4052f8ca5a50e4e7c5bb35ddec6519/src/os/file.go#L76 The “if possible” part of that comment is ambiguous: on Linux it seems to mean “if the file is a regular file or symlink to a regular file” (i.e., not a stream like `/dev/stdout`), but it could be “impossible” to truncate the file for other reasons (such as a permission error), and `os.OpenFile` with `os.O_TRUNC` seems to report an error in those cases. We should drop the “if possible” phrase and instead explicitly document the conditions under which `O_TRUNC` is ignored.",1.0,"os: clarify documentation for O_TRUNC - The comment for `os.O_TRUNC` currently says: https://github.com/golang/go/blob/78c0e1f81d4052f8ca5a50e4e7c5bb35ddec6519/src/os/file.go#L76 The “if possible” part of that comment is ambiguous: on Linux it seems to mean “if the file is a regular file or symlink to a regular file” (i.e., not a stream like `/dev/stdout`), but it could be “impossible” to truncate the file for other reasons (such as a permission error), and `os.OpenFile` with `os.O_TRUNC` seems to report an error in those cases. We should drop the “if possible” phrase and instead explicitly document the conditions under which `O_TRUNC` is ignored.",1,os clarify documentation for o trunc the comment for os o trunc currently says the “if possible” part of that comment is ambiguous on linux it seems to mean “if the file is a regular file or symlink to a regular file” i e not a stream like dev stdout but it could be “impossible” to truncate the file for other reasons such as a permission error and os openfile with os o trunc seems to report an error in those cases we should drop the “if possible” phrase and instead explicitly document the conditions under which o trunc is ignored ,1 6394,3019766471.0,IssuesEvent,2015-07-31 00:18:35,golang/go,https://api.github.com/repos/golang/go,closed,doc: Solaris port has many changes for Go 1.5,Documentation,"The release notes for Go 1.5 beta 3 omit a number of interesting changes made for the Solaris port of Go, some of which are bug fixes and others much larger feature support additions: * crypto/x509 now works ""out-of-the-box"" as the ""standard"" locations for the system-wide CA certificates file has been added * net package should now be fully functional (sendfile, socket options in particular) * cgo fully supported and enabled by default Oracle sponsored most of the work for the last two items via contracting Aram Hăvărneanu. There are of course numerous other bug fixes as well that others kindly contributed, but those are the big items that I'm aware of.",1.0,"doc: Solaris port has many changes for Go 1.5 - The release notes for Go 1.5 beta 3 omit a number of interesting changes made for the Solaris port of Go, some of which are bug fixes and others much larger feature support additions: * crypto/x509 now works ""out-of-the-box"" as the ""standard"" locations for the system-wide CA certificates file has been added * net package should now be fully functional (sendfile, socket options in particular) * cgo fully supported and enabled by default Oracle sponsored most of the work for the last two items via contracting Aram Hăvărneanu. There are of course numerous other bug fixes as well that others kindly contributed, but those are the big items that I'm aware of.",1,doc solaris port has many changes for go the release notes for go beta omit a number of interesting changes made for the solaris port of go some of which are bug fixes and others much larger feature support additions crypto now works out of the box as the standard locations for the system wide ca certificates file has been added net package should now be fully functional sendfile socket options in particular cgo fully supported and enabled by default oracle sponsored most of the work for the last two items via contracting aram hăvărneanu there are of course numerous other bug fixes as well that others kindly contributed but those are the big items that i m aware of ,1 95866,27642688459.0,IssuesEvent,2023-03-10 19:33:44,golang/go,https://api.github.com/repos/golang/go,opened,x/build: missing host-android-arm64-corellium-android host,Builders NeedsFix,"Currently at https://farmer.golang.org/#pools: ``` host-android-arm64-corellium-android: 2/2 (1 missing) ``` CC @golang/release",1.0,"x/build: missing host-android-arm64-corellium-android host - Currently at https://farmer.golang.org/#pools: ``` host-android-arm64-corellium-android: 2/2 (1 missing) ``` CC @golang/release",0,x build missing host android corellium android host currently at host android corellium android missing cc golang release,0 98997,11102513446.0,IssuesEvent,2019-12-17 00:19:11,golang/go,https://api.github.com/repos/golang/go,closed,time: Timer.Stop documentation not covering all the cases,Documentation WaitingForInfo,"Hello, In the section where the Stop method of a timer object is described there is a snippet about ensuring to drain the channel in case this method returns False. However, it does not mention explicitly that this code snippet works only when the Stop returns False in case the timer has already expired. Because only in this case the channel read will not block. If the timer is already stopped , this operation will block indefinitely, therefore will not drain the channel since no value will be ever sent. ",1.0,"time: Timer.Stop documentation not covering all the cases - Hello, In the section where the Stop method of a timer object is described there is a snippet about ensuring to drain the channel in case this method returns False. However, it does not mention explicitly that this code snippet works only when the Stop returns False in case the timer has already expired. Because only in this case the channel read will not block. If the timer is already stopped , this operation will block indefinitely, therefore will not drain the channel since no value will be ever sent. ",1,time timer stop documentation not covering all the cases hello in the section where the stop method of a timer object is described there is a snippet about ensuring to drain the channel in case this method returns false however it does not mention explicitly that this code snippet works only when the stop returns false in case the timer has already expired because only in this case the channel read will not block if the timer is already stopped this operation will block indefinitely therefore will not drain the channel since no value will be ever sent ,1 2282,2674186104.0,IssuesEvent,2015-03-24 23:57:13,golang/go,https://api.github.com/repos/golang/go,closed,net/url: inaccurate documentation for method URL.String,documentation,"go version: 1.4.2 problem: The [godoc](http://golang.org/pkg/net/url/#URL.String) for URL.String in ""net/url"" does not accurately describe the method's behavior when the Opaque field is set. > scheme:opaque > scheme://userinfo@host/path?query#fragment > If u.Opaque is non-empty, String uses the first form; otherwise it uses the second form. The following playground link demonstrates a `*url.URL` which does not fall into these categories. http://play.golang.org/p/SPGP5eSieA The documentation states that the snippet should print ""https://example.com/foo"". But they observed string is ""https://example.com/foo?bar=baz#qux""",1.0,"net/url: inaccurate documentation for method URL.String - go version: 1.4.2 problem: The [godoc](http://golang.org/pkg/net/url/#URL.String) for URL.String in ""net/url"" does not accurately describe the method's behavior when the Opaque field is set. > scheme:opaque > scheme://userinfo@host/path?query#fragment > If u.Opaque is non-empty, String uses the first form; otherwise it uses the second form. The following playground link demonstrates a `*url.URL` which does not fall into these categories. http://play.golang.org/p/SPGP5eSieA The documentation states that the snippet should print ""https://example.com/foo"". But they observed string is ""https://example.com/foo?bar=baz#qux""",1,net url inaccurate documentation for method url string go version problem the for url string in net url does not accurately describe the method s behavior when the opaque field is set scheme opaque scheme userinfo host path query fragment if u opaque is non empty string uses the first form otherwise it uses the second form the following playground link demonstrates a url url which does not fall into these categories the documentation states that the snippet should print but they observed string is ,1 7601,3105002971.0,IssuesEvent,2015-08-31 18:44:38,golang/go,https://api.github.com/repos/golang/go,closed,fmt: example format for %e and %E float verbs is incorrect,Documentation,"From http://golang.org/pkg/fmt/: %e scientific notation, e.g. -1234.456e+78 %E scientific notation, e.g. -1234.456E+78 while it should be (one non-zero digit before decimal point): %e scientific notation, e.g. -1.234567e+78 %E scientific notation, e.g. -1.234567E+78 http://play.golang.org/p/llGQ0mAT73 ",1.0,"fmt: example format for %e and %E float verbs is incorrect - From http://golang.org/pkg/fmt/: %e scientific notation, e.g. -1234.456e+78 %E scientific notation, e.g. -1234.456E+78 while it should be (one non-zero digit before decimal point): %e scientific notation, e.g. -1.234567e+78 %E scientific notation, e.g. -1.234567E+78 http://play.golang.org/p/llGQ0mAT73 ",1,fmt example format for e and e float verbs is incorrect from e scientific notation e g e scientific notation e g while it should be one non zero digit before decimal point e scientific notation e g e scientific notation e g ,1 81182,23409357481.0,IssuesEvent,2022-08-12 15:47:52,golang/go,https://api.github.com/repos/golang/go,closed,x/build: linux-386-longtest and linux-amd64-noopt failed,Builders NeedsInvestigation compiler/runtime,"The failure started since https://go-review.googlesource.com/c/go/+/419447 cc @prattmic ",1.0,"x/build: linux-386-longtest and linux-amd64-noopt failed - The failure started since https://go-review.googlesource.com/c/go/+/419447 cc @prattmic ",0,x build linux longtest and linux noopt failed the failure started since cc prattmic ,0 53554,28238721844.0,IssuesEvent,2023-04-06 04:35:54,golang/go,https://api.github.com/repos/golang/go,opened,crypto/internal/bigmod: switch to saturated limbs,Performance NeedsFix release-blocker,"Package bigmod uses unsaturated 63-bit limbs because the tradition suggests that's faster, but that might be only true when targeting portable C. With access to add-with-carry instructions, Montgomery multiplication can be much faster with sautrated limbs, and we already have optimized assembly for that in math/big. Switching bigmod to saturated limbs should allow us to reuse the math/big assembly cores, getting RSA performance back to Go 1.19 levels. https://go.dev/cl/471259",True,"crypto/internal/bigmod: switch to saturated limbs - Package bigmod uses unsaturated 63-bit limbs because the tradition suggests that's faster, but that might be only true when targeting portable C. With access to add-with-carry instructions, Montgomery multiplication can be much faster with sautrated limbs, and we already have optimized assembly for that in math/big. Switching bigmod to saturated limbs should allow us to reuse the math/big assembly cores, getting RSA performance back to Go 1.19 levels. https://go.dev/cl/471259",0,crypto internal bigmod switch to saturated limbs package bigmod uses unsaturated bit limbs because the tradition suggests that s faster but that might be only true when targeting portable c with access to add with carry instructions montgomery multiplication can be much faster with sautrated limbs and we already have optimized assembly for that in math big switching bigmod to saturated limbs should allow us to reuse the math big assembly cores getting rsa performance back to go levels ,0 129734,12417791898.0,IssuesEvent,2020-05-22 21:41:29,golang/go,https://api.github.com/repos/golang/go,opened,go/printer: CommentedNode behavior is partially undocumented,Documentation NeedsInvestigation,"### What did you do? I read the documentation of package `go/printer` in order to understand how to use `printer.CommentedNode`. ### What did you expect to see? Documentation that would allow me to learn an answer to the question of ""what happens to comments that are already a part of the `Node` being wrapped in a `printer.CommentedNode`?"" without having to also read the source code. ### What did you see instead? Insufficient documentation to know what the behavior is. `CommentedNode` is currently defined as: ```Go // A CommentedNode bundles an AST node and corresponding comments. // It may be provided as argument to any of the Fprint functions. // type CommentedNode struct { Node interface{} // *ast.File, or ast.Expr, ast.Decl, ast.Spec, or ast.Stmt Comments []*ast.CommentGroup } ``` It is also mentioned in the documentation of the `Config.Fprint` method: ```Go // Fprint ""pretty-prints"" an AST node to output for a given configuration cfg. // Position information is interpreted relative to the file set fset. // The node type must be *ast.File, *CommentedNode, []ast.Decl, []ast.Stmt, // or assignment-compatible to ast.Expr, ast.Decl, ast.Spec, or ast.Stmt. // func (cfg *Config) Fprint(output io.Writer, fset *token.FileSet, node interface{}) error ``` As well as the `format.Node` function, but there isn't additional relevant information there. /cc @griesemer @josharian",1.0,"go/printer: CommentedNode behavior is partially undocumented - ### What did you do? I read the documentation of package `go/printer` in order to understand how to use `printer.CommentedNode`. ### What did you expect to see? Documentation that would allow me to learn an answer to the question of ""what happens to comments that are already a part of the `Node` being wrapped in a `printer.CommentedNode`?"" without having to also read the source code. ### What did you see instead? Insufficient documentation to know what the behavior is. `CommentedNode` is currently defined as: ```Go // A CommentedNode bundles an AST node and corresponding comments. // It may be provided as argument to any of the Fprint functions. // type CommentedNode struct { Node interface{} // *ast.File, or ast.Expr, ast.Decl, ast.Spec, or ast.Stmt Comments []*ast.CommentGroup } ``` It is also mentioned in the documentation of the `Config.Fprint` method: ```Go // Fprint ""pretty-prints"" an AST node to output for a given configuration cfg. // Position information is interpreted relative to the file set fset. // The node type must be *ast.File, *CommentedNode, []ast.Decl, []ast.Stmt, // or assignment-compatible to ast.Expr, ast.Decl, ast.Spec, or ast.Stmt. // func (cfg *Config) Fprint(output io.Writer, fset *token.FileSet, node interface{}) error ``` As well as the `format.Node` function, but there isn't additional relevant information there. /cc @griesemer @josharian",1,go printer commentednode behavior is partially undocumented what did you do i read the documentation of package go printer in order to understand how to use printer commentednode what did you expect to see documentation that would allow me to learn an answer to the question of what happens to comments that are already a part of the node being wrapped in a printer commentednode without having to also read the source code what did you see instead insufficient documentation to know what the behavior is commentednode is currently defined as go a commentednode bundles an ast node and corresponding comments it may be provided as argument to any of the fprint functions type commentednode struct node interface ast file or ast expr ast decl ast spec or ast stmt comments ast commentgroup it is also mentioned in the documentation of the config fprint method go fprint pretty prints an ast node to output for a given configuration cfg position information is interpreted relative to the file set fset the node type must be ast file commentednode ast decl ast stmt or assignment compatible to ast expr ast decl ast spec or ast stmt func cfg config fprint output io writer fset token fileset node interface error as well as the format node function but there isn t additional relevant information there cc griesemer josharian,1 245742,18792487874.0,IssuesEvent,2021-11-08 18:17:05,golang/go,https://api.github.com/repos/golang/go,closed,proxy.golang.org: document process for unpublishing compromised modules,Documentation,"Given the recent security incident with the coa and rc node packages, I would like to request that the process for getting compromised module versions unpublished from proxy.golang.org be recorded in the [FAQ](https://proxy.golang.org/) to allow for a speedy resolution should an incident occur. In a situation like this, simply retracting the compromised version is insufficient. Please note that I am NOT intending to report a compromised version of any Go module in this issue. I'm just looking for documentation.",1.0,"proxy.golang.org: document process for unpublishing compromised modules - Given the recent security incident with the coa and rc node packages, I would like to request that the process for getting compromised module versions unpublished from proxy.golang.org be recorded in the [FAQ](https://proxy.golang.org/) to allow for a speedy resolution should an incident occur. In a situation like this, simply retracting the compromised version is insufficient. Please note that I am NOT intending to report a compromised version of any Go module in this issue. I'm just looking for documentation.",1,proxy golang org document process for unpublishing compromised modules given the recent security incident with the coa and rc node packages i would like to request that the process for getting compromised module versions unpublished from proxy golang org be recorded in the to allow for a speedy resolution should an incident occur in a situation like this simply retracting the compromised version is insufficient please note that i am not intending to report a compromised version of any go module in this issue i m just looking for documentation ,1 144130,13097047946.0,IssuesEvent,2020-08-03 16:43:58,golang/go,https://api.github.com/repos/golang/go,closed,go.dev: Package URL for docs should end with package name,Documentation go.dev,"This is a UX issue related to how pkg.go.dev works as compared to godoc.org. Here are the API documentation URLs for the zap package, * godoc: https://godoc.org/go.uber.org/zap * pkg.go.dev: https://pkg.go.dev/go.uber.org/zap?tab=doc If I delete the `?tab=doc`, it will end up redirecting with the URL parameter added. Often, a user may want to navigate the package structure using the URL, e.g., Modifying `/zap` to `/zap/zaptest`. To do this with godoc, it was easy as the package name was the last element. With pkg.go.dev, it requires scanning (or deleting) `?tab=doc` before being able to make the modification, making the experience more painful. Since the default go `pkg.go.dev/` is the documentation page, can we also avoid adding the `?tab=doc` suffix to the URL?",1.0,"go.dev: Package URL for docs should end with package name - This is a UX issue related to how pkg.go.dev works as compared to godoc.org. Here are the API documentation URLs for the zap package, * godoc: https://godoc.org/go.uber.org/zap * pkg.go.dev: https://pkg.go.dev/go.uber.org/zap?tab=doc If I delete the `?tab=doc`, it will end up redirecting with the URL parameter added. Often, a user may want to navigate the package structure using the URL, e.g., Modifying `/zap` to `/zap/zaptest`. To do this with godoc, it was easy as the package name was the last element. With pkg.go.dev, it requires scanning (or deleting) `?tab=doc` before being able to make the modification, making the experience more painful. Since the default go `pkg.go.dev/` is the documentation page, can we also avoid adding the `?tab=doc` suffix to the URL?",1,go dev package url for docs should end with package name this is a ux issue related to how pkg go dev works as compared to godoc org here are the api documentation urls for the zap package godoc pkg go dev if i delete the tab doc it will end up redirecting with the url parameter added often a user may want to navigate the package structure using the url e g modifying zap to zap zaptest to do this with godoc it was easy as the package name was the last element with pkg go dev it requires scanning or deleting tab doc before being able to make the modification making the experience more painful since the default go pkg go dev is the documentation page can we also avoid adding the tab doc suffix to the url ,1 8053,3133635928.0,IssuesEvent,2015-09-10 03:34:36,golang/go,https://api.github.com/repos/golang/go,closed,hash: should document byte order of Hash.Sum,Documentation,"Using ```go1.5``` The hash/* libraries [output a slice with the hash in big endian byte order](https://play.golang.org/p/UxXsVEvNNG) when the Hash.Sum([]byte) method is called. This is fine, but it should be documented. This does not apply to crypto hashes since those hashes are long enough (and don't fit in native integer types) that nobody mistakes the byte order.",1.0,"hash: should document byte order of Hash.Sum - Using ```go1.5``` The hash/* libraries [output a slice with the hash in big endian byte order](https://play.golang.org/p/UxXsVEvNNG) when the Hash.Sum([]byte) method is called. This is fine, but it should be documented. This does not apply to crypto hashes since those hashes are long enough (and don't fit in native integer types) that nobody mistakes the byte order.",1,hash should document byte order of hash sum using the hash libraries when the hash sum byte method is called this is fine but it should be documented this does not apply to crypto hashes since those hashes are long enough and don t fit in native integer types that nobody mistakes the byte order ,1 106344,11484953261.0,IssuesEvent,2020-02-11 05:55:50,golang/go,https://api.github.com/repos/golang/go,closed,hash/maphash: Document whether used hash algorithm is stable across future versions,Documentation NeedsFix release-blocker,"The new hash/maphash package in Go 1.14 doesn't make any statement about whether the hash results can differ in future versions or not. At worst people will just assume they won't differ and store those hash values expecting to be able to repeat the hashing given the same values and seeds in the future. I would sleep better when this was made more explicit in the documentation. ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14beta1 linux/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/me/.cache/go-build""
GOENV=""/home/me/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/me/sources/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/snap/go/4962""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/4962/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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/user/1000/go-build057059169=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read documentation of new package https://tip.golang.org/pkg/hash/maphash/ ### What did you expect to see? Documentation on whether the hash function will always deliver the same hash across all Go 1 versions in the future given the same seed and bytes to be hashed. ### What did you see instead? No statement whether I can assume this or not.",1.0,"hash/maphash: Document whether used hash algorithm is stable across future versions - The new hash/maphash package in Go 1.14 doesn't make any statement about whether the hash results can differ in future versions or not. At worst people will just assume they won't differ and store those hash values expecting to be able to repeat the hashing given the same values and seeds in the future. I would sleep better when this was made more explicit in the documentation. ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14beta1 linux/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/me/.cache/go-build""
GOENV=""/home/me/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/me/sources/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/snap/go/4962""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/4962/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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/user/1000/go-build057059169=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read documentation of new package https://tip.golang.org/pkg/hash/maphash/ ### What did you expect to see? Documentation on whether the hash function will always deliver the same hash across all Go 1 versions in the future given the same seed and bytes to be hashed. ### What did you see instead? No statement whether I can assume this or not.",1,hash maphash document whether used hash algorithm is stable across future versions the new hash maphash package in go doesn t make any statement about whether the hash results can differ in future versions or not at worst people will just assume they won t differ and store those hash values expecting to be able to repeat the hashing given the same values and seeds in the future i would sleep better when this was made more explicit in the documentation what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home me cache go build goenv home me config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux gopath home me sources go goprivate goproxy goroot snap go gosumdb sum golang org gotmpdir gotooldir snap go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp user go tmp go build gno record gcc switches what did you do read documentation of new package what did you expect to see documentation on whether the hash function will always deliver the same hash across all go versions in the future given the same seed and bytes to be hashed what did you see instead no statement whether i can assume this or not ,1 755,2622257016.0,IssuesEvent,2015-03-04 00:57:05,golang/go,https://api.github.com/repos/golang/go,closed,build: too many open files in buildlet,builder,"Just observed this new failure when starting a Windows buildlet: ``` builder: windows-amd64-gce rev: 0cdf1d2bc265b6ed8e1b9834ec9f6c59dcecdcfd vm name: buildlet-windows-amd64-gce-0cdf1d2b-rnbb9a0b started: 2015-03-03 00:49:42.356721167 +0000 UTC started: 2015-03-03 00:50:52.996985212 +0000 UTC success: false Events: 2015-03-03T00:49:43Z instance_create_requested +23.2s 2015-03-03T00:50:06Z instance_created +0.1s 2015-03-03T00:50:06Z waiting_for_buildlet +39.0s 2015-03-03T00:50:45Z buildlet_up +0.0s 2015-03-03T00:50:45Z start_write_version_tar +0.0s 2015-03-03T00:50:45Z start_fetch_gerrit_tgz +0.1s 2015-03-03T00:50:45Z start_write_go_tar +0.0s 2015-03-03T00:50:45Z start_write_go14_tar +7.2s 2015-03-03T00:50:52Z end_write_go_tar Build log: Error: Post http://10.240.20.29/writetgz?dir=go1.4: dial tcp 10.240.20.29:80: too many open files ``` Does the buildlet have an fd leak? /cc @adg ",1.0,"build: too many open files in buildlet - Just observed this new failure when starting a Windows buildlet: ``` builder: windows-amd64-gce rev: 0cdf1d2bc265b6ed8e1b9834ec9f6c59dcecdcfd vm name: buildlet-windows-amd64-gce-0cdf1d2b-rnbb9a0b started: 2015-03-03 00:49:42.356721167 +0000 UTC started: 2015-03-03 00:50:52.996985212 +0000 UTC success: false Events: 2015-03-03T00:49:43Z instance_create_requested +23.2s 2015-03-03T00:50:06Z instance_created +0.1s 2015-03-03T00:50:06Z waiting_for_buildlet +39.0s 2015-03-03T00:50:45Z buildlet_up +0.0s 2015-03-03T00:50:45Z start_write_version_tar +0.0s 2015-03-03T00:50:45Z start_fetch_gerrit_tgz +0.1s 2015-03-03T00:50:45Z start_write_go_tar +0.0s 2015-03-03T00:50:45Z start_write_go14_tar +7.2s 2015-03-03T00:50:52Z end_write_go_tar Build log: Error: Post http://10.240.20.29/writetgz?dir=go1.4: dial tcp 10.240.20.29:80: too many open files ``` Does the buildlet have an fd leak? /cc @adg ",0,build too many open files in buildlet just observed this new failure when starting a windows buildlet builder windows gce rev vm name buildlet windows gce started utc started utc success false events instance create requested instance created waiting for buildlet buildlet up start write version tar start fetch gerrit tgz start write go tar start write tar end write go tar build log error post dial tcp too many open files does the buildlet have an fd leak cc adg ,0 87367,10544350980.0,IssuesEvent,2019-10-02 16:44:25,golang/go,https://api.github.com/repos/golang/go,closed,math/rand: package docs don't explain the interval notation,Documentation,"### What version of Go are you using (`go version`)? Whatever version the page at https://golang.org/pkg/math/rand/ is associated with. ### Does this issue reproduce with the latest release? It is present at the https://golang.org/pkg/math/rand/ page. ### What operating system and processor architecture are you using (`go env`)? Not relevant for reading docs. ### What did you do? Reading https://golang.org/pkg/math/rand/ I wanted to understand what interval notation the particular documentation page uses. ### What did you expect to see? ""The documentation for this package uses interval notation with square brackets [, ] to denote included borders and round (, ) to denote excluded. For example, for n>0, [0, n) includes 0 but excludes n."" ### What did you see instead? ""Mathematical interval notation such as [0, n) is used throughout the documentation for this package."" I'm afraid there is no such thing as ""mathematical interval notation"". Different mathematicians define different notation. I propose that the mentioned documentation also properly defines the notation used in it. Ideally directly, or at least linking to the source of that notation. ",1.0,"math/rand: package docs don't explain the interval notation - ### What version of Go are you using (`go version`)? Whatever version the page at https://golang.org/pkg/math/rand/ is associated with. ### Does this issue reproduce with the latest release? It is present at the https://golang.org/pkg/math/rand/ page. ### What operating system and processor architecture are you using (`go env`)? Not relevant for reading docs. ### What did you do? Reading https://golang.org/pkg/math/rand/ I wanted to understand what interval notation the particular documentation page uses. ### What did you expect to see? ""The documentation for this package uses interval notation with square brackets [, ] to denote included borders and round (, ) to denote excluded. For example, for n>0, [0, n) includes 0 but excludes n."" ### What did you see instead? ""Mathematical interval notation such as [0, n) is used throughout the documentation for this package."" I'm afraid there is no such thing as ""mathematical interval notation"". Different mathematicians define different notation. I propose that the mentioned documentation also properly defines the notation used in it. Ideally directly, or at least linking to the source of that notation. ",1,math rand package docs don t explain the interval notation what version of go are you using go version whatever version the page at is associated with does this issue reproduce with the latest release it is present at the page what operating system and processor architecture are you using go env not relevant for reading docs what did you do reading i wanted to understand what interval notation the particular documentation page uses what did you expect to see the documentation for this package uses interval notation with square brackets to denote included borders and round to denote excluded for example for n n includes but excludes n what did you see instead mathematical interval notation such as n is used throughout the documentation for this package i m afraid there is no such thing as mathematical interval notation different mathematicians define different notation i propose that the mentioned documentation also properly defines the notation used in it ideally directly or at least linking to the source of that notation ,1 40784,10578111020.0,IssuesEvent,2019-10-07 21:42:28,golang/go,https://api.github.com/repos/golang/go,closed,x/build/devapp: broken link on `reviews` page,Builders NeedsFix,"https://dev.golang.org/reviews includes an entry linking to https://go-review.googlesource.com/93515. The latter link is currently a 404. Perhaps we need to filter out deleted CLs? CC @andybons ",1.0,"x/build/devapp: broken link on `reviews` page - https://dev.golang.org/reviews includes an entry linking to https://go-review.googlesource.com/93515. The latter link is currently a 404. Perhaps we need to filter out deleted CLs? CC @andybons ",0,x build devapp broken link on reviews page includes an entry linking to the latter link is currently a perhaps we need to filter out deleted cls cc andybons ,0 294546,25380600880.0,IssuesEvent,2022-11-21 17:13:42,golang/go,https://api.github.com/repos/golang/go,reopened,x/tools/playground/socket: TestLimiter failures due to arbitrary timeout,Testing NeedsFix Tools,"``` #!watchflakes post <- builder ~ pkg == ""golang.org/x/tools/playground/socket"" && test == ""TestLimiter"" ``` Bug automatically created to track these flakes. — watchflakes ",1.0,"x/tools/playground/socket: TestLimiter failures due to arbitrary timeout - ``` #!watchflakes post <- builder ~ pkg == ""golang.org/x/tools/playground/socket"" && test == ""TestLimiter"" ``` Bug automatically created to track these flakes. — watchflakes ",0,x tools playground socket testlimiter failures due to arbitrary timeout watchflakes post builder pkg golang org x tools playground socket test testlimiter bug automatically created to track these flakes — watchflakes ,0 297486,22359543598.0,IssuesEvent,2022-06-15 18:59:55,golang/go,https://api.github.com/repos/golang/go,closed,"doc: cmd/go: document use with modules ""from the ground up""",Documentation help wanted modules," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.3 darwin/amd64
### Does this issue reproduce with the latest release? NA ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
NA
### What did you do? I am a go newbie trying to set up several folders with go code in a monorepo (which also contains code built in other languages). Some of these folders will contain services, others library utilities. ### What did you expect to see? I would like documentation based on the new ""module"" paradigm that explain: * module * package * file * folder and their relationship to each other ""from the ground up"" (without assuming knowledge of how things used to work). In particular, in a monorepo, * should there be an overall ""go.mod"", or one in each folder (or both??) * if there is only one ""go.mod"" how do I specify different dependencies for each folder? If not, is there a way to specify common dependencies to force version synchronization (or if there isn't doc should flag as gotcha). * how do I refer to code in one folder from another? ### What did you see instead? The tutorials don't cover modules. The official doc for modules are geared to explain what is different for experienced go users. There seems to be no good documentation anywhere on use of modules in monorepos. ",1.0,"doc: cmd/go: document use with modules ""from the ground up"" - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.3 darwin/amd64
### Does this issue reproduce with the latest release? NA ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
NA
### What did you do? I am a go newbie trying to set up several folders with go code in a monorepo (which also contains code built in other languages). Some of these folders will contain services, others library utilities. ### What did you expect to see? I would like documentation based on the new ""module"" paradigm that explain: * module * package * file * folder and their relationship to each other ""from the ground up"" (without assuming knowledge of how things used to work). In particular, in a monorepo, * should there be an overall ""go.mod"", or one in each folder (or both??) * if there is only one ""go.mod"" how do I specify different dependencies for each folder? If not, is there a way to specify common dependencies to force version synchronization (or if there isn't doc should flag as gotcha). * how do I refer to code in one folder from another? ### What did you see instead? The tutorials don't cover modules. The official doc for modules are geared to explain what is different for experienced go users. There seems to be no good documentation anywhere on use of modules in monorepos. ",1,doc cmd go document use with modules from the ground up what version of go are you using go version go version go version darwin does this issue reproduce with the latest release na what operating system and processor architecture are you using go env go env output go env na 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 i am a go newbie trying to set up several folders with go code in a monorepo which also contains code built in other languages some of these folders will contain services others library utilities what did you expect to see i would like documentation based on the new module paradigm that explain module package file folder and their relationship to each other from the ground up without assuming knowledge of how things used to work in particular in a monorepo should there be an overall go mod or one in each folder or both if there is only one go mod how do i specify different dependencies for each folder if not is there a way to specify common dependencies to force version synchronization or if there isn t doc should flag as gotcha how do i refer to code in one folder from another what did you see instead the tutorials don t cover modules the official doc for modules are geared to explain what is different for experienced go users there seems to be no good documentation anywhere on use of modules in monorepos ,1 50504,7607055011.0,IssuesEvent,2018-04-30 15:16:18,golang/go,https://api.github.com/repos/golang/go,closed,"doc: ""Go's New Brand"" / Brand Book (pdf)",Documentation,"Most probably it's a non-issue, though changing to Go proportionally-spaced font from Go monospaced on p19 in the Brand Book (pdf) might make the Brand Book more branded. https://golang.org/s/brandbook ### What did you do? Had a look at the pdf. ### What did you expect to see? When I saw the Go font mentioned, I expected the text in proportionally-spaced font. ### What did you see instead? Text in monospaced font. ",1.0,"doc: ""Go's New Brand"" / Brand Book (pdf) - Most probably it's a non-issue, though changing to Go proportionally-spaced font from Go monospaced on p19 in the Brand Book (pdf) might make the Brand Book more branded. https://golang.org/s/brandbook ### What did you do? Had a look at the pdf. ### What did you expect to see? When I saw the Go font mentioned, I expected the text in proportionally-spaced font. ### What did you see instead? Text in monospaced font. ",1,doc go s new brand brand book pdf most probably it s a non issue though changing to go proportionally spaced font from go monospaced on in the brand book pdf might make the brand book more branded what did you do had a look at the pdf what did you expect to see when i saw the go font mentioned i expected the text in proportionally spaced font what did you see instead text in monospaced font ,1 18289,4243508895.0,IssuesEvent,2016-07-06 23:23:33,golang/go,https://api.github.com/repos/golang/go,closed,"path/filepath: behavior of Clean is not explicitly mentioned in its doc, which is surprising and easy to miss",Documentation,"_(Usually an issue is when a function does something which is not documented, or different than documented. This is not the case here, but I still believe there is an issue that can and should be resolved, i.e., improvement is possible.)_ One of my favorite properties of Go is that many things are explicit and there's little magic. When you want to learn what a func in standard library does, often just reading its doc string will tell you everything you need to know, without having to look at the implementation details. This is very nice and follows Principle of Least Surprise. I was trying to confirm the behavior of `filepath.Join`, so I began by reading its doc: ``` // Join joins any number of path elements into a single path, adding // a Separator if necessary. The result is Cleaned, in particular // all empty strings are ignored. // On Windows, the result is a UNC path if and only if the first path // element is a UNC path. func Join(elem ...string) string ``` It says that the result is Cleaned, so I read the doc for `Clean`: ``` // Clean returns the shortest path name equivalent to path // by purely lexical processing. It applies the following rules // iteratively until no further processing can be done: // // 1. Replace multiple Separator elements with a single one. // 2. Eliminate each . path name element (the current directory). // 3. Eliminate each inner .. path name element (the parent directory) // along with the non-.. element that precedes it. // 4. Eliminate .. elements that begin a rooted path: // that is, replace ""/.."" by ""/"" at the beginning of a path, // assuming Separator is '/'. // // The returned path ends in a slash only if it represents a root directory, // such as ""/"" on Unix or `C:\` on Windows. // // If the result of this process is an empty string, Clean // returns the string ""."". // // See also Rob Pike, ``Lexical File Names in Plan 9 or // Getting Dot-Dot Right,'' // http://plan9.bell-labs.com/sys/doc/lexnames.html func Clean(path string) string ``` With that, I am confident that I understand the behavior of `filepath.Join` because I've read its documentation. However, as I have learned today (by chance), my understanding of `filepath.Join`, `filepath.Clean` was incorrect because I overlooked a **very important, behavior altering** paragraph in the package documentation (which is used to describe this package). Read the second paragraph: ``` // Package filepath implements utility routines for manipulating filename paths // in a way compatible with the target operating system-defined file paths. // // Functions in this package replace any occurrences of the slash ('/') character // with os.PathSeparator when returning paths unless otherwise specified. package filepath ``` It turns out that `Clean` replaces any occurrences of the slash ('/') character with `os.PathSeparator` when returning path. So does `Join` since it calls `Clean`. I believe this is the first time I have ever encountered a standard library package where a part of the behavior (which is not the expected behavior for this package) is specified/overridden by package docs. If I'm not mistaken, I believe it'd be better to change documentation to document `Clean`s behavior explicitly, and change the package documentation to summarize behavior rather than be the only place that specifies it. ### Exaggerated, contrived example If I may provide an exaggerated, contrived example of how this current situation makes me feel, it would be like seeing a function in std lib like this: ```Go // Add returns sum of two numbers. func Add(a, b int) int ``` Then I run `Add(1, 2)` and get -3 instead of 3. Instead of a bug, imagine it turns out that: ```Go // Package math has some utilities for dealing with numbers. // // Functions in this package return the negation of the expected result, unless // otherwise specified. package math ``` This issue is the same as https://github.com/golang/go/issues/10122. However, that issue was resolved a year ago, and I hadn't noticed that it was resolved because I primarily read the function documentation when determining behavior of a function. I read the package documentation when I want to get a better overview of the purpose of package, but it's not where I expect to find unexpected behaviors specified. ### Proposed improvement I propose improving `path/filepath` by changing `Clean` documentation to be explicit about its behavior, and changing the package summary to be more descriptive of the package, rather than being the canonical place where behavior of individual functions is altered or specified. E.g., something like this: ![image](https://cloud.githubusercontent.com/assets/1924134/16174123/88bc2c02-356a-11e6-83f4-369710843395.png) /cc @hyangah since you originally ran into this issue as well (#10122), and worked on the original fix to the doc.",1.0,"path/filepath: behavior of Clean is not explicitly mentioned in its doc, which is surprising and easy to miss - _(Usually an issue is when a function does something which is not documented, or different than documented. This is not the case here, but I still believe there is an issue that can and should be resolved, i.e., improvement is possible.)_ One of my favorite properties of Go is that many things are explicit and there's little magic. When you want to learn what a func in standard library does, often just reading its doc string will tell you everything you need to know, without having to look at the implementation details. This is very nice and follows Principle of Least Surprise. I was trying to confirm the behavior of `filepath.Join`, so I began by reading its doc: ``` // Join joins any number of path elements into a single path, adding // a Separator if necessary. The result is Cleaned, in particular // all empty strings are ignored. // On Windows, the result is a UNC path if and only if the first path // element is a UNC path. func Join(elem ...string) string ``` It says that the result is Cleaned, so I read the doc for `Clean`: ``` // Clean returns the shortest path name equivalent to path // by purely lexical processing. It applies the following rules // iteratively until no further processing can be done: // // 1. Replace multiple Separator elements with a single one. // 2. Eliminate each . path name element (the current directory). // 3. Eliminate each inner .. path name element (the parent directory) // along with the non-.. element that precedes it. // 4. Eliminate .. elements that begin a rooted path: // that is, replace ""/.."" by ""/"" at the beginning of a path, // assuming Separator is '/'. // // The returned path ends in a slash only if it represents a root directory, // such as ""/"" on Unix or `C:\` on Windows. // // If the result of this process is an empty string, Clean // returns the string ""."". // // See also Rob Pike, ``Lexical File Names in Plan 9 or // Getting Dot-Dot Right,'' // http://plan9.bell-labs.com/sys/doc/lexnames.html func Clean(path string) string ``` With that, I am confident that I understand the behavior of `filepath.Join` because I've read its documentation. However, as I have learned today (by chance), my understanding of `filepath.Join`, `filepath.Clean` was incorrect because I overlooked a **very important, behavior altering** paragraph in the package documentation (which is used to describe this package). Read the second paragraph: ``` // Package filepath implements utility routines for manipulating filename paths // in a way compatible with the target operating system-defined file paths. // // Functions in this package replace any occurrences of the slash ('/') character // with os.PathSeparator when returning paths unless otherwise specified. package filepath ``` It turns out that `Clean` replaces any occurrences of the slash ('/') character with `os.PathSeparator` when returning path. So does `Join` since it calls `Clean`. I believe this is the first time I have ever encountered a standard library package where a part of the behavior (which is not the expected behavior for this package) is specified/overridden by package docs. If I'm not mistaken, I believe it'd be better to change documentation to document `Clean`s behavior explicitly, and change the package documentation to summarize behavior rather than be the only place that specifies it. ### Exaggerated, contrived example If I may provide an exaggerated, contrived example of how this current situation makes me feel, it would be like seeing a function in std lib like this: ```Go // Add returns sum of two numbers. func Add(a, b int) int ``` Then I run `Add(1, 2)` and get -3 instead of 3. Instead of a bug, imagine it turns out that: ```Go // Package math has some utilities for dealing with numbers. // // Functions in this package return the negation of the expected result, unless // otherwise specified. package math ``` This issue is the same as https://github.com/golang/go/issues/10122. However, that issue was resolved a year ago, and I hadn't noticed that it was resolved because I primarily read the function documentation when determining behavior of a function. I read the package documentation when I want to get a better overview of the purpose of package, but it's not where I expect to find unexpected behaviors specified. ### Proposed improvement I propose improving `path/filepath` by changing `Clean` documentation to be explicit about its behavior, and changing the package summary to be more descriptive of the package, rather than being the canonical place where behavior of individual functions is altered or specified. E.g., something like this: ![image](https://cloud.githubusercontent.com/assets/1924134/16174123/88bc2c02-356a-11e6-83f4-369710843395.png) /cc @hyangah since you originally ran into this issue as well (#10122), and worked on the original fix to the doc.",1,path filepath behavior of clean is not explicitly mentioned in its doc which is surprising and easy to miss usually an issue is when a function does something which is not documented or different than documented this is not the case here but i still believe there is an issue that can and should be resolved i e improvement is possible one of my favorite properties of go is that many things are explicit and there s little magic when you want to learn what a func in standard library does often just reading its doc string will tell you everything you need to know without having to look at the implementation details this is very nice and follows principle of least surprise i was trying to confirm the behavior of filepath join so i began by reading its doc join joins any number of path elements into a single path adding a separator if necessary the result is cleaned in particular all empty strings are ignored on windows the result is a unc path if and only if the first path element is a unc path func join elem string string it says that the result is cleaned so i read the doc for clean clean returns the shortest path name equivalent to path by purely lexical processing it applies the following rules iteratively until no further processing can be done replace multiple separator elements with a single one eliminate each path name element the current directory eliminate each inner path name element the parent directory along with the non element that precedes it eliminate elements that begin a rooted path that is replace by at the beginning of a path assuming separator is the returned path ends in a slash only if it represents a root directory such as on unix or c on windows if the result of this process is an empty string clean returns the string see also rob pike lexical file names in plan or getting dot dot right func clean path string string with that i am confident that i understand the behavior of filepath join because i ve read its documentation however as i have learned today by chance my understanding of filepath join filepath clean was incorrect because i overlooked a very important behavior altering paragraph in the package documentation which is used to describe this package read the second paragraph package filepath implements utility routines for manipulating filename paths in a way compatible with the target operating system defined file paths functions in this package replace any occurrences of the slash character with os pathseparator when returning paths unless otherwise specified package filepath it turns out that clean replaces any occurrences of the slash character with os pathseparator when returning path so does join since it calls clean i believe this is the first time i have ever encountered a standard library package where a part of the behavior which is not the expected behavior for this package is specified overridden by package docs if i m not mistaken i believe it d be better to change documentation to document clean s behavior explicitly and change the package documentation to summarize behavior rather than be the only place that specifies it exaggerated contrived example if i may provide an exaggerated contrived example of how this current situation makes me feel it would be like seeing a function in std lib like this go add returns sum of two numbers func add a b int int then i run add and get instead of instead of a bug imagine it turns out that go package math has some utilities for dealing with numbers functions in this package return the negation of the expected result unless otherwise specified package math this issue is the same as however that issue was resolved a year ago and i hadn t noticed that it was resolved because i primarily read the function documentation when determining behavior of a function i read the package documentation when i want to get a better overview of the purpose of package but it s not where i expect to find unexpected behaviors specified proposed improvement i propose improving path filepath by changing clean documentation to be explicit about its behavior and changing the package summary to be more descriptive of the package rather than being the canonical place where behavior of individual functions is altered or specified e g something like this cc hyangah since you originally ran into this issue as well and worked on the original fix to the doc ,1 351207,25017835309.0,IssuesEvent,2022-11-03 20:33:20,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: design/document new release policy,Documentation gopls Tools,"### Background Historically, we've endeavored to do a new gopls release ~monthly, in order to stay up-to-date with dependencies and minimize delta. Typically we'd cut a new minor version (e.g. gopls@v0.9.0) whenever there is a significant improvement that we'd like to highlight. At this point we'd create a new release branch (e.g. gopls-release-branch.0.9), and subsequently merge from master to the release branch whenever we cut patch releases (e.g. gopls@v0.9.1). ### Problems There are some problems with this model that we'd like to solve: 1. **Releasing is tedious**. Releasing involves multiple CLs, smoke testing, writing release notes, etc. We are working on integrating with the release team's new [Relui](https://github.com/golang/build/tree/master/cmd/relui) automation, which should make the _process_ of releasing easier, but it doesn't eliminate the need for manual verification of releases, writing release notes, or promoting the prerelease. 2. **Releasing is risky**. For example, see #54459. While we continue to invest in testing and benchmarking, it is unfortunately true that a. gopls has significant technical debt that we're still paying down b. gopls interacts heavily with the operating system, and so is subject to differing behavior across platforms ([example](https://go.dev/issue/54007)) c. gopls interacts with dozens of different editors and LSP clients, many of which have subtly different behavior ([example](https://go.dev/issue/54559)) d. gopls has no telemetry, and user reports are sparse and sporadic 3. **Historically, releases haven't followed the spirit of semver**. While we try to associate minor versions with ""significant"" changes, we have introduced new features in patch versions. Because we have been merging from master, there is also no reason to expect that patch releases are incrementally more stable: we introduced breakages such as #54459 in patch releases. ### Proposed Change I propose to address these problems by adopting a release policy more similar to that of the main Go distribution (albeit every 3 months rather than 6): - **Only merge from master for `*.*.0` patch releases**. Instead of merging for each patch release, only merge when we initially cut our minor version release branches, corresponding to the `*.*.0` patch release. Subsequent patch releases will contain only cherry-picked CLs, ideally only bug fixes. - **Target minor releases every ~3 months**. Try to stick to a schedule of releasing new minor versions every 3 months. This will allow a regular pace of new features, and allow us to coordinate with the Go release, but will reduce churn. - **Let new minor versions soak in prerelease for longer**. In the past, we've let prereleases soak for a few days, longer if we think they are risky. With this new policy, I think new minor versions should soak in prerelease for at least two weeks. - **Heavily promote minor version prereleases**. Recently we've tried promoting risky prereleases on gophers Slack, with moderate success. We can do more: a devlog, twitter post, or nightly channel for the main vscode-go extension. We can also encourage non-vscode LSP clients to have a nightly channel. - **Fully automate patch releases**. If subsequent patch releases consist only of a small number of bug fixes, it should be possible to fully automate them in Relui, including their release notes and publication. - **Target patch releases every ~month**. Since patch releases should be easy, releasing every month should no longer introduce significant toil. - **Document this policy**, for reference and to set expectations. CC @golang/tools-team ",1.0,"x/tools/gopls: design/document new release policy - ### Background Historically, we've endeavored to do a new gopls release ~monthly, in order to stay up-to-date with dependencies and minimize delta. Typically we'd cut a new minor version (e.g. gopls@v0.9.0) whenever there is a significant improvement that we'd like to highlight. At this point we'd create a new release branch (e.g. gopls-release-branch.0.9), and subsequently merge from master to the release branch whenever we cut patch releases (e.g. gopls@v0.9.1). ### Problems There are some problems with this model that we'd like to solve: 1. **Releasing is tedious**. Releasing involves multiple CLs, smoke testing, writing release notes, etc. We are working on integrating with the release team's new [Relui](https://github.com/golang/build/tree/master/cmd/relui) automation, which should make the _process_ of releasing easier, but it doesn't eliminate the need for manual verification of releases, writing release notes, or promoting the prerelease. 2. **Releasing is risky**. For example, see #54459. While we continue to invest in testing and benchmarking, it is unfortunately true that a. gopls has significant technical debt that we're still paying down b. gopls interacts heavily with the operating system, and so is subject to differing behavior across platforms ([example](https://go.dev/issue/54007)) c. gopls interacts with dozens of different editors and LSP clients, many of which have subtly different behavior ([example](https://go.dev/issue/54559)) d. gopls has no telemetry, and user reports are sparse and sporadic 3. **Historically, releases haven't followed the spirit of semver**. While we try to associate minor versions with ""significant"" changes, we have introduced new features in patch versions. Because we have been merging from master, there is also no reason to expect that patch releases are incrementally more stable: we introduced breakages such as #54459 in patch releases. ### Proposed Change I propose to address these problems by adopting a release policy more similar to that of the main Go distribution (albeit every 3 months rather than 6): - **Only merge from master for `*.*.0` patch releases**. Instead of merging for each patch release, only merge when we initially cut our minor version release branches, corresponding to the `*.*.0` patch release. Subsequent patch releases will contain only cherry-picked CLs, ideally only bug fixes. - **Target minor releases every ~3 months**. Try to stick to a schedule of releasing new minor versions every 3 months. This will allow a regular pace of new features, and allow us to coordinate with the Go release, but will reduce churn. - **Let new minor versions soak in prerelease for longer**. In the past, we've let prereleases soak for a few days, longer if we think they are risky. With this new policy, I think new minor versions should soak in prerelease for at least two weeks. - **Heavily promote minor version prereleases**. Recently we've tried promoting risky prereleases on gophers Slack, with moderate success. We can do more: a devlog, twitter post, or nightly channel for the main vscode-go extension. We can also encourage non-vscode LSP clients to have a nightly channel. - **Fully automate patch releases**. If subsequent patch releases consist only of a small number of bug fixes, it should be possible to fully automate them in Relui, including their release notes and publication. - **Target patch releases every ~month**. Since patch releases should be easy, releasing every month should no longer introduce significant toil. - **Document this policy**, for reference and to set expectations. CC @golang/tools-team ",1,x tools gopls design document new release policy background historically we ve endeavored to do a new gopls release monthly in order to stay up to date with dependencies and minimize delta typically we d cut a new minor version e g gopls whenever there is a significant improvement that we d like to highlight at this point we d create a new release branch e g gopls release branch and subsequently merge from master to the release branch whenever we cut patch releases e g gopls problems there are some problems with this model that we d like to solve releasing is tedious releasing involves multiple cls smoke testing writing release notes etc we are working on integrating with the release team s new automation which should make the process of releasing easier but it doesn t eliminate the need for manual verification of releases writing release notes or promoting the prerelease releasing is risky for example see while we continue to invest in testing and benchmarking it is unfortunately true that a gopls has significant technical debt that we re still paying down b gopls interacts heavily with the operating system and so is subject to differing behavior across platforms c gopls interacts with dozens of different editors and lsp clients many of which have subtly different behavior d gopls has no telemetry and user reports are sparse and sporadic historically releases haven t followed the spirit of semver while we try to associate minor versions with significant changes we have introduced new features in patch versions because we have been merging from master there is also no reason to expect that patch releases are incrementally more stable we introduced breakages such as in patch releases proposed change i propose to address these problems by adopting a release policy more similar to that of the main go distribution albeit every months rather than only merge from master for patch releases instead of merging for each patch release only merge when we initially cut our minor version release branches corresponding to the patch release subsequent patch releases will contain only cherry picked cls ideally only bug fixes target minor releases every months try to stick to a schedule of releasing new minor versions every months this will allow a regular pace of new features and allow us to coordinate with the go release but will reduce churn let new minor versions soak in prerelease for longer in the past we ve let prereleases soak for a few days longer if we think they are risky with this new policy i think new minor versions should soak in prerelease for at least two weeks heavily promote minor version prereleases recently we ve tried promoting risky prereleases on gophers slack with moderate success we can do more a devlog twitter post or nightly channel for the main vscode go extension we can also encourage non vscode lsp clients to have a nightly channel fully automate patch releases if subsequent patch releases consist only of a small number of bug fixes it should be possible to fully automate them in relui including their release notes and publication target patch releases every month since patch releases should be easy releasing every month should no longer introduce significant toil document this policy for reference and to set expectations cc golang tools team ,1 173136,14403476356.0,IssuesEvent,2020-12-03 16:06:11,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document net/smtp changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/smtp

TODO: https://golang.org/cl/247257: adds support for the SMTPUTF8 extension

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document net/smtp changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/smtp

TODO: https://golang.org/cl/247257: adds support for the SMTPUTF8 extension

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document net smtp changes for go as of filing this issue the contained the following html net smtp todo a href adds support for the extension per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 11005,3452288861.0,IssuesEvent,2015-12-17 02:52:57,golang/go,https://api.github.com/repos/golang/go,opened,archive/tar: mention changes in go1.6 docs,Documentation,"http://tip.golang.org/doc/go1.6 does not mention archive/tar at all, but tons of work went into in this cycle. @dsnet, can you help summarize the notable parts?",1.0,"archive/tar: mention changes in go1.6 docs - http://tip.golang.org/doc/go1.6 does not mention archive/tar at all, but tons of work went into in this cycle. @dsnet, can you help summarize the notable parts?",1,archive tar mention changes in docs does not mention archive tar at all but tons of work went into in this cycle dsnet can you help summarize the notable parts ,1 36547,6539270835.0,IssuesEvent,2017-09-01 10:22:56,golang/go,https://api.github.com/repos/golang/go,closed,strconv: incorrect rounding to nearest even,Documentation NeedsDecision,"The following statements ``` fmt.Printf(""x = %.1f\n"", 0.35) fmt.Printf(""x = %.1f\n"", 0.45) fmt.Printf(""x = %.1f\n"", 0.55) fmt.Printf(""x = %.1f\n"", 0.65) ``` produce ``` x = 0.3 x = 0.5 x = 0.6 x = 0.7 ``` (https://play.golang.org/p/kLC7Ap0cpP). However, assuming rounding to nearest even, one would expect the result to be ``` x = 0.4 x = 0.4 x = 0.6 x = 0.6 ``` (The examples use fmt.Printf but the culprit is in the underlying strconv code. The documentation doesn't explicitly state that it rounds to nearest even, but that is definitively the intent of the implementation which contains code and comments to that effect.). The problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision, what should be `.5` is sometimes below or above that value. That said, the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number, that is if rounding where done on the output of using the ""%g"" format (or `strconv.FormatFloat` with precision -1). Unfortunately, computing that representation is much more expensive than what happens now. We can probably not fix this. For one, it's been like this forever. Also, a corresponding C program ``` #include int main() { printf(""x = %.1f\n"", 0.35); printf(""x = %.1f\n"", 0.45); printf(""x = %.1f\n"", 0.55); printf(""x = %.1f\n"", 0.65); return 0; } ``` produces the same (incorrect) result. And so does `math/big.Float` formatting with the same arguments (since the code mirrors the strconv code). But we should probably document it and perhaps even provide a ""correct"" routine for cases where this truly matters. ",1.0,"strconv: incorrect rounding to nearest even - The following statements ``` fmt.Printf(""x = %.1f\n"", 0.35) fmt.Printf(""x = %.1f\n"", 0.45) fmt.Printf(""x = %.1f\n"", 0.55) fmt.Printf(""x = %.1f\n"", 0.65) ``` produce ``` x = 0.3 x = 0.5 x = 0.6 x = 0.7 ``` (https://play.golang.org/p/kLC7Ap0cpP). However, assuming rounding to nearest even, one would expect the result to be ``` x = 0.4 x = 0.4 x = 0.6 x = 0.6 ``` (The examples use fmt.Printf but the culprit is in the underlying strconv code. The documentation doesn't explicitly state that it rounds to nearest even, but that is definitively the intent of the implementation which contains code and comments to that effect.). The problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision, what should be `.5` is sometimes below or above that value. That said, the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number, that is if rounding where done on the output of using the ""%g"" format (or `strconv.FormatFloat` with precision -1). Unfortunately, computing that representation is much more expensive than what happens now. We can probably not fix this. For one, it's been like this forever. Also, a corresponding C program ``` #include int main() { printf(""x = %.1f\n"", 0.35); printf(""x = %.1f\n"", 0.45); printf(""x = %.1f\n"", 0.55); printf(""x = %.1f\n"", 0.65); return 0; } ``` produces the same (incorrect) result. And so does `math/big.Float` formatting with the same arguments (since the code mirrors the strconv code). But we should probably document it and perhaps even provide a ""correct"" routine for cases where this truly matters. ",1,strconv incorrect rounding to nearest even the following statements fmt printf x n fmt printf x n fmt printf x n fmt printf x n produce x x x x however assuming rounding to nearest even one would expect the result to be x x x x the examples use fmt printf but the culprit is in the underlying strconv code the documentation doesn t explicitly state that it rounds to nearest even but that is definitively the intent of the implementation which contains code and comments to that effect the problem of course is that these numbers cannot be accurately represented in binary form and when it comes to the rounding decision what should be is sometimes below or above that value that said the correct result could in fact be obtained if rounding were done on the shortest decimal representation that produces the incoming number that is if rounding where done on the output of using the g format or strconv formatfloat with precision unfortunately computing that representation is much more expensive than what happens now we can probably not fix this for one it s been like this forever also a corresponding c program include int main printf x n printf x n printf x n printf x n return produces the same incorrect result and so does math big float formatting with the same arguments since the code mirrors the strconv code but we should probably document it and perhaps even provide a correct routine for cases where this truly matters ,1 52037,7744100769.0,IssuesEvent,2018-05-29 14:34:26,golang/go,https://api.github.com/repos/golang/go,closed,Doc: State that Request.ParseForm() does not parse JSON payloads,Documentation,"### What did you expect to see? I spent a good deal of time trying to determine why my XHR-style ""forms"" (actually JSON) were coming in blank. ### What did you see instead? After much debugging, head-desking, and searching, I discovered that this doesn't work that way. I've learned, but other people who have used other server frameworks may make the same mistake I did. In fact, I discovered it on Stack Overflow through someone else having the same problem. I realize that a change to `ParseForm` would need to go through the language change proposal process. Obviously, nothing needs to be added to the language to be able to parse JSON payloads. However, I believe that a short note in [this comment](https://github.com/golang/go/blob/master/src/net/http/request.go#L1143) would help people understand that they'll need to parse JSON bodies themselves. I'd be happy to update the comment to that effect, but before I go through that effort, I wanted to ask the team if that sort of thing would be welcome. So - let me know. :) (and thank you for your time) ",1.0,"Doc: State that Request.ParseForm() does not parse JSON payloads - ### What did you expect to see? I spent a good deal of time trying to determine why my XHR-style ""forms"" (actually JSON) were coming in blank. ### What did you see instead? After much debugging, head-desking, and searching, I discovered that this doesn't work that way. I've learned, but other people who have used other server frameworks may make the same mistake I did. In fact, I discovered it on Stack Overflow through someone else having the same problem. I realize that a change to `ParseForm` would need to go through the language change proposal process. Obviously, nothing needs to be added to the language to be able to parse JSON payloads. However, I believe that a short note in [this comment](https://github.com/golang/go/blob/master/src/net/http/request.go#L1143) would help people understand that they'll need to parse JSON bodies themselves. I'd be happy to update the comment to that effect, but before I go through that effort, I wanted to ask the team if that sort of thing would be welcome. So - let me know. :) (and thank you for your time) ",1,doc state that request parseform does not parse json payloads what did you expect to see i spent a good deal of time trying to determine why my xhr style forms actually json were coming in blank what did you see instead after much debugging head desking and searching i discovered that this doesn t work that way i ve learned but other people who have used other server frameworks may make the same mistake i did in fact i discovered it on stack overflow through someone else having the same problem i realize that a change to parseform would need to go through the language change proposal process obviously nothing needs to be added to the language to be able to parse json payloads however i believe that a short note in would help people understand that they ll need to parse json bodies themselves i d be happy to update the comment to that effect but before i go through that effort i wanted to ask the team if that sort of thing would be welcome so let me know and thank you for your time ,1 314393,23519444721.0,IssuesEvent,2022-08-19 03:09:35,golang/go,https://api.github.com/repos/golang/go,closed,x/sync/errgroup: clarify that Go calls the function regardless of prior errors,Documentation help wanted NeedsFix,"### What version of Go are you using (`go version`)? ``` go version go1.19-pre4 cl/455575533 +12f49fe0ed linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes ### What did you do? ``` package test import ( ""errors"" ""sync/atomic"" ""testing"" ""time"" ""golang.org/x/sync/errgroup"" ) func TestErrGroupDoesNotRunNewFunctionsAfterPreviousError(t *testing.T) { group := errgroup.Group{} group.SetLimit(1) group.Go(func() error { return errors.New("""") }) time.Sleep(time.Second) var ran atomic.Bool group.Go(func() error { ran.Store(true) return nil }) _ = group.Wait() if ran.Load() { t.Errorf(""Expected second func not to run, but it did"") } } ``` ### What did you expect to see? The [documentation for errgroup](https://pkg.go.dev/golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f/errgroup#Group.Go) states: > Go calls the given function in a new goroutine. It blocks until the new goroutine can be added without the number of active goroutines in the group exceeding the configured limit. > > The first call to return a non-nil error cancels the group; its error will be returned by Wait. I would assume that if the first call to return a non-nil error cancels the group, future funcs passed to go won't run. Furthermore calls to `group.Wait()` should return immediately rather than waiting for funcs created after the group was cancelled to complete. ### What did you see instead? All funcs are called, even those created after the group was cancelled. `group.Wait()` waits for all funcs to complete before returning. ",1.0,"x/sync/errgroup: clarify that Go calls the function regardless of prior errors - ### What version of Go are you using (`go version`)? ``` go version go1.19-pre4 cl/455575533 +12f49fe0ed linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes ### What did you do? ``` package test import ( ""errors"" ""sync/atomic"" ""testing"" ""time"" ""golang.org/x/sync/errgroup"" ) func TestErrGroupDoesNotRunNewFunctionsAfterPreviousError(t *testing.T) { group := errgroup.Group{} group.SetLimit(1) group.Go(func() error { return errors.New("""") }) time.Sleep(time.Second) var ran atomic.Bool group.Go(func() error { ran.Store(true) return nil }) _ = group.Wait() if ran.Load() { t.Errorf(""Expected second func not to run, but it did"") } } ``` ### What did you expect to see? The [documentation for errgroup](https://pkg.go.dev/golang.org/x/sync@v0.0.0-20220601150217-0de741cfad7f/errgroup#Group.Go) states: > Go calls the given function in a new goroutine. It blocks until the new goroutine can be added without the number of active goroutines in the group exceeding the configured limit. > > The first call to return a non-nil error cancels the group; its error will be returned by Wait. I would assume that if the first call to return a non-nil error cancels the group, future funcs passed to go won't run. Furthermore calls to `group.Wait()` should return immediately rather than waiting for funcs created after the group was cancelled to complete. ### What did you see instead? All funcs are called, even those created after the group was cancelled. `group.Wait()` waits for all funcs to complete before returning. ",1,x sync errgroup clarify that go calls the function regardless of prior errors what version of go are you using go version go version cl linux does this issue reproduce with the latest release yes what did you do package test import errors sync atomic testing time golang org x sync errgroup func testerrgroupdoesnotrunnewfunctionsafterpreviouserror t testing t group errgroup group group setlimit group go func error return errors new time sleep time second var ran atomic bool group go func error ran store true return nil group wait if ran load t errorf expected second func not to run but it did what did you expect to see the states go calls the given function in a new goroutine it blocks until the new goroutine can be added without the number of active goroutines in the group exceeding the configured limit the first call to return a non nil error cancels the group its error will be returned by wait i would assume that if the first call to return a non nil error cancels the group future funcs passed to go won t run furthermore calls to group wait should return immediately rather than waiting for funcs created after the group was cancelled to complete what did you see instead all funcs are called even those created after the group was cancelled group wait waits for all funcs to complete before returning ,1 21593,4727235728.0,IssuesEvent,2016-10-18 12:56:51,golang/go,https://api.github.com/repos/golang/go,closed,testing: Document interaction of Skip and Error,Documentation NeedsFix,"```sh go version go1.7rc3 linux/amd64 ``` ```go package todo_test import ""testing"" func TestIssueFixed(t *testing.T) { defer func() { if t.Failed() { t.Skip(""Test failed as expected; see issue XXXXXXXX."") } t.Fatal(""Test did not fail as expected; please update issue XXXXXXXX."") }() t.Log("""") } func TestIssueOpen(t *testing.T) { defer func() { if t.Failed() { t.Skip(""Test failed as expected; see issue XXXXXXXX."") } t.Fatal(""Test did not fail as expected; please update issue XXXXXXXX."") }() t.Error("""") } ``` Expected: ``` $ go test -v todo === RUN TestIssueFixed --- FAIL: TestIssueFixed (0.00s) todo_test.go:13: todo_test.go:10: Test did not fail as expected; please update issue XXXXXXXX. === RUN TestIssueOpen --- SKIP: TestIssueOpen (0.00s) todo_test.go:24: todo_test.go:19: Test failed as expected; see issue XXXXXXXX. FAIL exit status 1 FAIL todo 0.018s ``` Actual: ``` $ go test -v todo === RUN TestIssueFixed --- FAIL: TestIssueFixed (0.00s) todo_test.go:13: todo_test.go:10: Test did not fail as expected; please update issue XXXXXXXX. === RUN TestIssueOpen --- FAIL: TestIssueOpen (0.00s) todo_test.go:24: todo_test.go:19: Test failed as expected; see issue XXXXXXXX. FAIL exit status 1 FAIL todo 0.031s ``` I'm guessing this is not actually a bug, but I don't see anything in https://golang.org/pkg/testing/ describing how Skip and Error are supposed to interact. It doesn't seem unreasonable to think that a test could be Skipped after it has already Failed, but that turns out not to be the case as implemented. Could someone with more in-depth knowledge of the testing package please confirm whether this behavior is intended (and, if so, update the documentation)?",1.0,"testing: Document interaction of Skip and Error - ```sh go version go1.7rc3 linux/amd64 ``` ```go package todo_test import ""testing"" func TestIssueFixed(t *testing.T) { defer func() { if t.Failed() { t.Skip(""Test failed as expected; see issue XXXXXXXX."") } t.Fatal(""Test did not fail as expected; please update issue XXXXXXXX."") }() t.Log("""") } func TestIssueOpen(t *testing.T) { defer func() { if t.Failed() { t.Skip(""Test failed as expected; see issue XXXXXXXX."") } t.Fatal(""Test did not fail as expected; please update issue XXXXXXXX."") }() t.Error("""") } ``` Expected: ``` $ go test -v todo === RUN TestIssueFixed --- FAIL: TestIssueFixed (0.00s) todo_test.go:13: todo_test.go:10: Test did not fail as expected; please update issue XXXXXXXX. === RUN TestIssueOpen --- SKIP: TestIssueOpen (0.00s) todo_test.go:24: todo_test.go:19: Test failed as expected; see issue XXXXXXXX. FAIL exit status 1 FAIL todo 0.018s ``` Actual: ``` $ go test -v todo === RUN TestIssueFixed --- FAIL: TestIssueFixed (0.00s) todo_test.go:13: todo_test.go:10: Test did not fail as expected; please update issue XXXXXXXX. === RUN TestIssueOpen --- FAIL: TestIssueOpen (0.00s) todo_test.go:24: todo_test.go:19: Test failed as expected; see issue XXXXXXXX. FAIL exit status 1 FAIL todo 0.031s ``` I'm guessing this is not actually a bug, but I don't see anything in https://golang.org/pkg/testing/ describing how Skip and Error are supposed to interact. It doesn't seem unreasonable to think that a test could be Skipped after it has already Failed, but that turns out not to be the case as implemented. Could someone with more in-depth knowledge of the testing package please confirm whether this behavior is intended (and, if so, update the documentation)?",1,testing document interaction of skip and error sh go version linux go package todo test import testing func testissuefixed t testing t defer func if t failed t skip test failed as expected see issue xxxxxxxx t fatal test did not fail as expected please update issue xxxxxxxx t log func testissueopen t testing t defer func if t failed t skip test failed as expected see issue xxxxxxxx t fatal test did not fail as expected please update issue xxxxxxxx t error expected go test v todo run testissuefixed fail testissuefixed todo test go todo test go test did not fail as expected please update issue xxxxxxxx run testissueopen skip testissueopen todo test go todo test go test failed as expected see issue xxxxxxxx fail exit status fail todo actual go test v todo run testissuefixed fail testissuefixed todo test go todo test go test did not fail as expected please update issue xxxxxxxx run testissueopen fail testissueopen todo test go todo test go test failed as expected see issue xxxxxxxx fail exit status fail todo i m guessing this is not actually a bug but i don t see anything in describing how skip and error are supposed to interact it doesn t seem unreasonable to think that a test could be skipped after it has already failed but that turns out not to be the case as implemented could someone with more in depth knowledge of the testing package please confirm whether this behavior is intended and if so update the documentation ,1 84028,10347658688.0,IssuesEvent,2019-09-04 17:55:35,golang/go,https://api.github.com/repos/golang/go,closed,doc: errors: wrong unwrap example [1.13 backport],CherryPickApproved Documentation,"@jba requested issue #34061 to be considered for backport to the next 1.13 minor release. > @gopherbot please backport 1.13 ",1.0,"doc: errors: wrong unwrap example [1.13 backport] - @jba requested issue #34061 to be considered for backport to the next 1.13 minor release. > @gopherbot please backport 1.13 ",1,doc errors wrong unwrap example jba requested issue to be considered for backport to the next minor release gopherbot please backport ,1 428102,29927642150.0,IssuesEvent,2023-06-22 07:10:16,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Random greeting tutorial docs outdated,Documentation website,"This commit: https://github.com/golang/website/commit/f734127 removes some code from the tutorial, but fails to remove the explanation for that code: https://github.com/golang/website/blob/cf517d8748f3d07b8a57fbee59d056c25b447bef/_content/doc/tutorial/random-greeting.html#L94-L100",1.0,"x/website: Random greeting tutorial docs outdated - This commit: https://github.com/golang/website/commit/f734127 removes some code from the tutorial, but fails to remove the explanation for that code: https://github.com/golang/website/blob/cf517d8748f3d07b8a57fbee59d056c25b447bef/_content/doc/tutorial/random-greeting.html#L94-L100",1,x website random greeting tutorial docs outdated this commit removes some code from the tutorial but fails to remove the explanation for that code ,1 45342,11641803374.0,IssuesEvent,2020-02-29 04:22:39,golang/go,https://api.github.com/repos/golang/go,closed,x/build: automatically start building subrepos for new release branches,Builders NeedsFix,"currently, a new release tag entity must be manually added to datastore before subrepos will be built and displayed on build.golang.org's index page. this should be automated. cc @rsc @broady ",1.0,"x/build: automatically start building subrepos for new release branches - currently, a new release tag entity must be manually added to datastore before subrepos will be built and displayed on build.golang.org's index page. this should be automated. cc @rsc @broady ",0,x build automatically start building subrepos for new release branches currently a new release tag entity must be manually added to datastore before subrepos will be built and displayed on build golang org s index page this should be automated cc rsc broady ,0 17136,6366410871.0,IssuesEvent,2017-08-01 01:23:33,golang/go,https://api.github.com/repos/golang/go,opened,x/build: use GCP container builder triggers for images?,Builders,"Work on converting docker images to GCP container builder and nested builds so we don't have to push and update them all the time. cc @adams-sarah @cybrcodr @bradfitz ",1.0,"x/build: use GCP container builder triggers for images? - Work on converting docker images to GCP container builder and nested builds so we don't have to push and update them all the time. cc @adams-sarah @cybrcodr @bradfitz ",0,x build use gcp container builder triggers for images work on converting docker images to gcp container builder and nested builds so we don t have to push and update them all the time cc adams sarah cybrcodr bradfitz ,0 137202,12747833315.0,IssuesEvent,2020-06-26 18:46:11,golang/go,https://api.github.com/repos/golang/go,closed,doc: BuildNameToCertificate deprecated in go 1.14 not mentioned in the release notes [1.14 backport],CherryPickApproved Documentation,"@FiloSottile requested issue #37626 to be considered for backport to the next 1.14 minor release. > @gopherbot please open a backport issue for Go 1.14, this is a documentation change that needs to go live on golang.org. ",1.0,"doc: BuildNameToCertificate deprecated in go 1.14 not mentioned in the release notes [1.14 backport] - @FiloSottile requested issue #37626 to be considered for backport to the next 1.14 minor release. > @gopherbot please open a backport issue for Go 1.14, this is a documentation change that needs to go live on golang.org. ",1,doc buildnametocertificate deprecated in go not mentioned in the release notes filosottile requested issue to be considered for backport to the next minor release gopherbot please open a backport issue for go this is a documentation change that needs to go live on golang org ,1 96063,10917950288.0,IssuesEvent,2019-11-21 16:01:38,golang/go,https://api.github.com/repos/golang/go,closed,net/url: comment of split function is wrong,Documentation NeedsFix,"### What did you expect to see? ``` // split slices s into two substrings separated by the first occurrence of // sep. If cutc is true then sep is excluded from the second substring. // If sep does not occur in s then s and the empty string is returned. func split(s string, sep byte, cutc bool) (string, string) { i := strings.IndexByte(s, sep) if i < 0 { return s, """" } if cutc { return s[:i], s[i+1:] } return s[:i], s[i:] } ``` ### What did you see instead? ``` // split slices s into two substrings separated by the first occurrence of // sep. If cutc is true then sep is included with the second substring. // If sep does not occur in s then s and the empty string is returned. func split(s string, sep byte, cutc bool) (string, string) { i := strings.IndexByte(s, sep) if i < 0 { return s, """" } if cutc { return s[:i], s[i+1:] } return s[:i], s[i:] } ``` https://github.com/golang/go/blob/39a9cb4b5dbf1e518b0c66fa3a7b4175f90226fc/src/net/url/url.go#L454-L466",1.0,"net/url: comment of split function is wrong - ### What did you expect to see? ``` // split slices s into two substrings separated by the first occurrence of // sep. If cutc is true then sep is excluded from the second substring. // If sep does not occur in s then s and the empty string is returned. func split(s string, sep byte, cutc bool) (string, string) { i := strings.IndexByte(s, sep) if i < 0 { return s, """" } if cutc { return s[:i], s[i+1:] } return s[:i], s[i:] } ``` ### What did you see instead? ``` // split slices s into two substrings separated by the first occurrence of // sep. If cutc is true then sep is included with the second substring. // If sep does not occur in s then s and the empty string is returned. func split(s string, sep byte, cutc bool) (string, string) { i := strings.IndexByte(s, sep) if i < 0 { return s, """" } if cutc { return s[:i], s[i+1:] } return s[:i], s[i:] } ``` https://github.com/golang/go/blob/39a9cb4b5dbf1e518b0c66fa3a7b4175f90226fc/src/net/url/url.go#L454-L466",1,net url comment of split function is wrong what did you expect to see split slices s into two substrings separated by the first occurrence of sep if cutc is true then sep is excluded from the second substring if sep does not occur in s then s and the empty string is returned func split s string sep byte cutc bool string string i strings indexbyte s sep if i return s if cutc return s s return s s what did you see instead split slices s into two substrings separated by the first occurrence of sep if cutc is true then sep is included with the second substring if sep does not occur in s then s and the empty string is returned func split s string sep byte cutc bool string string i strings indexbyte s sep if i return s if cutc return s s return s s ,1 19417,4388698633.0,IssuesEvent,2016-08-08 19:44:08,golang/go,https://api.github.com/repos/golang/go,reopened,website: inconsistency in supported OS X versions,Documentation,"https://golang.org/dl/ mentions: > Apple OS X > OS X 10.8 or later, Intel 64-bit processor https://golang.org/doc/install says: > Official binary distributions are available for ... > Mac OS X (10.7 and above) ",1.0,"website: inconsistency in supported OS X versions - https://golang.org/dl/ mentions: > Apple OS X > OS X 10.8 or later, Intel 64-bit processor https://golang.org/doc/install says: > Official binary distributions are available for ... > Mac OS X (10.7 and above) ",1,website inconsistency in supported os x versions mentions apple os x os x or later intel bit processor says official binary distributions are available for mac os x and above ,1 69102,9256549528.0,IssuesEvent,2019-03-16 20:02:06,golang/go,https://api.github.com/repos/golang/go,closed,blog: document Code generated convention in the Generating code blog post,Documentation NeedsFix,"As the Go community has reached consensus on the convention to use for distinguishing machine-generated code (i.e. https://golang.org/s/generatedcode), it would be good if the [Generating code](https://blog.golang.org/generate) article on the Go blog was updated to reflect this. Preferably a link could also be added from the Generating code article to https://golang.org/s/generatedcode In particular, the Generating code article is still using the convention `// generated by stringer -type Pill pill.go; DO NOT EDIT`. Since the blog post is the first hit (for me at least) on Google which searching for *generate code golang*, the article should in my opinion be updated so that new Gophers learn the newly established convention.",1.0,"blog: document Code generated convention in the Generating code blog post - As the Go community has reached consensus on the convention to use for distinguishing machine-generated code (i.e. https://golang.org/s/generatedcode), it would be good if the [Generating code](https://blog.golang.org/generate) article on the Go blog was updated to reflect this. Preferably a link could also be added from the Generating code article to https://golang.org/s/generatedcode In particular, the Generating code article is still using the convention `// generated by stringer -type Pill pill.go; DO NOT EDIT`. Since the blog post is the first hit (for me at least) on Google which searching for *generate code golang*, the article should in my opinion be updated so that new Gophers learn the newly established convention.",1,blog document code generated convention in the generating code blog post as the go community has reached consensus on the convention to use for distinguishing machine generated code i e it would be good if the article on the go blog was updated to reflect this preferably a link could also be added from the generating code article to in particular the generating code article is still using the convention generated by stringer type pill pill go do not edit since the blog post is the first hit for me at least on google which searching for generate code golang the article should in my opinion be updated so that new gophers learn the newly established convention ,1 65258,16174737695.0,IssuesEvent,2021-05-03 03:37:44,golang/go,https://api.github.com/repos/golang/go,opened,x/build: gopls-CI Kokoro presubmit failing on CL 315570 due to `rsync` failure,Builders NeedsInvestigation gopls,"[CL 315570](https://golang.org/cl/315570) is passing the TryBots and two out of three of the `gopls-legacy` kokoro presubmits (Go 1.13 and Go 1.14). However, the Go 1.12 presubmit is failing due to what appears to be an internal error within the presubmit script. The tests appear to have all run successfully, but then the presubmit script fails due to an `rsync` error attempting to transfer `gopls/go.mod` somewhere. The failure log also links to a document that no longer exists (https://go.googlesource.com/tools/+/refs/heads/master/gopls/doc/user.md#supported-go-versions), and especially given that it isn't at all clear to me why we're even testing against Go 1.12 — a version that hasn't been supported by the rest of the Go project for over a year now (2020-02-25). If this presubmit test is indicating a real problem with the CL, then it needs to be improved to more clearly explain what that problem is. Otherwise, the presubmit should be fixed (or disabled) to eliminate the spurious failure. CC @golang/release @ianthehat @stamblerre @findleyr
Log ``` Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. [19:17:32] Transferring environment variable script to build VM [19:17:33] Transferring kokoro_log_reader.py to build VM [19:17:34] Transferring source code to build VM [19:17:36] Executing build script on build VM [ID: 5087322] Executing command via SSH: export KOKORO_BUILD_NUMBER=""2301"" export KOKORO_JOB_NAME=""golang/tools/gopls-legacy/presubmit-112"" source /tmpfs/kokoro-env_vars.sh; cd /tmpfs/src/ ; chmod 755 piper/google3/go/kokoro/tools/gopls-legacy/build.sh ; nohup bash -c ""( rm -f /tmpfs/kokoro_build_exit_code ; piper/google3/go/kokoro/tools/gopls-legacy/build.sh ; echo \${PIPESTATUS[0]} > /tmpfs/kokoro_build_exit_code ) > /tmpfs/kokoro_build.log 2>&1"" > /dev/null 2>&1 & echo $! > /tmpfs/kokoro_build.pid ; python /tmpfs/kokoro_log_reader.py /tmpfs/kokoro_build.log /tmpfs/kokoro_build_exit_code /tmpfs/kokoro_build.pid /tmpfs/kokoro_log_reader.pid --start_byte 0 ABOUT THIS BUILD: this build runs gopls tests on 1.12. See https://go.googlesource.com/tools/+/refs/heads/master/gopls/doc/user.md#supported-go-versions for information on supported gopls versions. Unable to find image 'golang:1.12' locally 1.12: Pulling from library/golang dc65f448a2e2: Pulling fs layer 346ffb2b67d7: Pulling fs layer dea4ecac934f: Pulling fs layer 8ac92ddf84b3: Pulling fs layer 7ca605383307: Pulling fs layer 020f524b99dd: Pulling fs layer 06036b0307c9: Pulling fs layer 7ca605383307: Waiting 020f524b99dd: Waiting 06036b0307c9: Waiting 8ac92ddf84b3: Waiting 346ffb2b67d7: Verifying Checksum 346ffb2b67d7: Download complete dea4ecac934f: Download complete dc65f448a2e2: Verifying Checksum dc65f448a2e2: Download complete 8ac92ddf84b3: Verifying Checksum 8ac92ddf84b3: Download complete 06036b0307c9: Verifying Checksum 06036b0307c9: Download complete 7ca605383307: Verifying Checksum 7ca605383307: Download complete 020f524b99dd: Verifying Checksum 020f524b99dd: Download complete dc65f448a2e2: Pull complete 346ffb2b67d7: Pull complete dea4ecac934f: Pull complete 8ac92ddf84b3: Pull complete 7ca605383307: Pull complete 020f524b99dd: Pull complete 06036b0307c9: Pull complete Digest: sha256:d0e79a9c39cdb3d71cc45fec929d1308d50420b79201467ec602b1b80cc314a8 Status: Downloaded newer image for golang:1.12 go version go1.12.17 linux/amd64 total 96 -rw-rw-r-- 1 1000 1003 173 May 3 02:16 AUTHORS -rw-rw-r-- 1 1000 1003 913 May 3 02:16 CONTRIBUTING.md -rw-rw-r-- 1 1000 1003 170 May 3 02:16 CONTRIBUTORS -rw-rw-r-- 1 1000 1003 1479 May 3 02:16 LICENSE -rw-rw-r-- 1 1000 1003 1303 May 3 02:16 PATENTS -rw-rw-r-- 1 1000 1003 1381 May 3 02:16 README.md drwxrwsr-x 3 1000 1003 4096 May 3 02:16 benchmark drwxrwsr-x 3 1000 1003 4096 May 3 02:16 blog drwxrwsr-x 29 1000 1003 4096 May 3 02:16 cmd -rw-rw-r-- 1 1000 1003 21 May 3 02:16 codereview.cfg drwxrwsr-x 3 1000 1003 4096 May 3 02:16 container drwxrwsr-x 2 1000 1003 4096 May 3 02:16 copyright drwxrwsr-x 2 1000 1003 4096 May 3 02:16 cover drwxrwsr-x 17 1000 1003 4096 May 3 02:16 go -rw-rw-r-- 1 1000 1003 323 May 3 02:16 go.mod -rw-rw-r-- 1 1000 1003 2834 May 3 02:16 go.sum drwxrwsr-x 7 1000 1003 4096 May 3 02:16 godoc drwxrwsr-x 7 1000 1003 4096 May 3 02:16 gopls drwxrwsr-x 2 1000 1003 4096 May 3 02:16 imports drwxrwsr-x 22 1000 1003 4096 May 3 02:16 internal drwxrwsr-x 3 1000 1003 4096 May 3 02:16 playground drwxrwsr-x 3 1000 1003 4096 May 3 02:16 present drwxrwsr-x 6 1000 1003 4096 May 3 02:16 refactor drwxrwsr-x 2 1000 1003 4096 May 3 02:16 txtar go: finding github.com/yuin/goldmark v1.3.3 go: finding golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4 go: finding golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 go: finding golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: finding golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: finding golang.org/x/mod v0.4.2 go: finding golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898 go: finding golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e go: finding golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550 go: finding golang.org/x/sys v0.0.0-20210330210617-4fbd30eecc44 go: finding golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 go: finding golang.org/x/text v0.3.3 go: finding golang.org/x/sys v0.0.0-20201119102817-f84b799fce68 go: finding golang.org/x/sys v0.0.0-20190412213103-97732733099d go: finding golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3 go: finding golang.org/x/text v0.3.0 go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2 go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a go: finding golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e go: finding golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7 go: finding golang.org/x/net v0.0.0-20190620200207-3b0461eec859 go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58 go: downloading golang.org/x/mod v0.4.2 go: downloading golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: downloading golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: downloading golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 go: extracting golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: extracting golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: extracting golang.org/x/mod v0.4.2 go: extracting golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 ok golang.org/x/tools/internal/lsp 17.417s ok golang.org/x/tools/internal/lsp/analysis/fillreturns 3.840s ok golang.org/x/tools/internal/lsp/analysis/fillstruct 2.430s ok golang.org/x/tools/internal/lsp/analysis/nonewvars 2.052s ok golang.org/x/tools/internal/lsp/analysis/noresultvalues 0.097s ok golang.org/x/tools/internal/lsp/analysis/simplifycompositelit 0.131s ok golang.org/x/tools/internal/lsp/analysis/simplifyrange 2.947s ok golang.org/x/tools/internal/lsp/analysis/simplifyslice 0.142s ok golang.org/x/tools/internal/lsp/analysis/undeclaredname 0.126s ok golang.org/x/tools/internal/lsp/analysis/unusedparams 3.925s ? golang.org/x/tools/internal/lsp/browser [no test files] ok golang.org/x/tools/internal/lsp/cache 0.050s ok golang.org/x/tools/internal/lsp/cmd 20.132s ? golang.org/x/tools/internal/lsp/cmd/test [no test files] ok golang.org/x/tools/internal/lsp/command 2.946s ? golang.org/x/tools/internal/lsp/command/commandmeta [no test files] ? golang.org/x/tools/internal/lsp/command/gen [no test files] ? golang.org/x/tools/internal/lsp/debug [no test files] ? golang.org/x/tools/internal/lsp/debug/log [no test files] ? golang.org/x/tools/internal/lsp/debug/tag [no test files] ok golang.org/x/tools/internal/lsp/diff 0.027s ok golang.org/x/tools/internal/lsp/diff/difftest 0.088s ok golang.org/x/tools/internal/lsp/diff/myers 0.013s ok golang.org/x/tools/internal/lsp/fake 0.035s ok golang.org/x/tools/internal/lsp/fuzzy 0.017s ? golang.org/x/tools/internal/lsp/helper [no test files] ok golang.org/x/tools/internal/lsp/lsprpc 1.363s ok golang.org/x/tools/internal/lsp/mod 0.048s ? golang.org/x/tools/internal/lsp/protocol [no test files] ok golang.org/x/tools/internal/lsp/regtest 0.018s ok golang.org/x/tools/internal/lsp/snippet 0.006s ok golang.org/x/tools/internal/lsp/source 10.442s ok golang.org/x/tools/internal/lsp/source/completion 0.049s ? golang.org/x/tools/internal/lsp/tests [no test files] go: finding github.com/google/go-cmp v0.5.5 go: finding github.com/google/safehtml v0.0.2 go: finding github.com/BurntSushi/toml v0.3.1 go: finding github.com/jba/templatecheck v0.5.0 go: finding github.com/sergi/go-diff v1.1.0 go: finding github.com/sanity-io/litter v1.5.0 go: finding mvdan.cc/gofumpt v0.1.1 go: finding mvdan.cc/xurls/v2 v2.2.0 go: finding honnef.co/go/tools v0.1.3 go: finding github.com/davecgh/go-spew v0.0.0-20161028175848-04cdfd42973b go: finding github.com/stretchr/testify v0.0.0-20161117074351-18a02ba4a312 go: finding github.com/stretchr/testify v1.4.0 go: finding github.com/davecgh/go-spew v1.1.1 go: finding github.com/pmezard/go-difflib v0.0.0-20151028094244-d8ed2627bdf0 go: finding github.com/kr/pretty v0.1.0 go: finding golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 go: finding github.com/rogpeppe/go-internal v1.6.2 go: finding golang.org/x/mod v0.4.0 go: finding github.com/rogpeppe/go-internal v1.5.2 go: finding github.com/kisielk/gotool v1.0.0 go: finding github.com/google/go-cmp v0.5.4 go: finding github.com/kr/text v0.1.0 go: finding gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 go: finding gopkg.in/yaml.v2 v2.2.4 go: finding github.com/davecgh/go-spew v1.1.0 go: finding gopkg.in/yaml.v2 v2.2.2 go: finding github.com/pmezard/go-difflib v1.0.0 go: finding github.com/stretchr/objx v0.1.0 go: finding github.com/kr/pty v1.1.1 go: finding gopkg.in/errgo.v2 v2.1.0 go: finding gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405 go: downloading mvdan.cc/xurls/v2 v2.2.0 go: downloading github.com/sanity-io/litter v1.5.0 go: downloading mvdan.cc/gofumpt v0.1.1 go: downloading github.com/google/go-cmp v0.5.5 go: downloading github.com/sergi/go-diff v1.1.0 go: extracting github.com/sanity-io/litter v1.5.0 go: downloading github.com/jba/templatecheck v0.5.0 go: extracting mvdan.cc/xurls/v2 v2.2.0 go: extracting github.com/jba/templatecheck v0.5.0 go: downloading github.com/google/safehtml v0.0.2 go: extracting github.com/sergi/go-diff v1.1.0 go: extracting github.com/google/go-cmp v0.5.5 go: extracting mvdan.cc/gofumpt v0.1.1 go: extracting github.com/google/safehtml v0.0.2 go: downloading golang.org/x/text v0.3.3 go: extracting golang.org/x/text v0.3.3 ? golang.org/x/tools/gopls [no test files] ok golang.org/x/tools/gopls/doc 5.914s ? golang.org/x/tools/gopls/integration/govim [no test files] ok golang.org/x/tools/gopls/internal/hooks 0.057s ok golang.org/x/tools/gopls/internal/regtest/bench 0.066s ok golang.org/x/tools/gopls/internal/regtest/codelens 10.144s ok golang.org/x/tools/gopls/internal/regtest/completion 6.542s ok golang.org/x/tools/gopls/internal/regtest/diagnostics 48.518s ok golang.org/x/tools/gopls/internal/regtest/misc 39.890s ok golang.org/x/tools/gopls/internal/regtest/modfile 3.086s ok golang.org/x/tools/gopls/internal/regtest/watch 10.571s ok golang.org/x/tools/gopls/internal/regtest/workspace 11.245s ? golang.org/x/tools/gopls/release [no test files] ok golang.org/x/tools/gopls/test 20.946s ok golang.org/x/tools/gopls/test/debug 4.701s [ID: 5087322] Build finished after 141 secs, exit value: 0 Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] [19:19:57] Collecting build artifacts from build VM Build terminated with Tool Failure. [19:22:49] Build failed because of internal error ```
",1.0,"x/build: gopls-CI Kokoro presubmit failing on CL 315570 due to `rsync` failure - [CL 315570](https://golang.org/cl/315570) is passing the TryBots and two out of three of the `gopls-legacy` kokoro presubmits (Go 1.13 and Go 1.14). However, the Go 1.12 presubmit is failing due to what appears to be an internal error within the presubmit script. The tests appear to have all run successfully, but then the presubmit script fails due to an `rsync` error attempting to transfer `gopls/go.mod` somewhere. The failure log also links to a document that no longer exists (https://go.googlesource.com/tools/+/refs/heads/master/gopls/doc/user.md#supported-go-versions), and especially given that it isn't at all clear to me why we're even testing against Go 1.12 — a version that hasn't been supported by the rest of the Go project for over a year now (2020-02-25). If this presubmit test is indicating a real problem with the CL, then it needs to be improved to more clearly explain what that problem is. Otherwise, the presubmit should be fixed (or disabled) to eliminate the spurious failure. CC @golang/release @ianthehat @stamblerre @findleyr
Log ``` Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. [19:17:32] Transferring environment variable script to build VM [19:17:33] Transferring kokoro_log_reader.py to build VM [19:17:34] Transferring source code to build VM [19:17:36] Executing build script on build VM [ID: 5087322] Executing command via SSH: export KOKORO_BUILD_NUMBER=""2301"" export KOKORO_JOB_NAME=""golang/tools/gopls-legacy/presubmit-112"" source /tmpfs/kokoro-env_vars.sh; cd /tmpfs/src/ ; chmod 755 piper/google3/go/kokoro/tools/gopls-legacy/build.sh ; nohup bash -c ""( rm -f /tmpfs/kokoro_build_exit_code ; piper/google3/go/kokoro/tools/gopls-legacy/build.sh ; echo \${PIPESTATUS[0]} > /tmpfs/kokoro_build_exit_code ) > /tmpfs/kokoro_build.log 2>&1"" > /dev/null 2>&1 & echo $! > /tmpfs/kokoro_build.pid ; python /tmpfs/kokoro_log_reader.py /tmpfs/kokoro_build.log /tmpfs/kokoro_build_exit_code /tmpfs/kokoro_build.pid /tmpfs/kokoro_log_reader.pid --start_byte 0 ABOUT THIS BUILD: this build runs gopls tests on 1.12. See https://go.googlesource.com/tools/+/refs/heads/master/gopls/doc/user.md#supported-go-versions for information on supported gopls versions. Unable to find image 'golang:1.12' locally 1.12: Pulling from library/golang dc65f448a2e2: Pulling fs layer 346ffb2b67d7: Pulling fs layer dea4ecac934f: Pulling fs layer 8ac92ddf84b3: Pulling fs layer 7ca605383307: Pulling fs layer 020f524b99dd: Pulling fs layer 06036b0307c9: Pulling fs layer 7ca605383307: Waiting 020f524b99dd: Waiting 06036b0307c9: Waiting 8ac92ddf84b3: Waiting 346ffb2b67d7: Verifying Checksum 346ffb2b67d7: Download complete dea4ecac934f: Download complete dc65f448a2e2: Verifying Checksum dc65f448a2e2: Download complete 8ac92ddf84b3: Verifying Checksum 8ac92ddf84b3: Download complete 06036b0307c9: Verifying Checksum 06036b0307c9: Download complete 7ca605383307: Verifying Checksum 7ca605383307: Download complete 020f524b99dd: Verifying Checksum 020f524b99dd: Download complete dc65f448a2e2: Pull complete 346ffb2b67d7: Pull complete dea4ecac934f: Pull complete 8ac92ddf84b3: Pull complete 7ca605383307: Pull complete 020f524b99dd: Pull complete 06036b0307c9: Pull complete Digest: sha256:d0e79a9c39cdb3d71cc45fec929d1308d50420b79201467ec602b1b80cc314a8 Status: Downloaded newer image for golang:1.12 go version go1.12.17 linux/amd64 total 96 -rw-rw-r-- 1 1000 1003 173 May 3 02:16 AUTHORS -rw-rw-r-- 1 1000 1003 913 May 3 02:16 CONTRIBUTING.md -rw-rw-r-- 1 1000 1003 170 May 3 02:16 CONTRIBUTORS -rw-rw-r-- 1 1000 1003 1479 May 3 02:16 LICENSE -rw-rw-r-- 1 1000 1003 1303 May 3 02:16 PATENTS -rw-rw-r-- 1 1000 1003 1381 May 3 02:16 README.md drwxrwsr-x 3 1000 1003 4096 May 3 02:16 benchmark drwxrwsr-x 3 1000 1003 4096 May 3 02:16 blog drwxrwsr-x 29 1000 1003 4096 May 3 02:16 cmd -rw-rw-r-- 1 1000 1003 21 May 3 02:16 codereview.cfg drwxrwsr-x 3 1000 1003 4096 May 3 02:16 container drwxrwsr-x 2 1000 1003 4096 May 3 02:16 copyright drwxrwsr-x 2 1000 1003 4096 May 3 02:16 cover drwxrwsr-x 17 1000 1003 4096 May 3 02:16 go -rw-rw-r-- 1 1000 1003 323 May 3 02:16 go.mod -rw-rw-r-- 1 1000 1003 2834 May 3 02:16 go.sum drwxrwsr-x 7 1000 1003 4096 May 3 02:16 godoc drwxrwsr-x 7 1000 1003 4096 May 3 02:16 gopls drwxrwsr-x 2 1000 1003 4096 May 3 02:16 imports drwxrwsr-x 22 1000 1003 4096 May 3 02:16 internal drwxrwsr-x 3 1000 1003 4096 May 3 02:16 playground drwxrwsr-x 3 1000 1003 4096 May 3 02:16 present drwxrwsr-x 6 1000 1003 4096 May 3 02:16 refactor drwxrwsr-x 2 1000 1003 4096 May 3 02:16 txtar go: finding github.com/yuin/goldmark v1.3.3 go: finding golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4 go: finding golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 go: finding golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: finding golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: finding golang.org/x/mod v0.4.2 go: finding golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898 go: finding golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e go: finding golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550 go: finding golang.org/x/sys v0.0.0-20210330210617-4fbd30eecc44 go: finding golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 go: finding golang.org/x/text v0.3.3 go: finding golang.org/x/sys v0.0.0-20201119102817-f84b799fce68 go: finding golang.org/x/sys v0.0.0-20190412213103-97732733099d go: finding golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3 go: finding golang.org/x/text v0.3.0 go: finding golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2 go: finding golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a go: finding golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e go: finding golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7 go: finding golang.org/x/net v0.0.0-20190620200207-3b0461eec859 go: finding golang.org/x/sync v0.0.0-20190423024810-112230192c58 go: downloading golang.org/x/mod v0.4.2 go: downloading golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: downloading golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: downloading golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 go: extracting golang.org/x/sync v0.0.0-20210220032951-036812b2e83c go: extracting golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 go: extracting golang.org/x/mod v0.4.2 go: extracting golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57 ok golang.org/x/tools/internal/lsp 17.417s ok golang.org/x/tools/internal/lsp/analysis/fillreturns 3.840s ok golang.org/x/tools/internal/lsp/analysis/fillstruct 2.430s ok golang.org/x/tools/internal/lsp/analysis/nonewvars 2.052s ok golang.org/x/tools/internal/lsp/analysis/noresultvalues 0.097s ok golang.org/x/tools/internal/lsp/analysis/simplifycompositelit 0.131s ok golang.org/x/tools/internal/lsp/analysis/simplifyrange 2.947s ok golang.org/x/tools/internal/lsp/analysis/simplifyslice 0.142s ok golang.org/x/tools/internal/lsp/analysis/undeclaredname 0.126s ok golang.org/x/tools/internal/lsp/analysis/unusedparams 3.925s ? golang.org/x/tools/internal/lsp/browser [no test files] ok golang.org/x/tools/internal/lsp/cache 0.050s ok golang.org/x/tools/internal/lsp/cmd 20.132s ? golang.org/x/tools/internal/lsp/cmd/test [no test files] ok golang.org/x/tools/internal/lsp/command 2.946s ? golang.org/x/tools/internal/lsp/command/commandmeta [no test files] ? golang.org/x/tools/internal/lsp/command/gen [no test files] ? golang.org/x/tools/internal/lsp/debug [no test files] ? golang.org/x/tools/internal/lsp/debug/log [no test files] ? golang.org/x/tools/internal/lsp/debug/tag [no test files] ok golang.org/x/tools/internal/lsp/diff 0.027s ok golang.org/x/tools/internal/lsp/diff/difftest 0.088s ok golang.org/x/tools/internal/lsp/diff/myers 0.013s ok golang.org/x/tools/internal/lsp/fake 0.035s ok golang.org/x/tools/internal/lsp/fuzzy 0.017s ? golang.org/x/tools/internal/lsp/helper [no test files] ok golang.org/x/tools/internal/lsp/lsprpc 1.363s ok golang.org/x/tools/internal/lsp/mod 0.048s ? golang.org/x/tools/internal/lsp/protocol [no test files] ok golang.org/x/tools/internal/lsp/regtest 0.018s ok golang.org/x/tools/internal/lsp/snippet 0.006s ok golang.org/x/tools/internal/lsp/source 10.442s ok golang.org/x/tools/internal/lsp/source/completion 0.049s ? golang.org/x/tools/internal/lsp/tests [no test files] go: finding github.com/google/go-cmp v0.5.5 go: finding github.com/google/safehtml v0.0.2 go: finding github.com/BurntSushi/toml v0.3.1 go: finding github.com/jba/templatecheck v0.5.0 go: finding github.com/sergi/go-diff v1.1.0 go: finding github.com/sanity-io/litter v1.5.0 go: finding mvdan.cc/gofumpt v0.1.1 go: finding mvdan.cc/xurls/v2 v2.2.0 go: finding honnef.co/go/tools v0.1.3 go: finding github.com/davecgh/go-spew v0.0.0-20161028175848-04cdfd42973b go: finding github.com/stretchr/testify v0.0.0-20161117074351-18a02ba4a312 go: finding github.com/stretchr/testify v1.4.0 go: finding github.com/davecgh/go-spew v1.1.1 go: finding github.com/pmezard/go-difflib v0.0.0-20151028094244-d8ed2627bdf0 go: finding github.com/kr/pretty v0.1.0 go: finding golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 go: finding github.com/rogpeppe/go-internal v1.6.2 go: finding golang.org/x/mod v0.4.0 go: finding github.com/rogpeppe/go-internal v1.5.2 go: finding github.com/kisielk/gotool v1.0.0 go: finding github.com/google/go-cmp v0.5.4 go: finding github.com/kr/text v0.1.0 go: finding gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 go: finding gopkg.in/yaml.v2 v2.2.4 go: finding github.com/davecgh/go-spew v1.1.0 go: finding gopkg.in/yaml.v2 v2.2.2 go: finding github.com/pmezard/go-difflib v1.0.0 go: finding github.com/stretchr/objx v0.1.0 go: finding github.com/kr/pty v1.1.1 go: finding gopkg.in/errgo.v2 v2.1.0 go: finding gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 go: finding gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405 go: downloading mvdan.cc/xurls/v2 v2.2.0 go: downloading github.com/sanity-io/litter v1.5.0 go: downloading mvdan.cc/gofumpt v0.1.1 go: downloading github.com/google/go-cmp v0.5.5 go: downloading github.com/sergi/go-diff v1.1.0 go: extracting github.com/sanity-io/litter v1.5.0 go: downloading github.com/jba/templatecheck v0.5.0 go: extracting mvdan.cc/xurls/v2 v2.2.0 go: extracting github.com/jba/templatecheck v0.5.0 go: downloading github.com/google/safehtml v0.0.2 go: extracting github.com/sergi/go-diff v1.1.0 go: extracting github.com/google/go-cmp v0.5.5 go: extracting mvdan.cc/gofumpt v0.1.1 go: extracting github.com/google/safehtml v0.0.2 go: downloading golang.org/x/text v0.3.3 go: extracting golang.org/x/text v0.3.3 ? golang.org/x/tools/gopls [no test files] ok golang.org/x/tools/gopls/doc 5.914s ? golang.org/x/tools/gopls/integration/govim [no test files] ok golang.org/x/tools/gopls/internal/hooks 0.057s ok golang.org/x/tools/gopls/internal/regtest/bench 0.066s ok golang.org/x/tools/gopls/internal/regtest/codelens 10.144s ok golang.org/x/tools/gopls/internal/regtest/completion 6.542s ok golang.org/x/tools/gopls/internal/regtest/diagnostics 48.518s ok golang.org/x/tools/gopls/internal/regtest/misc 39.890s ok golang.org/x/tools/gopls/internal/regtest/modfile 3.086s ok golang.org/x/tools/gopls/internal/regtest/watch 10.571s ok golang.org/x/tools/gopls/internal/regtest/workspace 11.245s ? golang.org/x/tools/gopls/release [no test files] ok golang.org/x/tools/gopls/test 20.946s ok golang.org/x/tools/gopls/test/debug 4.701s [ID: 5087322] Build finished after 141 secs, exit value: 0 Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. rsync: send_files failed to open ""/tmpfs/src/git/tools/gopls/go.mod"": Permission denied (13) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3] [19:19:57] Collecting build artifacts from build VM Build terminated with Tool Failure. [19:22:49] Build failed because of internal error ```
",0,x build gopls ci kokoro presubmit failing on cl due to rsync failure is passing the trybots and two out of three of the gopls legacy kokoro presubmits go and go however the go presubmit is failing due to what appears to be an internal error within the presubmit script the tests appear to have all run successfully but then the presubmit script fails due to an rsync error attempting to transfer gopls go mod somewhere the failure log also links to a document that no longer exists and especially given that it isn t at all clear to me why we re even testing against go — a version that hasn t been supported by the rest of the go project for over a year now if this presubmit test is indicating a real problem with the cl then it needs to be improved to more clearly explain what that problem is otherwise the presubmit should be fixed or disabled to eliminate the spurious failure cc golang release ianthehat stamblerre findleyr log warning permanently added localhost ecdsa to the list of known hosts warning permanently added localhost ecdsa to the list of known hosts warning permanently added localhost ecdsa to the list of known hosts transferring environment variable script to build vm transferring kokoro log reader py to build vm transferring source code to build vm executing build script on build vm executing command via ssh export kokoro build number export kokoro job name golang tools gopls legacy presubmit source tmpfs kokoro env vars sh cd tmpfs src chmod piper go kokoro tools gopls legacy build sh nohup bash c rm f tmpfs kokoro build exit code piper go kokoro tools gopls legacy build sh echo pipestatus tmpfs kokoro build exit code tmpfs kokoro build log dev null echo tmpfs kokoro build pid python tmpfs kokoro log reader py tmpfs kokoro build log tmpfs kokoro build exit code tmpfs kokoro build pid tmpfs kokoro log reader pid start byte about this build this build runs gopls tests on see for information on supported gopls versions unable to find image golang locally pulling from library golang pulling fs layer pulling fs layer pulling fs layer pulling fs layer pulling fs layer pulling fs layer pulling fs layer waiting waiting waiting waiting verifying checksum download complete download complete verifying checksum download complete verifying checksum download complete verifying checksum download complete verifying checksum download complete verifying checksum download complete pull complete pull complete pull complete pull complete pull complete pull complete pull complete digest status downloaded newer image for golang go version linux total rw rw r may authors rw rw r may contributing md rw rw r may contributors rw rw r may license rw rw r may patents rw rw r may readme md drwxrwsr x may benchmark drwxrwsr x may blog drwxrwsr x may cmd rw rw r may codereview cfg drwxrwsr x may container drwxrwsr x may copyright drwxrwsr x may cover drwxrwsr x may go rw rw r may go mod rw rw r may go sum drwxrwsr x may godoc drwxrwsr x may gopls drwxrwsr x may imports drwxrwsr x may internal drwxrwsr x may playground drwxrwsr x may present drwxrwsr x may refactor drwxrwsr x may txtar go finding github com yuin goldmark go finding golang org x net go finding golang org x sys go finding golang org x xerrors go finding golang org x sync go finding golang org x mod go finding golang org x xerrors go finding golang org x tools go finding golang org x crypto go finding golang org x sys go finding golang org x term go finding golang org x text go finding golang org x sys go finding golang org x sys go finding golang org x net go finding golang org x text go finding golang org x crypto go finding golang org x sys go finding golang org x tools go finding golang org x xerrors go finding golang org x net go finding golang org x sync go downloading golang org x mod go downloading golang org x xerrors go downloading golang org x sync go downloading golang org x sys go extracting golang org x sync go extracting golang org x xerrors go extracting golang org x mod go extracting golang org x sys ok golang org x tools internal lsp ok golang org x tools internal lsp analysis fillreturns ok golang org x tools internal lsp analysis fillstruct ok golang org x tools internal lsp analysis nonewvars ok golang org x tools internal lsp analysis noresultvalues ok golang org x tools internal lsp analysis simplifycompositelit ok golang org x tools internal lsp analysis simplifyrange ok golang org x tools internal lsp analysis simplifyslice ok golang org x tools internal lsp analysis undeclaredname ok golang org x tools internal lsp analysis unusedparams golang org x tools internal lsp browser ok golang org x tools internal lsp cache ok golang org x tools internal lsp cmd golang org x tools internal lsp cmd test ok golang org x tools internal lsp command golang org x tools internal lsp command commandmeta golang org x tools internal lsp command gen golang org x tools internal lsp debug golang org x tools internal lsp debug log golang org x tools internal lsp debug tag ok golang org x tools internal lsp diff ok golang org x tools internal lsp diff difftest ok golang org x tools internal lsp diff myers ok golang org x tools internal lsp fake ok golang org x tools internal lsp fuzzy golang org x tools internal lsp helper ok golang org x tools internal lsp lsprpc ok golang org x tools internal lsp mod golang org x tools internal lsp protocol ok golang org x tools internal lsp regtest ok golang org x tools internal lsp snippet ok golang org x tools internal lsp source ok golang org x tools internal lsp source completion golang org x tools internal lsp tests go finding github com google go cmp go finding github com google safehtml go finding github com burntsushi toml go finding github com jba templatecheck go finding github com sergi go diff go finding github com sanity io litter go finding mvdan cc gofumpt go finding mvdan cc xurls go finding honnef co go tools go finding github com davecgh go spew go finding github com stretchr testify go finding github com stretchr testify go finding github com davecgh go spew go finding github com pmezard go difflib go finding github com kr pretty go finding golang org x xerrors go finding github com rogpeppe go internal go finding golang org x mod go finding github com rogpeppe go internal go finding github com kisielk gotool go finding github com google go cmp go finding github com kr text go finding gopkg in check go finding gopkg in yaml go finding github com davecgh go spew go finding gopkg in yaml go finding github com pmezard go difflib go finding github com stretchr objx go finding github com kr pty go finding gopkg in errgo go finding gopkg in check go finding gopkg in check go downloading mvdan cc xurls go downloading github com sanity io litter go downloading mvdan cc gofumpt go downloading github com google go cmp go downloading github com sergi go diff go extracting github com sanity io litter go downloading github com jba templatecheck go extracting mvdan cc xurls go extracting github com jba templatecheck go downloading github com google safehtml go extracting github com sergi go diff go extracting github com google go cmp go extracting mvdan cc gofumpt go extracting github com google safehtml go downloading golang org x text go extracting golang org x text golang org x tools gopls ok golang org x tools gopls doc golang org x tools gopls integration govim ok golang org x tools gopls internal hooks ok golang org x tools gopls internal regtest bench ok golang org x tools gopls internal regtest codelens ok golang org x tools gopls internal regtest completion ok golang org x tools gopls internal regtest diagnostics ok golang org x tools gopls internal regtest misc ok golang org x tools gopls internal regtest modfile ok golang org x tools gopls internal regtest watch ok golang org x tools gopls internal regtest workspace golang org x tools gopls release ok golang org x tools gopls test ok golang org x tools gopls test debug build finished after secs exit value warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c warning permanently added localhost ecdsa to the list of known hosts rsync send files failed to open tmpfs src git tools gopls go mod permission denied rsync error some files attrs were not transferred see previous errors code at main c collecting build artifacts from build vm build terminated with tool failure build failed because of internal error ,0 173129,14403475534.0,IssuesEvent,2020-12-03 16:06:08,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document flag changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
flag

TODO: https://golang.org/cl/240014: add Func

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document flag changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
flag

TODO: https://golang.org/cl/240014: add Func

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document flag changes for go as of filing this issue the contained the following html flag todo a href add func per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 264559,20024979593.0,IssuesEvent,2022-02-01 20:14:33,golang/go,https://api.github.com/repos/golang/go,closed,x/website/_content/ref: lang version determining rule should be documented in Go Module Reference,Documentation NeedsFix okay-after-beta1,"The behavior implemented in https://github.com/golang/go/issues/44976 should be documented at this section: https://golang.org/ref/mod#go-mod-file-go ref: https://groups.google.com/g/golang-nuts/c/lhedc8YaWlM ",1.0,"x/website/_content/ref: lang version determining rule should be documented in Go Module Reference - The behavior implemented in https://github.com/golang/go/issues/44976 should be documented at this section: https://golang.org/ref/mod#go-mod-file-go ref: https://groups.google.com/g/golang-nuts/c/lhedc8YaWlM ",1,x website content ref lang version determining rule should be documented in go module reference the behavior implemented in should be documented at this section ref ,1 156614,13651623347.0,IssuesEvent,2020-09-27 02:24:59,golang/go,https://api.github.com/repos/golang/go,closed,os: File implicitly closed when garbage-collected due to runtime finalizer but this behavior is not documented,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? 
$ go version
go 1.15.2
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? Linux and macOS. ### What did you do? Code: https://play.golang.org/p/YmHIIc7sha4 Note: This does not reproduce in go playground, but can reproduce on my mac/linux. ### What did you expect to see? No panic. ### What did you see instead? panic: bad file descriptor ### Reason I found that this is because there's an implicitly close call when the `file` object is garbage-collected. In os/file_unix.go: ``` func newFile(fd uintptr, name string, kind newFileKind) *File { ... runtime.SetFinalizer(f.file, (*file).close) return f } ``` ### What do I expect I know there's thousands of method to avoid being garbage-collected such as runtime.KeepAlive, but I think this is unreasonable, either this behaviour should be removed or the `file` object should not be garbage-collected. If a user forgets to call file.Close, the memory should be leaking. Also, this behaviour isn't documented anywhere. ",1.0,"os: File implicitly closed when garbage-collected due to runtime finalizer but this behavior is not documented - ### What version of Go are you using (`go version`)? 
$ go version
go 1.15.2
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? Linux and macOS. ### What did you do? Code: https://play.golang.org/p/YmHIIc7sha4 Note: This does not reproduce in go playground, but can reproduce on my mac/linux. ### What did you expect to see? No panic. ### What did you see instead? panic: bad file descriptor ### Reason I found that this is because there's an implicitly close call when the `file` object is garbage-collected. In os/file_unix.go: ``` func newFile(fd uintptr, name string, kind newFileKind) *File { ... runtime.SetFinalizer(f.file, (*file).close) return f } ``` ### What do I expect I know there's thousands of method to avoid being garbage-collected such as runtime.KeepAlive, but I think this is unreasonable, either this behaviour should be removed or the `file` object should not be garbage-collected. If a user forgets to call file.Close, the memory should be leaking. Also, this behaviour isn't documented anywhere. ",1,os file implicitly closed when garbage collected due to runtime finalizer but this behavior is not documented what version of go are you using go version go version go does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env linux and macos what did you do code note this does not reproduce in go playground but can reproduce on my mac linux what did you expect to see no panic what did you see instead panic bad file descriptor reason i found that this is because there s an implicitly close call when the file object is garbage collected in os file unix go func newfile fd uintptr name string kind newfilekind file runtime setfinalizer f file file close return f what do i expect i know there s thousands of method to avoid being garbage collected such as runtime keepalive but i think this is unreasonable either this behaviour should be removed or the file object should not be garbage collected if a user forgets to call file close the memory should be leaking also this behaviour isn t documented anywhere ,1 56889,8129711062.0,IssuesEvent,2018-08-17 15:53:26,golang/go,https://api.github.com/repos/golang/go,closed,doc/code.html: update description of install command,Documentation NeedsFix,"### What version of Go are you using (go version)? `go version go1.10 windows/amd64` ### Does this issue reproduce with the latest release? 1.10 is the latest at this moment ### What operating system and processor architecture are you using (go env)? GOARCH=amd64 GOOS=windows ### What did you do? I have small test program with two small dummy libraries. Go program in the `src` has path `github.com/user/hello` package main import ( ""fmt"" // Libraries bellow are not automatically generated in pkg ""github.com/user/stringutil"" ""github.com/user/tttt"" ) func main() { fmt.Printf(stringutil.Reverse(""\nHello, world.\n"")) fmt.Println(add(85,tttt.Tttt(9))) } `add()` function is in separate file, also in `hello` directory: package main func add(x int, y int) int { return x + y } When I don't have the above libraries compiled and just use go install `hello` program is installed and works but the `pkg` directory is not created and no `stringutil.a` and `tttt.a`. If I want to have libraries generated I have to use `go install` on every library, in which case `pkg` is generated and libraries in it. this is not behaviour according to this documentation: > Whenever the go tool installs a package or binary, it also installs whatever dependencies it has. So when you install the hello program $ go install github.com/user/hello the stringutil package will be installed as well, automatically. Note that I have just installed the latest version (1.10) and just start using it as is writing only one dummy program and two dummy libraries one of which is copied from Go documentation. ### What did you expect to see? Dependencies installed automatically in the `pkg` ### What did you see instead? No `pkg` and no installed dependencies",1.0,"doc/code.html: update description of install command - ### What version of Go are you using (go version)? `go version go1.10 windows/amd64` ### Does this issue reproduce with the latest release? 1.10 is the latest at this moment ### What operating system and processor architecture are you using (go env)? GOARCH=amd64 GOOS=windows ### What did you do? I have small test program with two small dummy libraries. Go program in the `src` has path `github.com/user/hello` package main import ( ""fmt"" // Libraries bellow are not automatically generated in pkg ""github.com/user/stringutil"" ""github.com/user/tttt"" ) func main() { fmt.Printf(stringutil.Reverse(""\nHello, world.\n"")) fmt.Println(add(85,tttt.Tttt(9))) } `add()` function is in separate file, also in `hello` directory: package main func add(x int, y int) int { return x + y } When I don't have the above libraries compiled and just use go install `hello` program is installed and works but the `pkg` directory is not created and no `stringutil.a` and `tttt.a`. If I want to have libraries generated I have to use `go install` on every library, in which case `pkg` is generated and libraries in it. this is not behaviour according to this documentation: > Whenever the go tool installs a package or binary, it also installs whatever dependencies it has. So when you install the hello program $ go install github.com/user/hello the stringutil package will be installed as well, automatically. Note that I have just installed the latest version (1.10) and just start using it as is writing only one dummy program and two dummy libraries one of which is copied from Go documentation. ### What did you expect to see? Dependencies installed automatically in the `pkg` ### What did you see instead? No `pkg` and no installed dependencies",1,doc code html update description of install command what version of go are you using go version go version windows does this issue reproduce with the latest release is the latest at this moment what operating system and processor architecture are you using go env goarch goos windows what did you do i have small test program with two small dummy libraries go program in the src has path github com user hello package main import fmt libraries bellow are not automatically generated in pkg github com user stringutil github com user tttt func main fmt printf stringutil reverse nhello world n fmt println add tttt tttt add function is in separate file also in hello directory package main func add x int y int int return x y when i don t have the above libraries compiled and just use go install hello program is installed and works but the pkg directory is not created and no stringutil a and tttt a if i want to have libraries generated i have to use go install on every library in which case pkg is generated and libraries in it this is not behaviour according to this documentation whenever the go tool installs a package or binary it also installs whatever dependencies it has so when you install the hello program go install github com user hello the stringutil package will be installed as well automatically note that i have just installed the latest version and just start using it as is writing only one dummy program and two dummy libraries one of which is copied from go documentation what did you expect to see dependencies installed automatically in the pkg what did you see instead no pkg and no installed dependencies,1 12937,8751436818.0,IssuesEvent,2018-12-13 22:19:43,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: directory traversal via curly braces in import paths [Go 1.10],Security,"This is a tracking issue for #29231, a security vulnerability fixed in Go 1.10.6.",True,"cmd/go: directory traversal via curly braces in import paths [Go 1.10] - This is a tracking issue for #29231, a security vulnerability fixed in Go 1.10.6.",0,cmd go directory traversal via curly braces in import paths this is a tracking issue for a security vulnerability fixed in go ,0 262461,19804440232.0,IssuesEvent,2022-01-19 04:00:48,golang/go,https://api.github.com/repos/golang/go,closed,spec: shift string(1 << s) should be invalid,Documentation,"```Go package p var s uint var _ = string(1 << s) ``` is not accepted by the compiler: ``` bug.go:3:15: invalid operation: 1 << s (shift of type string) ``` Per the spec (https://golang.org/ref/spec#Constant_expressions): ""If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone."" In this case, the left operand would be converted to `int` (not string). This is different from cases such as, say `float64(1 << s)` where `1` is implicitly converted to `1.0` because it can be done without loss of precision. It seems a bit far-fetched to claim that a `1` can be converted to a string without loss of precision. (That said, the spec is notoriously difficult to decipher with respect to shifts and implicit conversions.) As an aside, there's still #3939 which is proposing to prohibit `string(int_value)`, and `go vet` is checking for this. So we're not permitting a new category of programs by making `string(1 << s)` valid. Both `go/types` and `types2` accept this code. The test `$GOROOT/test/fixedbugs/bug193.go` assumes that this code should fail. ",1.0,"spec: shift string(1 << s) should be invalid - ```Go package p var s uint var _ = string(1 << s) ``` is not accepted by the compiler: ``` bug.go:3:15: invalid operation: 1 << s (shift of type string) ``` Per the spec (https://golang.org/ref/spec#Constant_expressions): ""If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone."" In this case, the left operand would be converted to `int` (not string). This is different from cases such as, say `float64(1 << s)` where `1` is implicitly converted to `1.0` because it can be done without loss of precision. It seems a bit far-fetched to claim that a `1` can be converted to a string without loss of precision. (That said, the spec is notoriously difficult to decipher with respect to shifts and implicit conversions.) As an aside, there's still #3939 which is proposing to prohibit `string(int_value)`, and `go vet` is checking for this. So we're not permitting a new category of programs by making `string(1 << s)` valid. Both `go/types` and `types2` accept this code. The test `$GOROOT/test/fixedbugs/bug193.go` assumes that this code should fail. ",1,spec shift string s should be invalid go package p var s uint var string s is not accepted by the compiler bug go invalid operation s shift of type string per the spec if the left operand of a non constant shift expression is an untyped constant it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone in this case the left operand would be converted to int not string this is different from cases such as say s where is implicitly converted to because it can be done without loss of precision it seems a bit far fetched to claim that a can be converted to a string without loss of precision that said the spec is notoriously difficult to decipher with respect to shifts and implicit conversions as an aside there s still which is proposing to prohibit string int value and go vet is checking for this so we re not permitting a new category of programs by making string s valid both go types and accept this code the test goroot test fixedbugs go assumes that this code should fail ,1 11644,7633460459.0,IssuesEvent,2018-05-06 05:31:47,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: optimize len([]rune(string)) to just count runes,NeedsFix Performance,"### What version of Go are you using (`go version`)? go1.10.1 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? I've benchmarked `len([]rune(string))` and `utf8.RuneCountInString(string)` and I saw that the latter performs better. Here's the [benchmark code](https://play.golang.org/p/M2HHTtuHMI-). **Benchmark Results:** BenchmarkRunCountInString16ascii-8 100000000 11.9 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString16multi-8 20000000 63.5 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString32ascii-8 100000000 18.2 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString32multi-8 10000000 120 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray16ascii-8 50000000 26.2 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray16multi-8 10000000 171 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray32ascii-8 30000000 46.1 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray32multi-8 5000000 322 ns/op ### What did you expect to see? Actually, I wasn't expecting `len([]rune(string))` to be faster compared to `utf8.RuneCountInString`, then again I wanted to open this issue. I noticed that there are a lot people are [using](https://github.com/search?l=Go&q=%22len%28%5B%5Drune%28%22&type=Code) this pattern. ",True,"cmd/compile: optimize len([]rune(string)) to just count runes - ### What version of Go are you using (`go version`)? go1.10.1 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? I've benchmarked `len([]rune(string))` and `utf8.RuneCountInString(string)` and I saw that the latter performs better. Here's the [benchmark code](https://play.golang.org/p/M2HHTtuHMI-). **Benchmark Results:** BenchmarkRunCountInString16ascii-8 100000000 11.9 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString16multi-8 20000000 63.5 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString32ascii-8 100000000 18.2 ns/op 0 B/op 0 allocs/op BenchmarkRunCountInString32multi-8 10000000 120 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray16ascii-8 50000000 26.2 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray16multi-8 10000000 171 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray32ascii-8 30000000 46.1 ns/op 0 B/op 0 allocs/op BenchmarkCastToRuneArray32multi-8 5000000 322 ns/op ### What did you expect to see? Actually, I wasn't expecting `len([]rune(string))` to be faster compared to `utf8.RuneCountInString`, then again I wanted to open this issue. I noticed that there are a lot people are [using](https://github.com/search?l=Go&q=%22len%28%5B%5Drune%28%22&type=Code) this pattern. ",0,cmd compile optimize len rune string to just count runes what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env darwin what did you do i ve benchmarked len rune string and runecountinstring string and i saw that the latter performs better here s the benchmark results ns op b op allocs op ns op b op allocs op ns op b op allocs op ns op b op allocs op ns op b op allocs op ns op b op allocs op ns op b op allocs op ns op what did you expect to see actually i wasn t expecting len rune string to be faster compared to runecountinstring then again i wanted to open this issue i noticed that there are a lot people are this pattern ,0 25110,5132878075.0,IssuesEvent,2017-01-11 00:47:10,golang/go,https://api.github.com/repos/golang/go,opened,testing: are T.Run and B.Run safe for concurrent use?,Documentation,"I do not see any documentation specifying if T.Run is safe for concurrent use. I see the following doc for [testing.T](https://tip.golang.org/pkg/testing/#T), which does not mention T.Run: > A test ends when its Test function returns or calls any of the methods FailNow, Fatal, Fatalf, SkipNow, Skip, or Skipf. Those methods, as well as the Parallel method, must be called only from the goroutine running the Test function. > > The other reporting methods, such as the variations of Log and Error, may be called simultaneously from multiple goroutines. There is a similar doc for [testing.B](https://tip.golang.org/pkg/testing/#B). I ask because I believe T.Run was safe for concurrent use in go 1.7. Then, [this line](https://github.com/golang/go/blob/7fb16406139e934d84f7ec66ba440a772747270a/src/testing/testing.go#L663) was added in go 1.8, which made T.Run no longer safe for concurrent use. I don't particularly care whether T.Run is safe for concurrent use, but I think the semantics should be clarified. Optimistically labeling this go1.8.",1.0,"testing: are T.Run and B.Run safe for concurrent use? - I do not see any documentation specifying if T.Run is safe for concurrent use. I see the following doc for [testing.T](https://tip.golang.org/pkg/testing/#T), which does not mention T.Run: > A test ends when its Test function returns or calls any of the methods FailNow, Fatal, Fatalf, SkipNow, Skip, or Skipf. Those methods, as well as the Parallel method, must be called only from the goroutine running the Test function. > > The other reporting methods, such as the variations of Log and Error, may be called simultaneously from multiple goroutines. There is a similar doc for [testing.B](https://tip.golang.org/pkg/testing/#B). I ask because I believe T.Run was safe for concurrent use in go 1.7. Then, [this line](https://github.com/golang/go/blob/7fb16406139e934d84f7ec66ba440a772747270a/src/testing/testing.go#L663) was added in go 1.8, which made T.Run no longer safe for concurrent use. I don't particularly care whether T.Run is safe for concurrent use, but I think the semantics should be clarified. Optimistically labeling this go1.8.",1,testing are t run and b run safe for concurrent use i do not see any documentation specifying if t run is safe for concurrent use i see the following doc for which does not mention t run a test ends when its test function returns or calls any of the methods failnow fatal fatalf skipnow skip or skipf those methods as well as the parallel method must be called only from the goroutine running the test function the other reporting methods such as the variations of log and error may be called simultaneously from multiple goroutines there is a similar doc for i ask because i believe t run was safe for concurrent use in go then was added in go which made t run no longer safe for concurrent use i don t particularly care whether t run is safe for concurrent use but i think the semantics should be clarified optimistically labeling this ,1 14587,3868544421.0,IssuesEvent,2016-04-10 01:07:41,golang/go,https://api.github.com/repos/golang/go,closed,x/exp/shiny: better examples UX,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go-1.6 2. What operating system and processor architecture are you using (`go env`)? linux/amd64 3. What did you do? ``` $> mkdir /tmp/gopath $> cd /tmp/gopath $> export GOPATH=/tmp/gopath $> go get -u golang.org/x/exp/shiny/screen/... $> cd $GOPATH/src/golang.org/x/exp/shiny/example/basic $> go run ./main.go ${GOPATH}/golang.org/x/exp/shiny/driver/internal/x11key/x11key.go:9:2: cannot find package ""golang.org/x/mobile/event/key"" in any of: ${GOPATH}/src/golang.org/x/exp/shiny/vendor/golang.org/x/mobile/event/key (vendor tree) /usr/local/go/src/golang.org/x/mobile/event/key (from $GOROOT) ${GOPATH}/src/golang.org/x/mobile/event/key (from $GOPATH) ${GOPATH}/src/golang.org/x/exp/shiny/driver/x11driver/window.go:25:2: cannot find package ""golang.org/x/mobile/event/lifecycle"" in any of: ${GOPATH}/src/golang.org/x/exp/shiny/vendor/golang.org/x/mobile/event/lifecycle (vendor tree) /usr/local/go/src/golang.org/x/mobile/event/lifecycle (from $GOROOT) ${GOPATH}/src/golang.org/x/mobile/event/lifecycle (from $GOPATH) ${GOPATH}/src/golang.org/x/exp/shiny/driver/x11driver/screen.go:20:2: cannot find package ""golang.org/x/mobile/event/mouse"" in any of: [...etc...] ``` 4. What did you expect to see? A nicer way to run the example(s) I would propose to: ``` $> cd $GOPATH/src/golang.org/x/exp/shiny $> git mv example _examples ``` and remove all the `// +build ignore` build tags from the examples, so one could at least do: ``` $> cd _examples/basic $> go get -d . ``` to download all the dependencies in one go. (I can send a CL) -s ",1.0,"x/exp/shiny: better examples UX - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go-1.6 2. What operating system and processor architecture are you using (`go env`)? linux/amd64 3. What did you do? ``` $> mkdir /tmp/gopath $> cd /tmp/gopath $> export GOPATH=/tmp/gopath $> go get -u golang.org/x/exp/shiny/screen/... $> cd $GOPATH/src/golang.org/x/exp/shiny/example/basic $> go run ./main.go ${GOPATH}/golang.org/x/exp/shiny/driver/internal/x11key/x11key.go:9:2: cannot find package ""golang.org/x/mobile/event/key"" in any of: ${GOPATH}/src/golang.org/x/exp/shiny/vendor/golang.org/x/mobile/event/key (vendor tree) /usr/local/go/src/golang.org/x/mobile/event/key (from $GOROOT) ${GOPATH}/src/golang.org/x/mobile/event/key (from $GOPATH) ${GOPATH}/src/golang.org/x/exp/shiny/driver/x11driver/window.go:25:2: cannot find package ""golang.org/x/mobile/event/lifecycle"" in any of: ${GOPATH}/src/golang.org/x/exp/shiny/vendor/golang.org/x/mobile/event/lifecycle (vendor tree) /usr/local/go/src/golang.org/x/mobile/event/lifecycle (from $GOROOT) ${GOPATH}/src/golang.org/x/mobile/event/lifecycle (from $GOPATH) ${GOPATH}/src/golang.org/x/exp/shiny/driver/x11driver/screen.go:20:2: cannot find package ""golang.org/x/mobile/event/mouse"" in any of: [...etc...] ``` 4. What did you expect to see? A nicer way to run the example(s) I would propose to: ``` $> cd $GOPATH/src/golang.org/x/exp/shiny $> git mv example _examples ``` and remove all the `// +build ignore` build tags from the examples, so one could at least do: ``` $> cd _examples/basic $> go get -d . ``` to download all the dependencies in one go. (I can send a CL) -s ",1,x exp shiny better examples ux please answer these questions before submitting your issue thanks what version of go are you using go version go what operating system and processor architecture are you using go env linux what did you do mkdir tmp gopath cd tmp gopath export gopath tmp gopath go get u golang org x exp shiny screen cd gopath src golang org x exp shiny example basic go run main go gopath golang org x exp shiny driver internal go cannot find package golang org x mobile event key in any of gopath src golang org x exp shiny vendor golang org x mobile event key vendor tree usr local go src golang org x mobile event key from goroot gopath src golang org x mobile event key from gopath gopath src golang org x exp shiny driver window go cannot find package golang org x mobile event lifecycle in any of gopath src golang org x exp shiny vendor golang org x mobile event lifecycle vendor tree usr local go src golang org x mobile event lifecycle from goroot gopath src golang org x mobile event lifecycle from gopath gopath src golang org x exp shiny driver screen go cannot find package golang org x mobile event mouse in any of what did you expect to see a nicer way to run the example s i would propose to cd gopath src golang org x exp shiny git mv example examples and remove all the build ignore build tags from the examples so one could at least do cd examples basic go get d to download all the dependencies in one go i can send a cl s ,1 46707,11872672939.0,IssuesEvent,2020-03-26 16:09:15,golang/go,https://api.github.com/repos/golang/go,closed,x/build/dashboard: macOS builders should specify filesystem case sensitivity in Notes field,Builders NeedsFix,"It should be easy to find out whether the filesystem is case sensitive or insensitive (macOS offers both options). We can put this information in the [`Notes`](https://github.com/golang/build/blob/2bf41cd70ade4691877019a878f4ad34d42be1b5/dashboard/builders.go#L732) field, so it'll show up at https://farmer.golang.org/builders. /cc @cagedmantis @toothrot @heschik",1.0,"x/build/dashboard: macOS builders should specify filesystem case sensitivity in Notes field - It should be easy to find out whether the filesystem is case sensitive or insensitive (macOS offers both options). We can put this information in the [`Notes`](https://github.com/golang/build/blob/2bf41cd70ade4691877019a878f4ad34d42be1b5/dashboard/builders.go#L732) field, so it'll show up at https://farmer.golang.org/builders. /cc @cagedmantis @toothrot @heschik",0,x build dashboard macos builders should specify filesystem case sensitivity in notes field it should be easy to find out whether the filesystem is case sensitive or insensitive macos offers both options we can put this information in the field so it ll show up at cc cagedmantis toothrot heschik,0 436681,30564976848.0,IssuesEvent,2023-07-20 17:03:55,golang/go,https://api.github.com/repos/golang/go,closed,net/url: better handling or documentation of IPv6 addresses in url.URL.Host,Documentation NeedsDecision,"### What did you do? https://go.dev/play/p/Lypv_o9VMRf host := ""fc00::121:0:2:27"" url := url.URL{ Scheme: ""https"", Host: host, Path: ""/some/path"", } fmt.Println(url.String()) ### What did you expect to see? `https://[fc00::121:0:2:27]/some/path` ### What did you see instead? `https://fc00::121:0:2:27/some/path` This ends up being interpreted as `https://[fc00::121:0:2]:27/some/path`. The documentation for `url.URL.Host` is `host or host:port`, which leaves it unclear as to how a literal IPv6 address would be treated. I think it makes more sense to treat a literal IPv6 address as just that, and require the user to specify `[]:` if that's what they actually wanted, though I appreciate that there would be backward compatibility issues with that. So at this point, it's probably best to just clarify the docs and add a reference to `net.JoinHostPort`. This could perhaps be done via #61093.",1.0,"net/url: better handling or documentation of IPv6 addresses in url.URL.Host - ### What did you do? https://go.dev/play/p/Lypv_o9VMRf host := ""fc00::121:0:2:27"" url := url.URL{ Scheme: ""https"", Host: host, Path: ""/some/path"", } fmt.Println(url.String()) ### What did you expect to see? `https://[fc00::121:0:2:27]/some/path` ### What did you see instead? `https://fc00::121:0:2:27/some/path` This ends up being interpreted as `https://[fc00::121:0:2]:27/some/path`. The documentation for `url.URL.Host` is `host or host:port`, which leaves it unclear as to how a literal IPv6 address would be treated. I think it makes more sense to treat a literal IPv6 address as just that, and require the user to specify `[]:` if that's what they actually wanted, though I appreciate that there would be backward compatibility issues with that. So at this point, it's probably best to just clarify the docs and add a reference to `net.JoinHostPort`. This could perhaps be done via #61093.",1,net url better handling or documentation of addresses in url url host what did you do host url url url scheme https host host path some path fmt println url string what did you expect to see https some path what did you see instead this ends up being interpreted as https some path the documentation for url url host is host or host port which leaves it unclear as to how a literal address would be treated i think it makes more sense to treat a literal address as just that and require the user to specify if that s what they actually wanted though i appreciate that there would be backward compatibility issues with that so at this point it s probably best to just clarify the docs and add a reference to net joinhostport this could perhaps be done via ,1 74,2492966558.0,IssuesEvent,2015-01-05 09:12:09,golang/go,https://api.github.com/repos/golang/go,closed,reflect: Value's == behavior changed between 1.3 and 1.4,documentation repo-main,"the following code snippet has different behavior when I run it on 1.3 and 1.4 respectively. code are in https://play.golang.org/p/yfy7ZKqU1Y when I run on 1.3, we have the following response: ``` false 0 0x0 true ``` while, It report false in the last println in golang 1.4 ``` false 0 0x0 false ``` not sure whether it is a bug or something",1.0,"reflect: Value's == behavior changed between 1.3 and 1.4 - the following code snippet has different behavior when I run it on 1.3 and 1.4 respectively. code are in https://play.golang.org/p/yfy7ZKqU1Y when I run on 1.3, we have the following response: ``` false 0 0x0 true ``` while, It report false in the last println in golang 1.4 ``` false 0 0x0 false ``` not sure whether it is a bug or something",1,reflect value s behavior changed between and the following code snippet has different behavior when i run it on and respectively code are in when i run on we have the following response false true while it report false in the last println in golang false false not sure whether it is a bug or something,1 10742,7300507642.0,IssuesEvent,2018-02-27 00:04:04,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: address calculation before write barrier check,Performance,"``` type T struct { a, b *int } func f(p *T, q *int) { p.b = q } ``` Compiles to ``` 0x001d 00029 (/Users/khr/go/tmp1.go:8) MOVQ """".p+32(SP), AX 0x0022 00034 (/Users/khr/go/tmp1.go:8) TESTB AL, (AX) 0x0024 00036 (/Users/khr/go/tmp1.go:8) MOVL runtime.writeBarrier(SB), CX 0x002a 00042 (/Users/khr/go/tmp1.go:8) LEAQ 8(AX), DX 0x002e 00046 (/Users/khr/go/tmp1.go:8) TESTL CX, CX 0x0030 00048 (/Users/khr/go/tmp1.go:8) JNE 69 0x0032 00050 (/Users/khr/go/tmp1.go:8) MOVQ """".q+40(SP), CX 0x0037 00055 (/Users/khr/go/tmp1.go:8) MOVQ CX, 8(AX) 0x003b 00059 (/Users/khr/go/tmp1.go:9) MOVQ 16(SP), BP 0x0040 00064 (/Users/khr/go/tmp1.go:9) ADDQ $24, SP 0x0044 00068 (/Users/khr/go/tmp1.go:9) RET 0x0045 00069 (/Users/khr/go/tmp1.go:8) MOVQ DX, (SP) 0x0049 00073 (/Users/khr/go/tmp1.go:8) MOVQ """".q+40(SP), AX 0x004e 00078 (/Users/khr/go/tmp1.go:8) MOVQ AX, 8(SP) 0x0053 00083 (/Users/khr/go/tmp1.go:8) PCDATA $0, $1 0x0053 00083 (/Users/khr/go/tmp1.go:8) CALL runtime.writebarrierptr(SB) 0x0058 00088 (/Users/khr/go/tmp1.go:8) JMP 59 ``` Note the LEAQ instruction at offset 42. It is only used by the store at offset 69. We should move it to just before 69 so it only has to execute if write barriers are on. The tighten pass is responsible for this kind of move, but unfortunately it runs before lowering. Before lowering there is a use of the LEAQ (at that time, an OffPtr) on both sides of the branch. It is used by the non-write-barrier store, but that use goes away during lowering because the OffPtr gets folded into the store. Another tighten run after lowering would fix this, but that's an awfully big hammer.",True,"cmd/compile: address calculation before write barrier check - ``` type T struct { a, b *int } func f(p *T, q *int) { p.b = q } ``` Compiles to ``` 0x001d 00029 (/Users/khr/go/tmp1.go:8) MOVQ """".p+32(SP), AX 0x0022 00034 (/Users/khr/go/tmp1.go:8) TESTB AL, (AX) 0x0024 00036 (/Users/khr/go/tmp1.go:8) MOVL runtime.writeBarrier(SB), CX 0x002a 00042 (/Users/khr/go/tmp1.go:8) LEAQ 8(AX), DX 0x002e 00046 (/Users/khr/go/tmp1.go:8) TESTL CX, CX 0x0030 00048 (/Users/khr/go/tmp1.go:8) JNE 69 0x0032 00050 (/Users/khr/go/tmp1.go:8) MOVQ """".q+40(SP), CX 0x0037 00055 (/Users/khr/go/tmp1.go:8) MOVQ CX, 8(AX) 0x003b 00059 (/Users/khr/go/tmp1.go:9) MOVQ 16(SP), BP 0x0040 00064 (/Users/khr/go/tmp1.go:9) ADDQ $24, SP 0x0044 00068 (/Users/khr/go/tmp1.go:9) RET 0x0045 00069 (/Users/khr/go/tmp1.go:8) MOVQ DX, (SP) 0x0049 00073 (/Users/khr/go/tmp1.go:8) MOVQ """".q+40(SP), AX 0x004e 00078 (/Users/khr/go/tmp1.go:8) MOVQ AX, 8(SP) 0x0053 00083 (/Users/khr/go/tmp1.go:8) PCDATA $0, $1 0x0053 00083 (/Users/khr/go/tmp1.go:8) CALL runtime.writebarrierptr(SB) 0x0058 00088 (/Users/khr/go/tmp1.go:8) JMP 59 ``` Note the LEAQ instruction at offset 42. It is only used by the store at offset 69. We should move it to just before 69 so it only has to execute if write barriers are on. The tighten pass is responsible for this kind of move, but unfortunately it runs before lowering. Before lowering there is a use of the LEAQ (at that time, an OffPtr) on both sides of the branch. It is used by the non-write-barrier store, but that use goes away during lowering because the OffPtr gets folded into the store. Another tighten run after lowering would fix this, but that's an awfully big hammer.",0,cmd compile address calculation before write barrier check type t struct a b int func f p t q int p b q compiles to users khr go go movq p sp ax users khr go go testb al ax users khr go go movl runtime writebarrier sb cx users khr go go leaq ax dx users khr go go testl cx cx users khr go go jne users khr go go movq q sp cx users khr go go movq cx ax users khr go go movq sp bp users khr go go addq sp users khr go go ret users khr go go movq dx sp users khr go go movq q sp ax users khr go go movq ax sp users khr go go pcdata users khr go go call runtime writebarrierptr sb users khr go go jmp note the leaq instruction at offset it is only used by the store at offset we should move it to just before so it only has to execute if write barriers are on the tighten pass is responsible for this kind of move but unfortunately it runs before lowering before lowering there is a use of the leaq at that time an offptr on both sides of the branch it is used by the non write barrier store but that use goes away during lowering because the offptr gets folded into the store another tighten run after lowering would fix this but that s an awfully big hammer ,0 43962,23442649715.0,IssuesEvent,2022-08-15 16:20:19,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: missing combine constant store cases on amd64,Performance NeedsInvestigation FeatureRequest compiler/runtime,"### What version of Go are you using (`go version`)? gotip ### What did you do? ```go func a(b []byte, idx int) { binary.LittleEndian.PutUint64(b[idx:], 123) } ``` ### What did you expect to see? ```asm MOVQ $123, (AX)(DX*1) ``` ### What did you see instead? ```asm MOVB $123, (AX)(DI*1) MOVB $0, 1(AX)(DI*1) MOVB $0, 2(AX)(DI*1) MOVB $0, 3(AX)(DI*1) MOVB $0, 4(AX)(DI*1) MOVB $0, 5(AX)(DI*1) MOVB $0, 6(AX)(DI*1) MOVB $0, 7(AX)(DI*1) ``` ",True,"cmd/compile: missing combine constant store cases on amd64 - ### What version of Go are you using (`go version`)? gotip ### What did you do? ```go func a(b []byte, idx int) { binary.LittleEndian.PutUint64(b[idx:], 123) } ``` ### What did you expect to see? ```asm MOVQ $123, (AX)(DX*1) ``` ### What did you see instead? ```asm MOVB $123, (AX)(DI*1) MOVB $0, 1(AX)(DI*1) MOVB $0, 2(AX)(DI*1) MOVB $0, 3(AX)(DI*1) MOVB $0, 4(AX)(DI*1) MOVB $0, 5(AX)(DI*1) MOVB $0, 6(AX)(DI*1) MOVB $0, 7(AX)(DI*1) ``` ",0,cmd compile missing combine constant store cases on what version of go are you using go version gotip what did you do go func a b byte idx int binary littleendian b what did you expect to see asm movq ax dx what did you see instead asm movb ax di movb ax di movb ax di movb ax di movb ax di movb ax di movb ax di movb ax di ,0 366626,25594575526.0,IssuesEvent,2022-12-01 15:18:24,golang/go,https://api.github.com/repos/golang/go,closed,docs: go fuzzing docs in go.dev blog,Documentation,"Hey, everyone! I read the [article](https://go.dev/security/fuzz/) in DARK mode about go fuzzing. I guess, source code by black font on grey background look awful. Please, fix it ",1.0,"docs: go fuzzing docs in go.dev blog - Hey, everyone! I read the [article](https://go.dev/security/fuzz/) in DARK mode about go fuzzing. I guess, source code by black font on grey background look awful. Please, fix it ",1,docs go fuzzing docs in go dev blog hey everyone i read the in dark mode about go fuzzing i guess source code by black font on grey background look awful please fix it ,1 173132,14403475916.0,IssuesEvent,2020-12-03 16:06:10,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document mime/multipart changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
mime/multipart

TODO: https://golang.org/cl/247477: return overflow errors in Reader.ReadForm

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document mime/multipart changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
mime/multipart

TODO: https://golang.org/cl/247477: return overflow errors in Reader.ReadForm

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document mime multipart changes for go as of filing this issue the contained the following html mime multipart todo a href return overflow errors in reader readform per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 23737,4971681206.0,IssuesEvent,2016-12-05 19:23:49,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/compile: mips: document requirements, Illegal instruction on mips router: GL-AR300M and GL-AR150",Documentation NeedsFix,"### What version of Go are you using (`go version`)? ``` go version go1.8beta1 windows/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? Building on `windows-amd64` for `linux-mips`. ``` set GOARCH=mips set GOBIN= set GOEXE= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=linux set GOPATH=C:\Users\cetin\go set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-fPIC -fmessage-length=0 set CXX=g++ set CGO_ENABLED=0 set PKG_CONFIG=pkg-config set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 ``` ### What did you do? Windows PC (`cmd.exe`): ``` set GOOS=linux&&set GOARCH=mips&&go build ``` MIPS Router: ``` ./hello Illegal instruction ``` ### What did you expect to see? ``` Hello world! ``` ### What did you see instead? ``` Illegal instruction ``` --- What kind of hardware products does the recent mips support merge target then?",1.0,"cmd/compile: mips: document requirements, Illegal instruction on mips router: GL-AR300M and GL-AR150 - ### What version of Go are you using (`go version`)? ``` go version go1.8beta1 windows/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? Building on `windows-amd64` for `linux-mips`. ``` set GOARCH=mips set GOBIN= set GOEXE= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=linux set GOPATH=C:\Users\cetin\go set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-fPIC -fmessage-length=0 set CXX=g++ set CGO_ENABLED=0 set PKG_CONFIG=pkg-config set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 ``` ### What did you do? Windows PC (`cmd.exe`): ``` set GOOS=linux&&set GOARCH=mips&&go build ``` MIPS Router: ``` ./hello Illegal instruction ``` ### What did you expect to see? ``` Hello world! ``` ### What did you see instead? ``` Illegal instruction ``` --- What kind of hardware products does the recent mips support merge target then?",1,cmd compile mips document requirements illegal instruction on mips router gl and gl what version of go are you using go version go version windows what operating system and processor architecture are you using go env building on windows for linux mips set goarch mips set gobin set goexe set gohostarch set gohostos windows set goos linux set gopath c users cetin go set gorace set goroot c go set gotooldir c go pkg tool windows set gccgo gccgo set cc gcc set gogccflags fpic fmessage length set cxx g set cgo enabled set pkg config pkg config set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g what did you do windows pc cmd exe set goos linux set goarch mips go build mips router hello illegal instruction what did you expect to see hello world what did you see instead illegal instruction what kind of hardware products does the recent mips support merge target then ,1 53614,28313213949.0,IssuesEvent,2023-04-10 17:14:56,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: unneccesary 0 check in division,Performance help wanted NeedsFix compiler/runtime," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
### Does this issue reproduce with the latest release? AFAIK I run the latest, havnt tried on tip. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/jaap/.cache/go-build""
GOENV=""/home/jaap/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/jaap/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/jaap/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.3""
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-build3803926857=/tmp/go-build -gno-record-gcc-switches""
### What did you do? ``` $ cat main.go package A func DivPositSameES(x uint32) { combinedFrac := (x) / (x | (1 << 31)) println(combinedFrac) } $ go tool compile -S main.go """".DivPositSameES STEXT size=110 args=0x8 locals=0x18 funcid=0x0 0x0000 00000 (main.go:3) TEXT """".DivPositSameES(SB), ABIInternal, $24-8 0x0000 00000 (main.go:3) MOVQ (TLS), CX 0x0009 00009 (main.go:3) CMPQ SP, 16(CX) 0x000d 00013 (main.go:3) PCDATA $0, $-2 0x000d 00013 (main.go:3) JLS 103 0x000f 00015 (main.go:3) PCDATA $0, $-1 0x000f 00015 (main.go:3) SUBQ $24, SP 0x0013 00019 (main.go:3) MOVQ BP, 16(SP) 0x0018 00024 (main.go:3) LEAQ 16(SP), BP 0x001d 00029 (main.go:3) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x001d 00029 (main.go:3) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x001d 00029 (main.go:4) MOVL """".x+32(SP), AX 0x0021 00033 (main.go:4) MOVL AX, CX 0x0023 00035 (main.go:4) BTSL $31, AX 0x0027 00039 (main.go:4) TESTL AX, AX 0x0029 00041 (main.go:4) JEQ 97 0x002b 00043 (main.go:4) MOVL AX, DX 0x002d 00045 (main.go:4) MOVL CX, AX 0x002f 00047 (main.go:4) MOVL DX, BX 0x0031 00049 (main.go:4) XORL DX, DX 0x0033 00051 (main.go:4) DIVL BX 0x0035 00053 (main.go:4) MOVL AX, """".combinedFrac+12(SP) 0x0039 00057 (main.go:5) PCDATA $1, $0 0x0039 00057 (main.go:5) CALL runtime.printlock(SB) 0x003e 00062 (main.go:5) MOVL """".combinedFrac+12(SP), CX 0x0042 00066 (main.go:5) MOVL CX, CX 0x0044 00068 (main.go:5) MOVQ CX, (SP) 0x0048 00072 (main.go:5) CALL runtime.printuint(SB) 0x004d 00077 (main.go:5) CALL runtime.printnl(SB) 0x0052 00082 (main.go:5) CALL runtime.printunlock(SB) 0x0057 00087 (main.go:6) MOVQ 16(SP), BP 0x005c 00092 (main.go:6) ADDQ $24, SP 0x0060 00096 (main.go:6) RET 0x0061 00097 (main.go:4) CALL runtime.panicdivide(SB) 0x0066 00102 (main.go:4) XCHGL AX, AX 0x0067 00103 (main.go:4) NOP 0x0067 00103 (main.go:3) PCDATA $1, $-1 0x0067 00103 (main.go:3) PCDATA $0, $-2 0x0067 00103 (main.go:3) CALL runtime.morestack_noctxt(SB) 0x006c 00108 (main.go:3) PCDATA $0, $-1 0x006c 00108 (main.go:3) JMP 0 0x0000 64 48 8b 0c 25 00 00 00 00 48 3b 61 10 76 58 48 dH..%....H;a.vXH 0x0010 83 ec 18 48 89 6c 24 10 48 8d 6c 24 10 8b 44 24 ...H.l$.H.l$..D$ 0x0020 20 89 c1 0f ba e8 1f 85 c0 74 36 89 c2 89 c8 89 ........t6..... 0x0030 d3 31 d2 f7 f3 89 44 24 0c e8 00 00 00 00 8b 4c .1....D$.......L 0x0040 24 0c 89 c9 48 89 0c 24 e8 00 00 00 00 e8 00 00 $...H..$........ 0x0050 00 00 e8 00 00 00 00 48 8b 6c 24 10 48 83 c4 18 .......H.l$.H... 0x0060 c3 e8 00 00 00 00 90 e8 00 00 00 00 eb 92 .............. rel 5+4 t=17 TLS+0 rel 58+4 t=8 runtime.printlock+0 rel 73+4 t=8 runtime.printuint+0 rel 78+4 t=8 runtime.printnl+0 rel 83+4 t=8 runtime.printunlock+0 rel 98+4 t=8 runtime.panicdivide+0 rel 104+4 t=8 runtime.morestack_noctxt+0 go.cuinfo.packagename. SDWARFCUINFO dupok size=0 0x0000 41 A gclocals·33cdeccccebe80329f1fdbee7f5874cb SRODATA dupok size=8 0x0000 01 00 00 00 00 00 00 00 ........ ``` ### What did you expect to see? I expected the compiler to be smart enough to know that `x | (1 << 31)` would never be 0, as it should be quite obvious. ### What did you see instead? Most notibly: ``` 0x0027 00039 (main.go:4) TESTL AX, AX 0x0029 00041 (main.go:4) JEQ 97 ``` This is a 0 check that I did not expect to see. It sounds quite plausible to me that the compiler only checks for non-0 constants to remove this check. I think that when it is so explicitly not 0, the compiler should be able to figure this one out.",True,"cmd/compile: unneccesary 0 check in division - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
### Does this issue reproduce with the latest release? AFAIK I run the latest, havnt tried on tip. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/jaap/.cache/go-build""
GOENV=""/home/jaap/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/jaap/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/jaap/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.3""
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-build3803926857=/tmp/go-build -gno-record-gcc-switches""
### What did you do? ``` $ cat main.go package A func DivPositSameES(x uint32) { combinedFrac := (x) / (x | (1 << 31)) println(combinedFrac) } $ go tool compile -S main.go """".DivPositSameES STEXT size=110 args=0x8 locals=0x18 funcid=0x0 0x0000 00000 (main.go:3) TEXT """".DivPositSameES(SB), ABIInternal, $24-8 0x0000 00000 (main.go:3) MOVQ (TLS), CX 0x0009 00009 (main.go:3) CMPQ SP, 16(CX) 0x000d 00013 (main.go:3) PCDATA $0, $-2 0x000d 00013 (main.go:3) JLS 103 0x000f 00015 (main.go:3) PCDATA $0, $-1 0x000f 00015 (main.go:3) SUBQ $24, SP 0x0013 00019 (main.go:3) MOVQ BP, 16(SP) 0x0018 00024 (main.go:3) LEAQ 16(SP), BP 0x001d 00029 (main.go:3) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x001d 00029 (main.go:3) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x001d 00029 (main.go:4) MOVL """".x+32(SP), AX 0x0021 00033 (main.go:4) MOVL AX, CX 0x0023 00035 (main.go:4) BTSL $31, AX 0x0027 00039 (main.go:4) TESTL AX, AX 0x0029 00041 (main.go:4) JEQ 97 0x002b 00043 (main.go:4) MOVL AX, DX 0x002d 00045 (main.go:4) MOVL CX, AX 0x002f 00047 (main.go:4) MOVL DX, BX 0x0031 00049 (main.go:4) XORL DX, DX 0x0033 00051 (main.go:4) DIVL BX 0x0035 00053 (main.go:4) MOVL AX, """".combinedFrac+12(SP) 0x0039 00057 (main.go:5) PCDATA $1, $0 0x0039 00057 (main.go:5) CALL runtime.printlock(SB) 0x003e 00062 (main.go:5) MOVL """".combinedFrac+12(SP), CX 0x0042 00066 (main.go:5) MOVL CX, CX 0x0044 00068 (main.go:5) MOVQ CX, (SP) 0x0048 00072 (main.go:5) CALL runtime.printuint(SB) 0x004d 00077 (main.go:5) CALL runtime.printnl(SB) 0x0052 00082 (main.go:5) CALL runtime.printunlock(SB) 0x0057 00087 (main.go:6) MOVQ 16(SP), BP 0x005c 00092 (main.go:6) ADDQ $24, SP 0x0060 00096 (main.go:6) RET 0x0061 00097 (main.go:4) CALL runtime.panicdivide(SB) 0x0066 00102 (main.go:4) XCHGL AX, AX 0x0067 00103 (main.go:4) NOP 0x0067 00103 (main.go:3) PCDATA $1, $-1 0x0067 00103 (main.go:3) PCDATA $0, $-2 0x0067 00103 (main.go:3) CALL runtime.morestack_noctxt(SB) 0x006c 00108 (main.go:3) PCDATA $0, $-1 0x006c 00108 (main.go:3) JMP 0 0x0000 64 48 8b 0c 25 00 00 00 00 48 3b 61 10 76 58 48 dH..%....H;a.vXH 0x0010 83 ec 18 48 89 6c 24 10 48 8d 6c 24 10 8b 44 24 ...H.l$.H.l$..D$ 0x0020 20 89 c1 0f ba e8 1f 85 c0 74 36 89 c2 89 c8 89 ........t6..... 0x0030 d3 31 d2 f7 f3 89 44 24 0c e8 00 00 00 00 8b 4c .1....D$.......L 0x0040 24 0c 89 c9 48 89 0c 24 e8 00 00 00 00 e8 00 00 $...H..$........ 0x0050 00 00 e8 00 00 00 00 48 8b 6c 24 10 48 83 c4 18 .......H.l$.H... 0x0060 c3 e8 00 00 00 00 90 e8 00 00 00 00 eb 92 .............. rel 5+4 t=17 TLS+0 rel 58+4 t=8 runtime.printlock+0 rel 73+4 t=8 runtime.printuint+0 rel 78+4 t=8 runtime.printnl+0 rel 83+4 t=8 runtime.printunlock+0 rel 98+4 t=8 runtime.panicdivide+0 rel 104+4 t=8 runtime.morestack_noctxt+0 go.cuinfo.packagename. SDWARFCUINFO dupok size=0 0x0000 41 A gclocals·33cdeccccebe80329f1fdbee7f5874cb SRODATA dupok size=8 0x0000 01 00 00 00 00 00 00 00 ........ ``` ### What did you expect to see? I expected the compiler to be smart enough to know that `x | (1 << 31)` would never be 0, as it should be quite obvious. ### What did you see instead? Most notibly: ``` 0x0027 00039 (main.go:4) TESTL AX, AX 0x0029 00041 (main.go:4) JEQ 97 ``` This is a 0 check that I did not expect to see. It sounds quite plausible to me that the compiler only checks for non-0 constants to remove this check. I think that when it is so explicitly not 0, the compiler should be able to figure this one out.",0,cmd compile unneccesary check in division please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release afaik i run the latest havnt tried on tip what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home jaap cache go build goenv home jaap config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home jaap go pkg mod gonoproxy gonosumdb goos linux gopath home jaap go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do cat main go package a func divpositsamees x combinedfrac x x println combinedfrac go tool compile s main go divpositsamees stext size args locals funcid main go text divpositsamees sb abiinternal main go movq tls cx main go cmpq sp cx main go pcdata main go jls main go pcdata main go subq sp main go movq bp sp main go leaq sp bp main go funcdata gclocals· sb main go funcdata gclocals· sb main go movl x sp ax main go movl ax cx main go btsl ax main go testl ax ax main go jeq main go movl ax dx main go movl cx ax main go movl dx bx main go xorl dx dx main go divl bx main go movl ax combinedfrac sp main go pcdata main go call runtime printlock sb main go movl combinedfrac sp cx main go movl cx cx main go movq cx sp main go call runtime printuint sb main go call runtime printnl sb main go call runtime printunlock sb main go movq sp bp main go addq sp main go ret main go call runtime panicdivide sb main go xchgl ax ax main go nop main go pcdata main go pcdata main go call runtime morestack noctxt sb main go pcdata main go jmp dh h a vxh ec h l h l d ba d l h h l h eb rel t tls rel t runtime printlock rel t runtime printuint rel t runtime printnl rel t runtime printunlock rel t runtime panicdivide rel t runtime morestack noctxt go cuinfo packagename sdwarfcuinfo dupok size a gclocals· srodata dupok size what did you expect to see i expected the compiler to be smart enough to know that x would never be as it should be quite obvious what did you see instead most notibly main go testl ax ax main go jeq this is a check that i did not expect to see it sounds quite plausible to me that the compiler only checks for non constants to remove this check i think that when it is so explicitly not the compiler should be able to figure this one out ,0 8571,6574519704.0,IssuesEvent,2017-09-11 13:11:36,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: do more optimizations for ARMv6/V7,Performance,"More ARMv6 & ARMv7 instructions are already merged into branch master. The compiler can use them to do further optimization. Such as (Mul16 x y) -> (MULBB x y) (ADD z (MULBB x y) -> MULABB(x y z) (SUB x (MUL y z) -> MULS(x y z) and so on. I have prepared a optimization CL for all these MULA like instructions. But the final form depends on how issue #19141 is fixed. ",True,"cmd/compile: do more optimizations for ARMv6/V7 - More ARMv6 & ARMv7 instructions are already merged into branch master. The compiler can use them to do further optimization. Such as (Mul16 x y) -> (MULBB x y) (ADD z (MULBB x y) -> MULABB(x y z) (SUB x (MUL y z) -> MULS(x y z) and so on. I have prepared a optimization CL for all these MULA like instructions. But the final form depends on how issue #19141 is fixed. ",0,cmd compile do more optimizations for more instructions are already merged into branch master the compiler can use them to do further optimization such as x y mulbb x y add z mulbb x y mulabb x y z sub x mul y z muls x y z and so on i have prepared a optimization cl for all these mula like instructions but the final form depends on how issue is fixed ,0 52069,7746121957.0,IssuesEvent,2018-05-29 20:36:54,golang/go,https://api.github.com/repos/golang/go,closed,net/http: Closing Hijacked Conn doesn't cancel Request Context,Documentation NeedsFix,"After a server Handler Hijacks and returns the underlying net.Conn, I'd expect the Handler's Request.Context to be Done when that Conn is closed. It appears that the Context is Done when the original handler routine returns, but closing the Conn after a Hijack no longer triggers it too. Here's a test demonstrating it. It gets stuck at the linked line. https://github.com/anacrolix/wat/blob/master/http_test.go#L63 $ go version go version devel +2da8a16cbc Thu Oct 19 23:34:02 2017 +0000 darwin/amd64",1.0,"net/http: Closing Hijacked Conn doesn't cancel Request Context - After a server Handler Hijacks and returns the underlying net.Conn, I'd expect the Handler's Request.Context to be Done when that Conn is closed. It appears that the Context is Done when the original handler routine returns, but closing the Conn after a Hijack no longer triggers it too. Here's a test demonstrating it. It gets stuck at the linked line. https://github.com/anacrolix/wat/blob/master/http_test.go#L63 $ go version go version devel +2da8a16cbc Thu Oct 19 23:34:02 2017 +0000 darwin/amd64",1,net http closing hijacked conn doesn t cancel request context after a server handler hijacks and returns the underlying net conn i d expect the handler s request context to be done when that conn is closed it appears that the context is done when the original handler routine returns but closing the conn after a hijack no longer triggers it too here s a test demonstrating it it gets stuck at the linked line go version go version devel thu oct darwin ,1 14191,9212839862.0,IssuesEvent,2019-03-10 05:40:59,golang/go,https://api.github.com/repos/golang/go,closed,runtime: Windows DLL preloading attack possible for winmm.dll,NeedsInvestigation OS-Windows Security,"Go 1.11 seems vulnerable to dll preloading on windows with `winmm.dll`. It looks like #14959 mostly fixed this, `kernel32.dll` etc are protected, but `winmm.dll` still seems to be affected. It seems to be loaded implicitly by the go runtime — https://github.com/golang/go/blob/6174b5e21e73714c63061e66efdbe180e1c5491d/src/pkg/runtime/thread_windows.c#L31 — but I notice is not listed with the other safely loaded DLLs — https://github.com/golang/go/blob/6174b5e21e73714c63061e66efdbe180e1c5491d/src/pkg/syscall/zsyscall_windows_amd64.go#L9-L19 ### What version of Go are you using (`go version`)? 
$ docker run --rm golang:1.11 go version
go version go1.11.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ docker run --rm golang:1.11 go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/root/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build782466443=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. Create a `main.go` with: ``` package main import ""fmt"" func main() { fmt.Println(""Hello world"") } ``` 1. Cross-compile for windows: ``` docker run -v $PWD:/go -e GOARCH=amd64 -e GOOS=windows --rm golang:1.11 go build -o test.exe main.go ``` 1. Copy `test.exe` to a windows vm 1. Add a `winmm.dll` beside `test.exe` with contents `not a dll` 1. Double click `test.exe` ### What did you expect to see? ""Hello world"" ### What did you see instead? ",True,"runtime: Windows DLL preloading attack possible for winmm.dll - Go 1.11 seems vulnerable to dll preloading on windows with `winmm.dll`. It looks like #14959 mostly fixed this, `kernel32.dll` etc are protected, but `winmm.dll` still seems to be affected. It seems to be loaded implicitly by the go runtime — https://github.com/golang/go/blob/6174b5e21e73714c63061e66efdbe180e1c5491d/src/pkg/runtime/thread_windows.c#L31 — but I notice is not listed with the other safely loaded DLLs — https://github.com/golang/go/blob/6174b5e21e73714c63061e66efdbe180e1c5491d/src/pkg/syscall/zsyscall_windows_amd64.go#L9-L19 ### What version of Go are you using (`go version`)? 
$ docker run --rm golang:1.11 go version
go version go1.11.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ docker run --rm golang:1.11 go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/root/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build782466443=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. Create a `main.go` with: ``` package main import ""fmt"" func main() { fmt.Println(""Hello world"") } ``` 1. Cross-compile for windows: ``` docker run -v $PWD:/go -e GOARCH=amd64 -e GOOS=windows --rm golang:1.11 go build -o test.exe main.go ``` 1. Copy `test.exe` to a windows vm 1. Add a `winmm.dll` beside `test.exe` with contents `not a dll` 1. Double click `test.exe` ### What did you expect to see? ""Hello world"" ### What did you see instead? ",0,runtime windows dll preloading attack possible for winmm dll go seems vulnerable to dll preloading on windows with winmm dll it looks like mostly fixed this dll etc are protected but winmm dll still seems to be affected it seems to be loaded implicitly by the go runtime — — but i notice is not listed with the other safely loaded dlls —  what version of go are you using go version docker run rm golang go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output docker run rm golang go env goarch gobin gocache root cache go build goexe goflags gohostarch gohostos linux goos linux gopath go goproxy gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do create a main go with package main import fmt func main fmt println hello world cross compile for windows docker run v pwd go e goarch e goos windows rm golang go build o test exe main go copy test exe to a windows vm add a winmm dll beside test exe with contents not a dll double click test exe what did you expect to see hello world what did you see instead img width alt screen shot at am src ,0 109934,11671523477.0,IssuesEvent,2020-03-04 03:29:24,golang/go,https://api.github.com/repos/golang/go,closed,doc: About Golang memory model-The loop in main is not guaranteed to finish.,Documentation,"> Another incorrect idiom is busy waiting for a value, as in: > ``` var a string var done bool func setup() { a = ""hello, world"" done = true } func main() { go setup() for !done { } print(a) } ``` > As before, there is no guarantee that, in main, observing the write to done implies observing the write to a, so this program could print an empty string too. Worse, there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish. > this code from https://golang.org/ref/mem#tmp_2 what is mean The loop in main is not guaranteed to finish？is only happens on single core cpu or all mulit core cpus. I run test on it，the main is all always finish。",1.0,"doc: About Golang memory model-The loop in main is not guaranteed to finish. - > Another incorrect idiom is busy waiting for a value, as in: > ``` var a string var done bool func setup() { a = ""hello, world"" done = true } func main() { go setup() for !done { } print(a) } ``` > As before, there is no guarantee that, in main, observing the write to done implies observing the write to a, so this program could print an empty string too. Worse, there is no guarantee that the write to done will ever be observed by main, since there are no synchronization events between the two threads. The loop in main is not guaranteed to finish. > this code from https://golang.org/ref/mem#tmp_2 what is mean The loop in main is not guaranteed to finish？is only happens on single core cpu or all mulit core cpus. I run test on it，the main is all always finish。",1,doc about golang memory model the loop in main is not guaranteed to finish another incorrect idiom is busy waiting for a value as in var a string var done bool func setup a hello world done true func main go setup for done print a as before there is no guarantee that in main observing the write to done implies observing the write to a so this program could print an empty string too worse there is no guarantee that the write to done will ever be observed by main since there are no synchronization events between the two threads the loop in main is not guaranteed to finish this code from what is mean the loop in main is not guaranteed to finish？is only happens on single core cpu or all mulit core cpus i run test on it，the main is all always finish。,1 32094,6031807615.0,IssuesEvent,2017-06-09 00:41:28,golang/go,https://api.github.com/repos/golang/go,opened,net/http: document SOCKS5 proxy support,Documentation,SOCKS5 proxy support was added by https://golang.org/cl/35488. Documentation should be added to net/http.,1.0,net/http: document SOCKS5 proxy support - SOCKS5 proxy support was added by https://golang.org/cl/35488. Documentation should be added to net/http.,1,net http document proxy support proxy support was added by documentation should be added to net http ,1 36479,6536369706.0,IssuesEvent,2017-08-31 17:52:50,golang/go,https://api.github.com/repos/golang/go,closed,doc: Writing web applications ignores error from ListenAndServe,Documentation,"> @campoy: > Does everyone forget to check the error on ListenAndServe? #golang > https://twitter.com/francesc/status/838547440710012928 Nothing in this tutorial https://golang.org/doc/articles/wiki/ **Writing Web Applications**, in the Articles section of documentation, seems to indicate that ListenAndServe may return an error. Errors should be checked. > https://golang.org/pkg/net/http/#ListenAndServe > func ListenAndServe(addr string, handler Handler) error > ListenAndServe always returns a non-nil error. Since I don't see an issue opened by @campoy , I'm opening one. **EDIT: Clarified that the issue is in Article, not the package documentation.**",1.0,"doc: Writing web applications ignores error from ListenAndServe - > @campoy: > Does everyone forget to check the error on ListenAndServe? #golang > https://twitter.com/francesc/status/838547440710012928 Nothing in this tutorial https://golang.org/doc/articles/wiki/ **Writing Web Applications**, in the Articles section of documentation, seems to indicate that ListenAndServe may return an error. Errors should be checked. > https://golang.org/pkg/net/http/#ListenAndServe > func ListenAndServe(addr string, handler Handler) error > ListenAndServe always returns a non-nil error. Since I don't see an issue opened by @campoy , I'm opening one. **EDIT: Clarified that the issue is in Article, not the package documentation.**",1,doc writing web applications ignores error from listenandserve campoy does everyone forget to check the error on listenandserve golang nothing in this tutorial writing web applications in the articles section of documentation seems to indicate that listenandserve may return an error errors should be checked func listenandserve addr string handler handler error listenandserve always returns a non nil error since i don t see an issue opened by campoy i m opening one edit clarified that the issue is in article not the package documentation ,1 29137,8299493518.0,IssuesEvent,2018-09-21 03:14:37,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gerritbot: don't ask author to do the review,Builders,"Not sure if I have the right component here, but I just sent a couple of CLs regarding fmt, and ""Gobot"" asked me and only me to review them. ",1.0,"x/build/cmd/gerritbot: don't ask author to do the review - Not sure if I have the right component here, but I just sent a couple of CLs regarding fmt, and ""Gobot"" asked me and only me to review them. ",0,x build cmd gerritbot don t ask author to do the review not sure if i have the right component here but i just sent a couple of cls regarding fmt and gobot asked me and only me to review them ,0 206696,16049986467.0,IssuesEvent,2021-04-22 17:53:28,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: textDocument/completion suggests internal packages from other modules,Documentation Tools gopls," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
#### gopls version 
$ gopls version
golang.org/x/tools/gopls v0.6.10
#### vscode-go version ``` Id: golang.go Version: 0.24.2 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""~/.cache/go-build""
GOENV=""~/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""~/.go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""~/.go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.3""
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-build1429872732=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I'll take `Tag` from `golang.org/x/text/language` as an example. 1. I create variable and start typing `language.Tag` 2. LSP client (vscode-go in my case) tries to make a code completion for package that isn't yet imported in current scope ### What did you expect to see? I expect to **not** see suggestions for `internal` packages from `golang.org/x` when I'm working inside my own modules since these imports will be restricted and cannot be used. ### What did you see instead? Sometimes (actually quite a lot of times) first suggestion comes from `x/text/internal/language` instead of `x/text/language`.
gopls trace
[Trace - 19:50:58.056 PM] Received response 'textDocument/completion - (57)' in 47ms.
Result: {""isIncomplete"":true,""items"":[{""label"":""language.Language"",""kind"":7,""detail"":""uint16 (from \""golang.org/x/text/internal/language\"")"",""preselect"":true,""sortText"":""00000"",""filterText"":""language.Language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.Language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""golang.org/x/text/language\"""",""sortText"":""00001"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""golang.org/x/text/internal/language\"""",""sortText"":""00002"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language.BaseLanguages"",""kind"":3,""detail"":""func() []language.Language (from \""golang.org/x/text/internal/language\"")"",""documentation"":""BaseLanguages returns the list of all supported base languages. It generates\nthe list by traversing the internal structures.\n"",""sortText"":""00003"",""filterText"":""language.BaseLanguages"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.BaseLanguages()""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language.ParseAcceptLanguage"",""kind"":3,""detail"":""func(s string) (tag []language.Tag, q []float32, err error) (from \""golang.org/x/text/language\"")"",""documentation"":""ParseAcceptLanguage parses the contents of an Accept-Language header as\ndefined in http://www.ietf.org/rfc/rfc2616.txt and returns a list of Tags and\na list of corresponding quality weights. It is more permissive than RFC 2616\nand may return non-nil slices even if the input is not valid.\nThe Tags will be sorted by highest weight first and then by first occurrence.\nTags with a weight of zero will be dropped. An error will be returned if the\ninput could not be parsed.\n"",""sortText"":""00004"",""filterText"":""language.ParseAcceptLanguage"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.ParseAcceptLanguage(${1:})""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""google.golang.org/genproto/googleapis/cloud/language/v1\"""",""sortText"":""00007"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""google.golang.org/genproto/googleapis/cloud/language/v1\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""google.golang.org/api/language/v1\"""",""sortText"":""00008"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""google.golang.org/api/language/v1\""\n\t\""""}]}]}
",1.0,"x/tools/gopls: textDocument/completion suggests internal packages from other modules - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
#### gopls version 
$ gopls version
golang.org/x/tools/gopls v0.6.10
#### vscode-go version ``` Id: golang.go Version: 0.24.2 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""~/.cache/go-build""
GOENV=""~/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""~/.go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""~/.go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.3""
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-build1429872732=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I'll take `Tag` from `golang.org/x/text/language` as an example. 1. I create variable and start typing `language.Tag` 2. LSP client (vscode-go in my case) tries to make a code completion for package that isn't yet imported in current scope ### What did you expect to see? I expect to **not** see suggestions for `internal` packages from `golang.org/x` when I'm working inside my own modules since these imports will be restricted and cannot be used. ### What did you see instead? Sometimes (actually quite a lot of times) first suggestion comes from `x/text/internal/language` instead of `x/text/language`.
gopls trace
[Trace - 19:50:58.056 PM] Received response 'textDocument/completion - (57)' in 47ms.
Result: {""isIncomplete"":true,""items"":[{""label"":""language.Language"",""kind"":7,""detail"":""uint16 (from \""golang.org/x/text/internal/language\"")"",""preselect"":true,""sortText"":""00000"",""filterText"":""language.Language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.Language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""golang.org/x/text/language\"""",""sortText"":""00001"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""golang.org/x/text/internal/language\"""",""sortText"":""00002"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language.BaseLanguages"",""kind"":3,""detail"":""func() []language.Language (from \""golang.org/x/text/internal/language\"")"",""documentation"":""BaseLanguages returns the list of all supported base languages. It generates\nthe list by traversing the internal structures.\n"",""sortText"":""00003"",""filterText"":""language.BaseLanguages"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.BaseLanguages()""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/internal/language\""\n\t\""""}]},{""label"":""language.ParseAcceptLanguage"",""kind"":3,""detail"":""func(s string) (tag []language.Tag, q []float32, err error) (from \""golang.org/x/text/language\"")"",""documentation"":""ParseAcceptLanguage parses the contents of an Accept-Language header as\ndefined in http://www.ietf.org/rfc/rfc2616.txt and returns a list of Tags and\na list of corresponding quality weights. It is more permissive than RFC 2616\nand may return non-nil slices even if the input is not valid.\nThe Tags will be sorted by highest weight first and then by first occurrence.\nTags with a weight of zero will be dropped. An error will be returned if the\ninput could not be parsed.\n"",""sortText"":""00004"",""filterText"":""language.ParseAcceptLanguage"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language.ParseAcceptLanguage(${1:})""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""golang.org/x/text/language\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""google.golang.org/genproto/googleapis/cloud/language/v1\"""",""sortText"":""00007"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""google.golang.org/genproto/googleapis/cloud/language/v1\""\n\t\""""}]},{""label"":""language"",""kind"":9,""detail"":""\""google.golang.org/api/language/v1\"""",""sortText"":""00008"",""filterText"":""language"",""insertTextFormat"":2,""textEdit"":{""range"":{""start"":{""line"":36,""character"":1},""end"":{""line"":36,""character"":9}},""newText"":""language""},""additionalTextEdits"":[{""range"":{""start"":{""line"":3,""character"":2},""end"":{""line"":3,""character"":2}},""newText"":""google.golang.org/api/language/v1\""\n\t\""""}]}]}
",1,x tools gopls textdocument completion suggests internal packages from other modules please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux gopls version gopls version golang org x tools gopls vscode go version id golang go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache cache go build goenv config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache go pkg mod gonoproxy gonosumdb goos linux gopath go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 i ll take tag from golang org x text language as an example i create variable and start typing language tag lsp client vscode go in my case tries to make a code completion for package that isn t yet imported in current scope what did you expect to see i expect to not see suggestions for internal packages from golang org x when i m working inside my own modules since these imports will be restricted and cannot be used what did you see instead sometimes actually quite a lot of times first suggestion comes from x text internal language instead of x text language gopls trace received response textdocument completion in result isincomplete true items label language kind detail golang org x text language sorttext filtertext language inserttextformat textedit range start line character end line character newtext language additionaltextedits label language kind detail golang org x text internal language sorttext filtertext language inserttextformat textedit range start line character end line character newtext language additionaltextedits label language baselanguages kind detail func language language from golang org x text internal language documentation baselanguages returns the list of all supported base languages it generates nthe list by traversing the internal structures n sorttext filtertext language baselanguages inserttextformat textedit range start line character end line character newtext language baselanguages additionaltextedits label language parseacceptlanguage kind detail func s string tag language tag q err error from golang org x text language documentation parseacceptlanguage parses the contents of an accept language header as ndefined in and returns a list of tags and na list of corresponding quality weights it is more permissive than rfc nand may return non nil slices even if the input is not valid nthe tags will be sorted by highest weight first and then by first occurrence ntags with a weight of zero will be dropped an error will be returned if the ninput could not be parsed n sorttext filtertext language parseacceptlanguage inserttextformat textedit range start line character end line character newtext language parseacceptlanguage additionaltextedits label language kind detail google golang org genproto googleapis cloud language sorttext filtertext language inserttextformat textedit range start line character end line character newtext language additionaltextedits label language kind detail google golang org api language sorttext filtertext language inserttextformat textedit range start line character end line character newtext language additionaltextedits ,1 3416,3910665360.0,IssuesEvent,2016-04-20 00:08:14,golang/go,https://api.github.com/repos/golang/go,opened,runtime: make mallocgc figure out kindNoPointers by itself,Performance,"See the discussion at https://go-review.googlesource.com/#/c/22276/1/src/runtime/slice.go@63. Can mallocgc do without any flags param at all? cc @bradfitz @randall77 ",True,"runtime: make mallocgc figure out kindNoPointers by itself - See the discussion at https://go-review.googlesource.com/#/c/22276/1/src/runtime/slice.go@63. Can mallocgc do without any flags param at all? cc @bradfitz @randall77 ",0,runtime make mallocgc figure out kindnopointers by itself see the discussion at can mallocgc do without any flags param at all cc bradfitz ,0 363174,25411994606.0,IssuesEvent,2022-11-22 19:51:49,golang/go,https://api.github.com/repos/golang/go,opened,x/sync/semaphore: document ordering of Weighted.Acquire,Documentation Proposal,"I was debugging a sluggish system and the problem came down to the ordering of how `Acquire` was satisfied. The current behavior of `Weighted.Acquire` is that it serves acquisitions in order. This is a reasonable behavior, but it should be documented as it is significant performance implications. In particular, this behavior leads to head-of-line blocking where a large acquisition will prevent smaller acquisitions from making progress. The alternate behavior to satisfy any possible acquisition out-of-order, but that would lead to live-lock situations where a continuous stream of small acquisitions prevent a large acquisition from ever making progress. My solution ended up splitting the semaphore into two parts: * a semaphore for small requests * a semaphore for large requests. However, it was not obvious to me that I should do this since I had originally assumed that the semaphore allowed for out-of-order acquisitions.",1.0,"x/sync/semaphore: document ordering of Weighted.Acquire - I was debugging a sluggish system and the problem came down to the ordering of how `Acquire` was satisfied. The current behavior of `Weighted.Acquire` is that it serves acquisitions in order. This is a reasonable behavior, but it should be documented as it is significant performance implications. In particular, this behavior leads to head-of-line blocking where a large acquisition will prevent smaller acquisitions from making progress. The alternate behavior to satisfy any possible acquisition out-of-order, but that would lead to live-lock situations where a continuous stream of small acquisitions prevent a large acquisition from ever making progress. My solution ended up splitting the semaphore into two parts: * a semaphore for small requests * a semaphore for large requests. However, it was not obvious to me that I should do this since I had originally assumed that the semaphore allowed for out-of-order acquisitions.",1,x sync semaphore document ordering of weighted acquire i was debugging a sluggish system and the problem came down to the ordering of how acquire was satisfied the current behavior of weighted acquire is that it serves acquisitions in order this is a reasonable behavior but it should be documented as it is significant performance implications in particular this behavior leads to head of line blocking where a large acquisition will prevent smaller acquisitions from making progress the alternate behavior to satisfy any possible acquisition out of order but that would lead to live lock situations where a continuous stream of small acquisitions prevent a large acquisition from ever making progress my solution ended up splitting the semaphore into two parts a semaphore for small requests a semaphore for large requests however it was not obvious to me that i should do this since i had originally assumed that the semaphore allowed for out of order acquisitions ,1 13291,3699724840.0,IssuesEvent,2016-02-29 02:34:11,golang/go,https://api.github.com/repos/golang/go,closed,time: Tick and NewTicker inconsistency,Documentation,"`NewTicker` will panic if the duration isn't greater than zero, while `Tick` will return `nil`. Ideally `Tick` would panic as well but that could potentially break some code relying on this inconsistency. This special case should be documented as it's definitely not something you'd expect from reading the current `Tick` documentation.",1.0,"time: Tick and NewTicker inconsistency - `NewTicker` will panic if the duration isn't greater than zero, while `Tick` will return `nil`. Ideally `Tick` would panic as well but that could potentially break some code relying on this inconsistency. This special case should be documented as it's definitely not something you'd expect from reading the current `Tick` documentation.",1,time tick and newticker inconsistency newticker will panic if the duration isn t greater than zero while tick will return nil ideally tick would panic as well but that could potentially break some code relying on this inconsistency this special case should be documented as it s definitely not something you d expect from reading the current tick documentation ,1 59030,8319732722.0,IssuesEvent,2018-09-25 18:03:40,golang/go,https://api.github.com/repos/golang/go,closed,doc: broken link in FAQ,Documentation,"Under the question ""[Why do garbage collection? Won't it be too expensive?][1]"", there is a link to https://talks.golang.org/2018/ismmkeynote, which does not exist. It should link to https://blog.golang.org/ismmkeynote. [1]: https://golang.org/doc/faq#garbage_collection",1.0,"doc: broken link in FAQ - Under the question ""[Why do garbage collection? Won't it be too expensive?][1]"", there is a link to https://talks.golang.org/2018/ismmkeynote, which does not exist. It should link to https://blog.golang.org/ismmkeynote. [1]: https://golang.org/doc/faq#garbage_collection",1,doc broken link in faq under the question there is a link to which does not exist it should link to ,1 17658,4184064989.0,IssuesEvent,2016-06-23 04:31:09,golang/go,https://api.github.com/repos/golang/go,closed,html/template: Security Model definition link broken,Documentation,"The [Security Model section](https://golang.org/pkg/html/template/#hdr-Security_Model) links to a document defining ""safe"" template behavior (http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html#problem_definition) which is not available anymore. Does this document still exist? `tip: version devel +eaf4ad6 and go1.6.2` ",1.0,"html/template: Security Model definition link broken - The [Security Model section](https://golang.org/pkg/html/template/#hdr-Security_Model) links to a document defining ""safe"" template behavior (http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html#problem_definition) which is not available anymore. Does this document still exist? `tip: version devel +eaf4ad6 and go1.6.2` ",1,html template security model definition link broken the links to a document defining safe template behavior which is not available anymore does this document still exist tip version devel and ,1 209436,16193852463.0,IssuesEvent,2021-05-04 12:19:48,golang/go,https://api.github.com/repos/golang/go,closed,"x/image: LineTo has an unexpected behaviour, or is not enough documented",Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.6 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/olivierwulveryck/Library/Caches/go-build""
GOENV=""/Users/olivierwulveryck/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/olivierwulveryck/GOPROJECTS/pkg/mod""
GONOPROXY=""github.com/dktunited""
GONOSUMDB=""github.com/dktunited""
GOOS=""darwin""
GOPATH=""/Users/olivierwulveryck/GOPROJECTS""
GOPRIVATE=""github.com/dktunited""
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/olivierwulveryck/GOPROJECTS/src/github.com/owulveryck/linesToGo/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/j3/t2_lsqzd5mgbv7tqvxg9ty5r0000gn/T/go-build500293275=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I am trying to draw a simple line on a picture with the `vector` package. I cannot figure out how the package work. I made a trivial test and I expect it to see in the mask two identical values (representing the horizontal line) and two identical nil values. ```go func TestMe(t *testing.T) { z := vector.NewRasterizer(2, 2) z.DrawOp = draw.Src // . | . // ----- // . | . z.MoveTo(0, 0) z.LineTo(1, 0) // x | x // ----- // . | . dst := image.NewAlpha(z.Bounds()) z.Draw(dst, dst.Bounds(), image.Opaque, image.Point{}) expected := []uint8{255, 255, 0, 0} if !reflect.DeepEqual(dst.Pix, expected) { t.Fatal(dst.Pix) } } ``` https://play.golang.org/p/RnHAWhUwP7K I tried to debug the code without success. I may have completely misunderstood how to use the package. Therefore an example would help ### What did you expect to see? Eventually, the representation of a line ### What did you see instead? A blank mask or a black picture",1.0,"x/image: LineTo has an unexpected behaviour, or is not enough documented - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.6 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/olivierwulveryck/Library/Caches/go-build""
GOENV=""/Users/olivierwulveryck/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/olivierwulveryck/GOPROJECTS/pkg/mod""
GONOPROXY=""github.com/dktunited""
GONOSUMDB=""github.com/dktunited""
GOOS=""darwin""
GOPATH=""/Users/olivierwulveryck/GOPROJECTS""
GOPRIVATE=""github.com/dktunited""
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/olivierwulveryck/GOPROJECTS/src/github.com/owulveryck/linesToGo/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/j3/t2_lsqzd5mgbv7tqvxg9ty5r0000gn/T/go-build500293275=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I am trying to draw a simple line on a picture with the `vector` package. I cannot figure out how the package work. I made a trivial test and I expect it to see in the mask two identical values (representing the horizontal line) and two identical nil values. ```go func TestMe(t *testing.T) { z := vector.NewRasterizer(2, 2) z.DrawOp = draw.Src // . | . // ----- // . | . z.MoveTo(0, 0) z.LineTo(1, 0) // x | x // ----- // . | . dst := image.NewAlpha(z.Bounds()) z.Draw(dst, dst.Bounds(), image.Opaque, image.Point{}) expected := []uint8{255, 255, 0, 0} if !reflect.DeepEqual(dst.Pix, expected) { t.Fatal(dst.Pix) } } ``` https://play.golang.org/p/RnHAWhUwP7K I tried to debug the code without success. I may have completely misunderstood how to use the package. Therefore an example would help ### What did you expect to see? Eventually, the representation of a line ### What did you see instead? A blank mask or a black picture",1,x image lineto has an unexpected behaviour or is not enough documented please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users olivierwulveryck library caches go build goenv users olivierwulveryck library application support go env goexe goflags gohostarch gohostos darwin goinsecure gomodcache users olivierwulveryck goprojects pkg mod gonoproxy github com dktunited gonosumdb github com dktunited goos darwin gopath users olivierwulveryck goprojects goprivate github com dktunited goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users olivierwulveryck goprojects src github com owulveryck linestogo go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do i am trying to draw a simple line on a picture with the vector package i cannot figure out how the package work i made a trivial test and i expect it to see in the mask two identical values representing the horizontal line and two identical nil values go func testme t testing t z vector newrasterizer z drawop draw src z moveto z lineto x x dst image newalpha z bounds z draw dst dst bounds image opaque image point expected if reflect deepequal dst pix expected t fatal dst pix i tried to debug the code without success i may have completely misunderstood how to use the package therefore an example would help if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see eventually the representation of a line what did you see instead a blank mask or a black picture,1 126487,10424932071.0,IssuesEvent,2019-09-16 14:31:15,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/cmd/callgraph: TestCallgraph has started to fail with Go tip,NeedsInvestigation Testing,"![image](https://user-images.githubusercontent.com/1924134/64966563-047f5780-d86d-11e9-98f7-1e4096e8b4bf.png) From https://build.golang.org/?repo=golang.org%2fx%2ftools, it looks like the failure started to happen roughly close to https://github.com/golang/go/commit/24781a1faf62ac5c9a553af6f46b787e972f5539, but that might not be the exact commit. Unfortunately, I can't reproduce it locally yet. For now, I'll send a CL to get more debug info out of the builders where it reproduces easily. /cc @jayconrod @matloob",1.0,"x/tools/cmd/callgraph: TestCallgraph has started to fail with Go tip - ![image](https://user-images.githubusercontent.com/1924134/64966563-047f5780-d86d-11e9-98f7-1e4096e8b4bf.png) From https://build.golang.org/?repo=golang.org%2fx%2ftools, it looks like the failure started to happen roughly close to https://github.com/golang/go/commit/24781a1faf62ac5c9a553af6f46b787e972f5539, but that might not be the exact commit. Unfortunately, I can't reproduce it locally yet. For now, I'll send a CL to get more debug info out of the builders where it reproduces easily. /cc @jayconrod @matloob",0,x tools cmd callgraph testcallgraph has started to fail with go tip from it looks like the failure started to happen roughly close to but that might not be the exact commit unfortunately i can t reproduce it locally yet for now i ll send a cl to get more debug info out of the builders where it reproduces easily cc jayconrod matloob,0 98883,30212622193.0,IssuesEvent,2023-07-05 13:43:13,golang/go,https://api.github.com/repos/golang/go,closed,"x/build/cmd/relui: pkgbuild produces an installer that installs to /usr/local/go/bin/go, no longer in PATH on os X mojave",OS-Darwin Builders WaitingForInfo NeedsInvestigation,"### What version of Go are you using (`go version`)? go 1.11.2 darwin/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin/amd64
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/b5/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/b5/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/6p/sjn8bct92397mbgwmwwvcb4h0000gn/T/go-build195699704=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Ran the go .pkg installer downloaded from golang.org. Installer completes successfully. I then moved over to the command line & ran: ```shell $ which go go not found ``` ### What did you expect to see? I was _hoping_ to see `/usr/local/go/bin/go`, or for some magic created by `pkgbuild/productbuild` to symlink `/usr/local/go/bin/go` -> `/usr/local/bin/go`. but alas, nope. This problem only seems to exist on os x Mojave (as far as I can tell). ### What did you see instead? `go not found` My guess is the fix will land [here](https://github.com/golang/build/blob/790500f5933191797a6638a27127be424f6ae2c2/cmd/release/releaselet.go) ",1.0,"x/build/cmd/relui: pkgbuild produces an installer that installs to /usr/local/go/bin/go, no longer in PATH on os X mojave - ### What version of Go are you using (`go version`)? go 1.11.2 darwin/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin/amd64
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/b5/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/b5/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/6p/sjn8bct92397mbgwmwwvcb4h0000gn/T/go-build195699704=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Ran the go .pkg installer downloaded from golang.org. Installer completes successfully. I then moved over to the command line & ran: ```shell $ which go go not found ``` ### What did you expect to see? I was _hoping_ to see `/usr/local/go/bin/go`, or for some magic created by `pkgbuild/productbuild` to symlink `/usr/local/go/bin/go` -> `/usr/local/bin/go`. but alas, nope. This problem only seems to exist on os x Mojave (as far as I can tell). ### What did you see instead? `go not found` My guess is the fix will land [here](https://github.com/golang/build/blob/790500f5933191797a6638a27127be424f6ae2c2/cmd/release/releaselet.go) ",0,x build cmd relui pkgbuild produces an installer that installs to usr local go bin go no longer in path on os x mojave what version of go are you using go version go darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env darwin go env output go env goarch gobin gocache users library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users go goproxy gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do ran the go pkg installer downloaded from golang org installer completes successfully i then moved over to the command line ran shell which go go not found what did you expect to see i was hoping to see usr local go bin go or for some magic created by pkgbuild productbuild to symlink usr local go bin go usr local bin go but alas nope this problem only seems to exist on os x mojave as far as i can tell what did you see instead go not found my guess is the fix will land ,0 271416,20672534691.0,IssuesEvent,2022-03-10 04:56:26,golang/go,https://api.github.com/repos/golang/go,closed,spec: make(T) compiles even though T has no core type,Documentation NeedsFix,"From a [golang-nuts post](https://groups.google.com/g/golang-nuts/c/JIZuVoUNAlE/m/Ja0SHiS0AgAJ): ```Go package main func main() {} type C interface { map[int]int M() } func foo[T C]() { var _ = make(T) } ``` This program compiles without error even though `T` doesn't have a core type (the typeset of `C` is empty). This may require an update to the definition of core types or perhaps some other accommodation in the spec.",1.0,"spec: make(T) compiles even though T has no core type - From a [golang-nuts post](https://groups.google.com/g/golang-nuts/c/JIZuVoUNAlE/m/Ja0SHiS0AgAJ): ```Go package main func main() {} type C interface { map[int]int M() } func foo[T C]() { var _ = make(T) } ``` This program compiles without error even though `T` doesn't have a core type (the typeset of `C` is empty). This may require an update to the definition of core types or perhaps some other accommodation in the spec.",1,spec make t compiles even though t has no core type from a go package main func main type c interface map int m func foo var make t this program compiles without error even though t doesn t have a core type the typeset of c is empty this may require an update to the definition of core types or perhaps some other accommodation in the spec ,1 26717,5282655565.0,IssuesEvent,2017-02-07 19:24:18,golang/go,https://api.github.com/repos/golang/go,closed,time: behavior of function Parse for Feburary 31,Documentation NeedsFix,"### What version of Go are you using (`go version`)? go version go1.7.5 darwin/amd64 ### What did you do? https://play.golang.org/p/R4HlVseTm2 ### What did you expect to see? A behavior which corresponds the documentation. Actually I expect to see an error, but the current documentation says that it should be parsed successfully. > For example February 31 and even February 99 are valid dates, specifying dates in March and May. Documentation was introduced by CL https://golang.org/cl/14123 but that behavior was changed later by CL https://golang.org/cl/17710",1.0,"time: behavior of function Parse for Feburary 31 - ### What version of Go are you using (`go version`)? go version go1.7.5 darwin/amd64 ### What did you do? https://play.golang.org/p/R4HlVseTm2 ### What did you expect to see? A behavior which corresponds the documentation. Actually I expect to see an error, but the current documentation says that it should be parsed successfully. > For example February 31 and even February 99 are valid dates, specifying dates in March and May. Documentation was introduced by CL https://golang.org/cl/14123 but that behavior was changed later by CL https://golang.org/cl/17710",1,time behavior of function parse for feburary what version of go are you using go version go version darwin what did you do what did you expect to see a behavior which corresponds the documentation actually i expect to see an error but the current documentation says that it should be parsed successfully for example february and even february are valid dates specifying dates in march and may documentation was introduced by cl but that behavior was changed later by cl ,1 353129,25103105059.0,IssuesEvent,2022-11-08 14:55:11,golang/go,https://api.github.com/repos/golang/go,closed,"net: make LookupCNAME consistent between Unix and Windows, document",Documentation OS-Windows Proposal Proposal-Accepted Proposal-FinalCommentPeriod,"LookupCNAME is pretty weird right now. Despite the name, it entirely ignores CNAME records on Unix. It launches `A` and `AAAA` record lookups to recursive resolvers and returns the first response name found in the `A` and `AAAA`, skipping over any `CNAME`. (and not even asking for a `CNAME`) But it documents that it does that... https://pkg.go.dev/net#LookupCNAME > A canonical name is the final name after following zero or more CNAME records. LookupCNAME does not return an error if host does not contain DNS ""CNAME"" records, as long as host resolves to address records. OTOH, on Windows, it does what you would expect from the name itself: it looks up CNAME records: ```go func (*Resolver) lookupCNAME(ctx context.Context, name string) (string, error) { // TODO(bradfitz): finish ctx plumbing. Nothing currently depends on this. acquireThread() defer releaseThread() var r *syscall.DNSRecord e := syscall.DnsQuery(name, syscall.DNS_TYPE_CNAME, 0, nil, &r, nil) ``` Here's a demo of a program behaving differently: ```go func main() { txt, err := net.LookupTXT(""cname-to-txt.go4.org"") log.Printf(""LookupTXT = %q, %v"", txt, err) cname, err := net.LookupCNAME(""cname-to-txt.go4.org"") log.Printf(""cname = %q, %v"", cname, err) } ``` On Linux/Mac: ``` 2021/12/10 21:19:45 LookupTXT = [""foo=bar""], 2021/12/10 21:19:45 cname = """", lookup cname-to-txt.go4.org: no such host ``` On Windows: ``` 2021/12/10 21:11:45 LookupTXT = [""foo=bar""], 2021/12/10 21:11:45 cname = ""test-txt-record.go4.org."", ``` I like the Windows behavior better, FWIW. That's what I was looking for, but apparently it doesn't exist. Can we either: 1. add `LookupCNAMERecord` that actually looks up a CNAME record 2. redefine `LookupCNAME` to be like Windows, perhaps adding a `LookupCanonicalName` with the current weird Unix behavior of `LookupCNAME`? But at minimum: document whatever the rules are and make Unix and Windows match? At least in `Resolver.PreferGo` mode?",1.0,"net: make LookupCNAME consistent between Unix and Windows, document - LookupCNAME is pretty weird right now. Despite the name, it entirely ignores CNAME records on Unix. It launches `A` and `AAAA` record lookups to recursive resolvers and returns the first response name found in the `A` and `AAAA`, skipping over any `CNAME`. (and not even asking for a `CNAME`) But it documents that it does that... https://pkg.go.dev/net#LookupCNAME > A canonical name is the final name after following zero or more CNAME records. LookupCNAME does not return an error if host does not contain DNS ""CNAME"" records, as long as host resolves to address records. OTOH, on Windows, it does what you would expect from the name itself: it looks up CNAME records: ```go func (*Resolver) lookupCNAME(ctx context.Context, name string) (string, error) { // TODO(bradfitz): finish ctx plumbing. Nothing currently depends on this. acquireThread() defer releaseThread() var r *syscall.DNSRecord e := syscall.DnsQuery(name, syscall.DNS_TYPE_CNAME, 0, nil, &r, nil) ``` Here's a demo of a program behaving differently: ```go func main() { txt, err := net.LookupTXT(""cname-to-txt.go4.org"") log.Printf(""LookupTXT = %q, %v"", txt, err) cname, err := net.LookupCNAME(""cname-to-txt.go4.org"") log.Printf(""cname = %q, %v"", cname, err) } ``` On Linux/Mac: ``` 2021/12/10 21:19:45 LookupTXT = [""foo=bar""], 2021/12/10 21:19:45 cname = """", lookup cname-to-txt.go4.org: no such host ``` On Windows: ``` 2021/12/10 21:11:45 LookupTXT = [""foo=bar""], 2021/12/10 21:11:45 cname = ""test-txt-record.go4.org."", ``` I like the Windows behavior better, FWIW. That's what I was looking for, but apparently it doesn't exist. Can we either: 1. add `LookupCNAMERecord` that actually looks up a CNAME record 2. redefine `LookupCNAME` to be like Windows, perhaps adding a `LookupCanonicalName` with the current weird Unix behavior of `LookupCNAME`? But at minimum: document whatever the rules are and make Unix and Windows match? At least in `Resolver.PreferGo` mode?",1,net make lookupcname consistent between unix and windows document lookupcname is pretty weird right now despite the name it entirely ignores cname records on unix it launches a and aaaa record lookups to recursive resolvers and returns the first response name found in the a and aaaa skipping over any cname and not even asking for a cname but it documents that it does that a canonical name is the final name after following zero or more cname records lookupcname does not return an error if host does not contain dns cname records as long as host resolves to address records otoh on windows it does what you would expect from the name itself it looks up cname records go func resolver lookupcname ctx context context name string string error todo bradfitz finish ctx plumbing nothing currently depends on this acquirethread defer releasethread var r syscall dnsrecord e syscall dnsquery name syscall dns type cname nil r nil here s a demo of a program behaving differently go func main txt err net lookuptxt cname to txt org log printf lookuptxt q v txt err cname err net lookupcname cname to txt org log printf cname q v cname err on linux mac lookuptxt cname lookup cname to txt org no such host on windows lookuptxt cname test txt record org i like the windows behavior better fwiw that s what i was looking for but apparently it doesn t exist can we either add lookupcnamerecord that actually looks up a cname record redefine lookupcname to be like windows perhaps adding a lookupcanonicalname with the current weird unix behavior of lookupcname but at minimum document whatever the rules are and make unix and windows match at least in resolver prefergo mode ,1 92166,26599687264.0,IssuesEvent,2023-01-23 14:58:03,golang/go,https://api.github.com/repos/golang/go,opened,x/build: add a windows/arm builder using a windows/arm64 host,OS-Windows Builders arch-arm,"@zx2c4 windows/arm builder has been missing for a long time, although it still appears on the build dashboard. I've been able to compile a windows/arm Go toolchain and run `go tool dist test` using a Windows ARM64 host by setting `GOHOSTARCH=arm` and `GOARCH=arm`. I believe that we could follow the same approach with the `host-windows11-arm64-azure` host (recently added as part of #53541), using it to run a windows/arm builder. @heschi @thanm ",1.0,"x/build: add a windows/arm builder using a windows/arm64 host - @zx2c4 windows/arm builder has been missing for a long time, although it still appears on the build dashboard. I've been able to compile a windows/arm Go toolchain and run `go tool dist test` using a Windows ARM64 host by setting `GOHOSTARCH=arm` and `GOARCH=arm`. I believe that we could follow the same approach with the `host-windows11-arm64-azure` host (recently added as part of #53541), using it to run a windows/arm builder. @heschi @thanm ",0,x build add a windows arm builder using a windows host windows arm builder has been missing for a long time although it still appears on the build dashboard i ve been able to compile a windows arm go toolchain and run go tool dist test using a windows host by setting gohostarch arm and goarch arm i believe that we could follow the same approach with the host azure host recently added as part of using it to run a windows arm builder heschi thanm ,0 43244,23164221062.0,IssuesEvent,2022-07-29 21:46:34,golang/go,https://api.github.com/repos/golang/go,closed,net: TCPConn.Read Higher CPU usage than comparable operation in python3/c#/nodejs,Performance NeedsInvestigation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.18.4 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/root/.cache/go-build""
GOENV=""/root/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/root/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/root/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.18.4""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/root/GoServer/go.mod""
GOWORK=""""
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-build3785892550=/tmp/go-build -gno-record-gcc-switches""

cat /etc/os-release
NAME=""Ubuntu""
VERSION=""20.04.4 LTS (Focal Fossa)""
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME=""Ubuntu 20.04.4 LTS""
VERSION_ID=""20.04""
HOME_URL=""https://www.ubuntu.com/""
SUPPORT_URL=""https://help.ubuntu.com/""
BUG_REPORT_URL=""https://bugs.launchpad.net/ubuntu/""
PRIVACY_POLICY_URL=""https://www.ubuntu.com/legal/terms-and-policies/privacy-policy""
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
### What did you do? I was debugging higher than expected CPU usage for async socket operations in c#/net6 on linux and ran a series of socket tests in nodejs, python3, c, and go as a references. I noticed that go uses about twice as much cpu as python3/c/.net6 and somewhat more than nodejs in my synchronous read test case. It's not a bug but I thought I'd share the findings in case somebody is interested at looking at it. I suspect there is some optimization that can be done to bring the go results in line with the others. I'm not a go developer but the code and are test are very simple so I don't believe it's naivety on my part - though I apologize if it is. These tests are done with the default settings, I'm not adjusting any socket settings, OS settings, etc. Just plain socket reads into an oversized buffer. From another host on the network I run netcat to saturate the network (in my case the receiving server is 192.168.1.93 and my tests were with a gigabit network) cat /dev/zero | nc 192.168.1.93 9989 Then I run a receiving application such as the go application below to read the data and print out some details when I kill the netcat. I monitored the cpu usage with top and confirmed the network usage with iftop in addition to the application output below. using netcat as a listener nc -l 9989 >/dev/null uses about 8% cpu using golang with a goroutine per connection receiving into a buffer ./GoServer (attached zip, but it's super simple and has the code) uses about 14% cpu using nodejs and the socket.on data callback nodejs jsserver.js uses about 10% cpu (not re-using a receive buffer so it's less efficient) using python3 with a synchronous tcp socket receiving into a buffer python3 pyserver.py uses about 8% cpu using .net6 with a synchronous tcp socket receiving into a buffer dotnet run --configuration Release PerfTestTCPListener uses about 6-8% cpu Code for python3, nodejs, c#/net6 [OtherSamples.zip](https://github.com/golang/go/files/9133779/OtherSamples.zip) Code for Go [GoServer.zip](https://github.com/golang/go/files/9133803/GoServer.zip) 
package main

import (
        ""fmt""
        ""io""
        ""net""
        ""os""
        ""time""
)

func main() {
        port := ""0.0.0.0:9989""
        listener, err := net.Listen(""tcp"", port)
        if err != nil {
                fmt.Println(""failed to create listener, err:"", err)
                os.Exit(1)
        }
        fmt.Printf(""listening on %s\n"", listener.Addr())

        for {
                conn, err := listener.Accept()
                if err != nil {
                        fmt.Println(""failed to accept connection, err:"", err)
                        continue
                }
                // run connection in a goroutine
                go handleConnection(conn)
        }
}

func handleConnection(conn net.Conn) {
        defer conn.Close()
        buf := make([]byte, 1048576)
        nBytes := 0
        start := time.Now()
        for {
                n, err := conn.Read(buf)
                if err != nil {
                        if err != io.EOF {
                                fmt.Println(""failed to read data, err:"", err)
                        }
                        t := time.Now()
                        elapsed := t.Sub(start)
                        fmt.Printf(""Read: %d MB in %s, %f MB/s\n"", nBytes/1048576, elapsed, float64(nBytes)/1048576.0/el                                                                       apsed.Seconds())
                        return
                }
                nBytes += n
        }
}
### What did you expect to see? Similar cpu usage to python/.net6/nodejs ### What did you see instead? ~14% cpu usage vs ~8% cpu usage for python3/net6 and ~10% cpu usage for nodejs ",True,"net: TCPConn.Read Higher CPU usage than comparable operation in python3/c#/nodejs - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18.4 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/root/.cache/go-build""
GOENV=""/root/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/root/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/root/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.18.4""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/root/GoServer/go.mod""
GOWORK=""""
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-build3785892550=/tmp/go-build -gno-record-gcc-switches""

cat /etc/os-release
NAME=""Ubuntu""
VERSION=""20.04.4 LTS (Focal Fossa)""
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME=""Ubuntu 20.04.4 LTS""
VERSION_ID=""20.04""
HOME_URL=""https://www.ubuntu.com/""
SUPPORT_URL=""https://help.ubuntu.com/""
BUG_REPORT_URL=""https://bugs.launchpad.net/ubuntu/""
PRIVACY_POLICY_URL=""https://www.ubuntu.com/legal/terms-and-policies/privacy-policy""
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
### What did you do? I was debugging higher than expected CPU usage for async socket operations in c#/net6 on linux and ran a series of socket tests in nodejs, python3, c, and go as a references. I noticed that go uses about twice as much cpu as python3/c/.net6 and somewhat more than nodejs in my synchronous read test case. It's not a bug but I thought I'd share the findings in case somebody is interested at looking at it. I suspect there is some optimization that can be done to bring the go results in line with the others. I'm not a go developer but the code and are test are very simple so I don't believe it's naivety on my part - though I apologize if it is. These tests are done with the default settings, I'm not adjusting any socket settings, OS settings, etc. Just plain socket reads into an oversized buffer. From another host on the network I run netcat to saturate the network (in my case the receiving server is 192.168.1.93 and my tests were with a gigabit network) cat /dev/zero | nc 192.168.1.93 9989 Then I run a receiving application such as the go application below to read the data and print out some details when I kill the netcat. I monitored the cpu usage with top and confirmed the network usage with iftop in addition to the application output below. using netcat as a listener nc -l 9989 >/dev/null uses about 8% cpu using golang with a goroutine per connection receiving into a buffer ./GoServer (attached zip, but it's super simple and has the code) uses about 14% cpu using nodejs and the socket.on data callback nodejs jsserver.js uses about 10% cpu (not re-using a receive buffer so it's less efficient) using python3 with a synchronous tcp socket receiving into a buffer python3 pyserver.py uses about 8% cpu using .net6 with a synchronous tcp socket receiving into a buffer dotnet run --configuration Release PerfTestTCPListener uses about 6-8% cpu Code for python3, nodejs, c#/net6 [OtherSamples.zip](https://github.com/golang/go/files/9133779/OtherSamples.zip) Code for Go [GoServer.zip](https://github.com/golang/go/files/9133803/GoServer.zip) 
package main

import (
        ""fmt""
        ""io""
        ""net""
        ""os""
        ""time""
)

func main() {
        port := ""0.0.0.0:9989""
        listener, err := net.Listen(""tcp"", port)
        if err != nil {
                fmt.Println(""failed to create listener, err:"", err)
                os.Exit(1)
        }
        fmt.Printf(""listening on %s\n"", listener.Addr())

        for {
                conn, err := listener.Accept()
                if err != nil {
                        fmt.Println(""failed to accept connection, err:"", err)
                        continue
                }
                // run connection in a goroutine
                go handleConnection(conn)
        }
}

func handleConnection(conn net.Conn) {
        defer conn.Close()
        buf := make([]byte, 1048576)
        nBytes := 0
        start := time.Now()
        for {
                n, err := conn.Read(buf)
                if err != nil {
                        if err != io.EOF {
                                fmt.Println(""failed to read data, err:"", err)
                        }
                        t := time.Now()
                        elapsed := t.Sub(start)
                        fmt.Printf(""Read: %d MB in %s, %f MB/s\n"", nBytes/1048576, elapsed, float64(nBytes)/1048576.0/el                                                                       apsed.Seconds())
                        return
                }
                nBytes += n
        }
}
### What did you expect to see? Similar cpu usage to python/.net6/nodejs ### What did you see instead? ~14% cpu usage vs ~8% cpu usage for python3/net6 and ~10% cpu usage for nodejs ",0,net tcpconn read higher cpu usage than comparable operation in c nodejs what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache root cache go build goenv root config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache root go pkg mod gonoproxy gonosumdb goos linux gopath root go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod root goserver go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cat etc os release name ubuntu version lts focal fossa id ubuntu id like debian pretty name ubuntu lts version id home url support url bug report url privacy policy url version codename focal ubuntu codename focal what did you do i was debugging higher than expected cpu usage for async socket operations in c on linux and ran a series of socket tests in nodejs c and go as a references i noticed that go uses about twice as much cpu as c and somewhat more than nodejs in my synchronous read test case it s not a bug but i thought i d share the findings in case somebody is interested at looking at it i suspect there is some optimization that can be done to bring the go results in line with the others i m not a go developer but the code and are test are very simple so i don t believe it s naivety on my part though i apologize if it is these tests are done with the default settings i m not adjusting any socket settings os settings etc just plain socket reads into an oversized buffer from another host on the network i run netcat to saturate the network in my case the receiving server is and my tests were with a gigabit network cat dev zero nc then i run a receiving application such as the go application below to read the data and print out some details when i kill the netcat i monitored the cpu usage with top and confirmed the network usage with iftop in addition to the application output below using netcat as a listener nc l dev null uses about cpu using golang with a goroutine per connection receiving into a buffer goserver attached zip but it s super simple and has the code uses about cpu using nodejs and the socket on data callback nodejs jsserver js uses about cpu not re using a receive buffer so it s less efficient using with a synchronous tcp socket receiving into a buffer pyserver py uses about cpu using with a synchronous tcp socket receiving into a buffer dotnet run configuration release perftesttcplistener uses about cpu code for nodejs c code for go package main import fmt io net os time func main port listener err net listen tcp port if err nil fmt println failed to create listener err err os exit fmt printf listening on s n listener addr for conn err listener accept if err nil fmt println failed to accept connection err err continue run connection in a goroutine go handleconnection conn func handleconnection conn net conn defer conn close buf make byte nbytes start time now for n err conn read buf if err nil if err io eof fmt println failed to read data err err t time now elapsed t sub start fmt printf read d mb in s f mb s n nbytes elapsed nbytes el apsed seconds return nbytes n what did you expect to see similar cpu usage to python nodejs what did you see instead cpu usage vs cpu usage for and cpu usage for nodejs ,0 85571,24627315498.0,IssuesEvent,2022-10-16 17:33:45,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/updatestd: test failures without useful output,Builders WaitingForInfo NeedsFix,"``` 2022/09/08 04:11:11 > go list -mod=readonly -m -json all 2022/09/08 04:11:11 command failed: exit status 1 FAIL golang.org/x/build/cmd/updatestd 92.408s ``` It looks like the `go list` command failed, but I can't dig into it further because the `stderr` stream from the `go list` command is not logged. A good first step would probably be to update this test in line with https://go.dev/wiki/CodeReviewComments#useful-test-failures.",1.0,"x/build/cmd/updatestd: test failures without useful output - ``` 2022/09/08 04:11:11 > go list -mod=readonly -m -json all 2022/09/08 04:11:11 command failed: exit status 1 FAIL golang.org/x/build/cmd/updatestd 92.408s ``` It looks like the `go list` command failed, but I can't dig into it further because the `stderr` stream from the `go list` command is not logged. A good first step would probably be to update this test in line with https://go.dev/wiki/CodeReviewComments#useful-test-failures.",0,x build cmd updatestd test failures without useful output go list mod readonly m json all command failed exit status fail golang org x build cmd updatestd it looks like the go list command failed but i can t dig into it further because the stderr stream from the go list command is not logged a good first step would probably be to update this test in line with ,0 48765,7456980382.0,IssuesEvent,2018-03-30 00:57:42,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: improve documentation for DB.Close() (graceful close or not),Documentation,"The documentation doesn't make clear what DB.Close() does. Does it close the Pool immediately even if there are still queries happening in some of the connections, or does it wait for the queries to finish and gradually closes the connections and then closes the pool?",1.0,"database/sql: improve documentation for DB.Close() (graceful close or not) - The documentation doesn't make clear what DB.Close() does. Does it close the Pool immediately even if there are still queries happening in some of the connections, or does it wait for the queries to finish and gradually closes the connections and then closes the pool?",1,database sql improve documentation for db close graceful close or not the documentation doesn t make clear what db close does does it close the pool immediately even if there are still queries happening in some of the connections or does it wait for the queries to finish and gradually closes the connections and then closes the pool ,1 47021,7299398061.0,IssuesEvent,2018-02-26 19:59:25,golang/go,https://api.github.com/repos/golang/go,closed,archive/zip: improve Writer.Create documentation on how to add directories,Documentation NeedsFix help wanted,"I tried to add an empty folder to a zip.Writer with zip.Writer.Create. From the [docs](https://golang.org/pkg/archive/zip/#Writer.Create) it is not clear how to do this. There is a [google group post](https://groups.google.com/forum/#!topic/golang-nuts/Te0oScOV3KM) that provides the solution, which is to add a slash at the end of the path given to zip.Writer.Create. I suggest adding this detail to the documentation comment on zip.Writer.Create, e.g. ""... To create a folder instead of a file, add a trailing slash to the path."".",1.0,"archive/zip: improve Writer.Create documentation on how to add directories - I tried to add an empty folder to a zip.Writer with zip.Writer.Create. From the [docs](https://golang.org/pkg/archive/zip/#Writer.Create) it is not clear how to do this. There is a [google group post](https://groups.google.com/forum/#!topic/golang-nuts/Te0oScOV3KM) that provides the solution, which is to add a slash at the end of the path given to zip.Writer.Create. I suggest adding this detail to the documentation comment on zip.Writer.Create, e.g. ""... To create a folder instead of a file, add a trailing slash to the path."".",1,archive zip improve writer create documentation on how to add directories i tried to add an empty folder to a zip writer with zip writer create from the it is not clear how to do this there is a that provides the solution which is to add a slash at the end of the path given to zip writer create i suggest adding this detail to the documentation comment on zip writer create e g to create a folder instead of a file add a trailing slash to the path ,1 26966,5302645011.0,IssuesEvent,2017-02-10 13:40:23,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: Unmarshal to nil pointer documentation discrepancy,Documentation,"When trying to unmarshal a json string into a nil pointer, the operation fails as can be seen here: https://play.golang.org/p/wL6UDpaJ-h The error returned is InvalidUnmarshalError whose docs clearly state: ""The argument to Unmarshal must be a non-nil pointer."" (https://golang.org/pkg/encoding/json/#InvalidUnmarshalError) But the docs for the Unmarshal function state: ""Unmarshal unmarshals the JSON into the value pointed at by the pointer. If the pointer is nil, Unmarshal allocates a new value for it to point to."" (https://golang.org/pkg/encoding/json/#Unmarshal) Obviously, the behaviour implemented is the one from the error docs. Curiously, this works: https://play.golang.org/p/w-Sg24qcCo So, a reference to a nil pointer is accepted but the nil pointer itself is not. Anyone care to clarify? go1.7.4 darwin/amd64 ",1.0,"encoding/json: Unmarshal to nil pointer documentation discrepancy - When trying to unmarshal a json string into a nil pointer, the operation fails as can be seen here: https://play.golang.org/p/wL6UDpaJ-h The error returned is InvalidUnmarshalError whose docs clearly state: ""The argument to Unmarshal must be a non-nil pointer."" (https://golang.org/pkg/encoding/json/#InvalidUnmarshalError) But the docs for the Unmarshal function state: ""Unmarshal unmarshals the JSON into the value pointed at by the pointer. If the pointer is nil, Unmarshal allocates a new value for it to point to."" (https://golang.org/pkg/encoding/json/#Unmarshal) Obviously, the behaviour implemented is the one from the error docs. Curiously, this works: https://play.golang.org/p/w-Sg24qcCo So, a reference to a nil pointer is accepted but the nil pointer itself is not. Anyone care to clarify? go1.7.4 darwin/amd64 ",1,encoding json unmarshal to nil pointer documentation discrepancy when trying to unmarshal a json string into a nil pointer the operation fails as can be seen here the error returned is invalidunmarshalerror whose docs clearly state the argument to unmarshal must be a non nil pointer but the docs for the unmarshal function state unmarshal unmarshals the json into the value pointed at by the pointer if the pointer is nil unmarshal allocates a new value for it to point to obviously the behaviour implemented is the one from the error docs curiously this works so a reference to a nil pointer is accepted but the nil pointer itself is not anyone care to clarify darwin ,1 31006,5893901807.0,IssuesEvent,2017-05-17 23:31:27,golang/go,https://api.github.com/repos/golang/go,closed,doc: add IntelliJ Go editor guide,DevExp Documentation,"This is a tracking bug for an editor guide on IntelliJ Go, see #20398 . Create a brief info card based on the template at #20398 and create screencast for a few top features as 1280x640 gifs. /cc @dlsniper ",1.0,"doc: add IntelliJ Go editor guide - This is a tracking bug for an editor guide on IntelliJ Go, see #20398 . Create a brief info card based on the template at #20398 and create screencast for a few top features as 1280x640 gifs. /cc @dlsniper ",1,doc add intellij go editor guide this is a tracking bug for an editor guide on intellij go see create a brief info card based on the template at and create screencast for a few top features as gifs cc dlsniper ,1 55814,8031414597.0,IssuesEvent,2018-07-28 01:16:07,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: `go help mod` should mention `go help module`,Documentation NeedsFix modules,"go version devel +5f5402b Tue Jul 24 23:54:08 2018 +0000 linux/amd64 The help for `go help mod` should mention the existence of the modules help page which contains crucial information about GO111MODULE and how modules work. I didn't know that existed until I grepped for GO111 in the Go source tree and found that help text. Perhaps if #26581 was addressed, then the output of `go help mod` could be the same as that of `go help modules` now, as well as mentioning the subcommands.",1.0,"cmd/go: `go help mod` should mention `go help module` - go version devel +5f5402b Tue Jul 24 23:54:08 2018 +0000 linux/amd64 The help for `go help mod` should mention the existence of the modules help page which contains crucial information about GO111MODULE and how modules work. I didn't know that existed until I grepped for GO111 in the Go source tree and found that help text. Perhaps if #26581 was addressed, then the output of `go help mod` could be the same as that of `go help modules` now, as well as mentioning the subcommands.",1,cmd go go help mod should mention go help module go version devel tue jul linux the help for go help mod should mention the existence of the modules help page which contains crucial information about and how modules work i didn t know that existed until i grepped for in the go source tree and found that help text perhaps if was addressed then the output of go help mod could be the same as that of go help modules now as well as mentioning the subcommands ,1 47125,7307953166.0,IssuesEvent,2018-02-28 05:55:56,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go run: triggers Symantec malware alert.,Documentation,"### What version of Go are you using (`go version`)? `go version go1.9.4 windows/amd64` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\Users\-snip-\go set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config ``` ### What did you do? I ran the following program: ``` package main import ""fmt"" func main() { fmt.Println(""1 + 1 ="", 1 + 1) fmt.Println(""1 + 1 ="", 1.0 + 1.0) } ``` ### What did you expect to see? ``` 1 + 1 = 2 1 + 1 = 2 ``` ### What did you see instead? ``` exit status 3221225506 ``` Symantec got triggered. https://www.symantec.com/security_response/writeup.jsp?docid=2017-032721-5748-99&vid=4294924267",1.0,"cmd/go: go run: triggers Symantec malware alert. - ### What version of Go are you using (`go version`)? `go version go1.9.4 windows/amd64` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\Users\-snip-\go set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config ``` ### What did you do? I ran the following program: ``` package main import ""fmt"" func main() { fmt.Println(""1 + 1 ="", 1 + 1) fmt.Println(""1 + 1 ="", 1.0 + 1.0) } ``` ### What did you expect to see? ``` 1 + 1 = 2 1 + 1 = 2 ``` ### What did you see instead? ``` exit status 3221225506 ``` Symantec got triggered. https://www.symantec.com/security_response/writeup.jsp?docid=2017-032721-5748-99&vid=4294924267",1,cmd go go run triggers symantec malware alert what version of go are you using go version go version windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env set goarch set gobin set goexe exe set gohostarch set gohostos windows set goos windows set gopath c users snip go set gorace set goroot c go set gotooldir c go pkg tool windows set gccgo gccgo set cc gcc set gogccflags mthreads fmessage length set cxx g set cgo enabled set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config what did you do i ran the following program package main import fmt func main fmt println fmt println what did you expect to see what did you see instead exit status symantec got triggered ,1 22078,4771761463.0,IssuesEvent,2016-10-26 18:55:03,golang/go,https://api.github.com/repos/golang/go,opened,net: no docs about the behavior of announcing or listening on IP dual stack,Documentation,"I asked several times on golang-nuts, golang-dev or golang-codereviews like the following: https://groups.google.com/d/msg/golang-dev/MvAlef3CTqk/DGs5sLBcCgAJ ",1.0,"net: no docs about the behavior of announcing or listening on IP dual stack - I asked several times on golang-nuts, golang-dev or golang-codereviews like the following: https://groups.google.com/d/msg/golang-dev/MvAlef3CTqk/DGs5sLBcCgAJ ",1,net no docs about the behavior of announcing or listening on ip dual stack i asked several times on golang nuts golang dev or golang codereviews like the following ,1 65560,8819660880.0,IssuesEvent,2018-12-31 22:49:20,golang/go,https://api.github.com/repos/golang/go,closed,strconv: Atoi documentation is slightly misleading,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version 1.11.4
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? Irrelevant.
go env Output
$ go env
### What did you do? Look at the documentation here: https://golang.org/src/strconv/atoi.go?s=5013:5045#L192 ### What did you expect to see? An explanation of `strconv.Atoi` that matched what it actually did. ### What did you see instead? An explanation that is only half true. `Atoi returns the result of ParseInt(s, 10, 0) converted to type int.` It appears that `Atoi` doesn't just return the value of `ParseInt(s, 10, 0)`, it only calls `ParseInt` as a last alternative, the ""slow path"". Without checking the code I was under the belief that I could just replace `Atoi` with `ParseInt` and it would basically run the exact same code. It appears that the documentation was correct up until this commit: https://github.com/golang/go/commit/46aa9f5437b000fad3696b0cd9fd97995da16411#diff-cbef0f4cdbfb7c355433bb342a5ef463",1.0,"strconv: Atoi documentation is slightly misleading - ### What version of Go are you using (`go version`)? 
$ go version 1.11.4
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? Irrelevant.
go env Output
$ go env
### What did you do? Look at the documentation here: https://golang.org/src/strconv/atoi.go?s=5013:5045#L192 ### What did you expect to see? An explanation of `strconv.Atoi` that matched what it actually did. ### What did you see instead? An explanation that is only half true. `Atoi returns the result of ParseInt(s, 10, 0) converted to type int.` It appears that `Atoi` doesn't just return the value of `ParseInt(s, 10, 0)`, it only calls `ParseInt` as a last alternative, the ""slow path"". Without checking the code I was under the belief that I could just replace `Atoi` with `ParseInt` and it would basically run the exact same code. It appears that the documentation was correct up until this commit: https://github.com/golang/go/commit/46aa9f5437b000fad3696b0cd9fd97995da16411#diff-cbef0f4cdbfb7c355433bb342a5ef463",1,strconv atoi documentation is slightly misleading what version of go are you using go version go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env irrelevant go env output go env what did you do look at the documentation here if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see an explanation of strconv atoi that matched what it actually did what did you see instead an explanation that is only half true atoi returns the result of parseint s converted to type int it appears that atoi doesn t just return the value of parseint s it only calls parseint as a last alternative the slow path without checking the code i was under the belief that i could just replace atoi with parseint and it would basically run the exact same code it appears that the documentation was correct up until this commit ,1 11703,3516782940.0,IssuesEvent,2016-01-12 01:56:40,golang/go,https://api.github.com/repos/golang/go,closed,doc: $GOPATH is opaque even if you find the doc,Documentation,"Rick and Austin both ran into problems with trying to set up $GOPATH. They both found https://golang.org/doc/code.html but it didn't help either of them. Perhaps the doc should start out more prescriptive and only _then_ move into the description of what a workspace is. Also, the recipe given uses $HOME/go as $GOPATH, which is just about the worst possible suggestion, because it's where we tell people to check out Go trees in http://golang.org/doc/install/source. This doc should probably use $HOME/work. People will be able to figure out how to generalize to other values of 'work'. It looks like all the necessary information _is_ in the doc, it's just too hard to find if you're skimming trying to solve a problem. Maybe there should be a short intro that hits the highlights: (1) mkdir $HOME/work; export GOPATH=$HOME/work; export PATH=$GOPATH/bin:$PATH (2) Your own work goes in $GOPATH/src/github.com/you/project. Your version control applies to that subdirectory tree, not to all of $GOPATH. and then the rest of the doc can elaborate. @adg @aclements @rlh ",1.0,"doc: $GOPATH is opaque even if you find the doc - Rick and Austin both ran into problems with trying to set up $GOPATH. They both found https://golang.org/doc/code.html but it didn't help either of them. Perhaps the doc should start out more prescriptive and only _then_ move into the description of what a workspace is. Also, the recipe given uses $HOME/go as $GOPATH, which is just about the worst possible suggestion, because it's where we tell people to check out Go trees in http://golang.org/doc/install/source. This doc should probably use $HOME/work. People will be able to figure out how to generalize to other values of 'work'. It looks like all the necessary information _is_ in the doc, it's just too hard to find if you're skimming trying to solve a problem. Maybe there should be a short intro that hits the highlights: (1) mkdir $HOME/work; export GOPATH=$HOME/work; export PATH=$GOPATH/bin:$PATH (2) Your own work goes in $GOPATH/src/github.com/you/project. Your version control applies to that subdirectory tree, not to all of $GOPATH. and then the rest of the doc can elaborate. @adg @aclements @rlh ",1,doc gopath is opaque even if you find the doc rick and austin both ran into problems with trying to set up gopath they both found but it didn t help either of them perhaps the doc should start out more prescriptive and only then move into the description of what a workspace is also the recipe given uses home go as gopath which is just about the worst possible suggestion because it s where we tell people to check out go trees in this doc should probably use home work people will be able to figure out how to generalize to other values of work it looks like all the necessary information is in the doc it s just too hard to find if you re skimming trying to solve a problem maybe there should be a short intro that hits the highlights mkdir home work export gopath home work export path gopath bin path your own work goes in gopath src github com you project your version control applies to that subdirectory tree not to all of gopath and then the rest of the doc can elaborate adg aclements rlh ,1 160654,20115839210.0,IssuesEvent,2022-02-07 19:25:18,golang/go,https://api.github.com/repos/golang/go,closed,crypto/elliptic: IsOnCurve returns true for invalid field elements [1.17 backport],Security CherryPickApproved,"@FiloSottile requested issue #50974 to be considered for backport to the next 1.17 minor release. > @gopherbot please open backport issues for this security fix. /cc @golang/security ",True,"crypto/elliptic: IsOnCurve returns true for invalid field elements [1.17 backport] - @FiloSottile requested issue #50974 to be considered for backport to the next 1.17 minor release. > @gopherbot please open backport issues for this security fix. /cc @golang/security ",0,crypto elliptic isoncurve returns true for invalid field elements filosottile requested issue to be considered for backport to the next minor release gopherbot please open backport issues for this security fix cc golang security ,0 91778,26485993975.0,IssuesEvent,2023-01-17 18:04:12,golang/go,https://api.github.com/repos/golang/go,closed,x/build: darwin-arm64 builders will be unavailable during maintenance period,OS-Darwin Builders NeedsFix Soon,"The darwin builders hosted on `host-darwin-arm64-11` and `host-darwin-arm64-12` will be unavailable while they are being migrated to a different location. This maintenance is scheduled for 2021-01-17 between 20:00 and 22:00 UTC. @golang/release ",1.0,"x/build: darwin-arm64 builders will be unavailable during maintenance period - The darwin builders hosted on `host-darwin-arm64-11` and `host-darwin-arm64-12` will be unavailable while they are being migrated to a different location. This maintenance is scheduled for 2021-01-17 between 20:00 and 22:00 UTC. @golang/release ",0,x build darwin builders will be unavailable during maintenance period the darwin builders hosted on host darwin and host darwin will be unavailable while they are being migrated to a different location this maintenance is scheduled for between and utc golang release ,0 336487,24500986904.0,IssuesEvent,2022-10-10 12:47:33,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: textDocument/definition is slow in large codebase,Documentation NeedsInvestigation gopls Tools," ### gopls version ``` golang.org/x/tools/gopls v0.9.4 golang.org/x/tools/gopls@v0.9.4 h1:YhHOxVi++ILnY+QnH9FGtRKZZrunSaR7OW8/dCp7bBk= github.com/BurntSushi/toml@v1.2.0 h1:Rt8g24XnyGTyglgET/PRUNlrUeu9F5L+7FilkXfZgs0= github.com/google/go-cmp@v0.5.8 h1:e6P7q2lk1O+qJJb4BtCQXlK8vWEO8V1ZeuEdJNOqZyg= github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= golang.org/x/exp/typeparams@v0.0.0-20220722155223-a9213eeb770e h1:7Xs2YCOpMlNqSQSmrrnhlzBXIE/bpMecZplbLePTJvE= golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s= golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4 h1:uVc8UZUe6tr40fFVnUP5Oj+veunVezqYl9z7DYw9xzw= golang.org/x/sys@v0.0.0-20220722155257-8c9f86f7a55f h1:v4INt8xihDGvnrfjMDVXGxw9wrfxYyCjk0KbXjhR55s= golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk= golang.org/x/tools@v0.1.13-0.20220812184215-3f9b119300de h1:b68wxF4nfQjj1XTRHtjVjCximbhAwjztuzDEFGU+n9o= honnef.co/go/tools@v0.3.2 h1:ytYb4rOqyp1TSa2EPvNVwtPQJctSELKaMyLfqNP4+34= mvdan.cc/gofumpt@v0.3.1 h1:avhhrOmv0IuvQVK7fvwV91oFSGAk5/6Po8GXTzICeu8= mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc= go: go1.17.6 ``` ### go env ``` GO111MODULE=""on"" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/ubuntu/.cache/go-build"" GOENV=""/home/ubuntu/.config/go/env"" GOEXE="""" GOEXPERIMENT="""" GOFLAGS=""-mod=readonly"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOINSECURE="""" GOMODCACHE=""/home/ubuntu/co/backend/go/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""linux"" GOPATH=""/home/ubuntu/co/backend/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/home/ubuntu/co/backend/opt/go1.17.6"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/home/ubuntu/co/backend/opt/go1.17.6/pkg/tool/linux_amd64"" GOVCS="""" GOVERSION=""go1.17.6"" 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-build457205370=/tmp/go-build -gno-record-gcc-switches"" ``` # What Happened I noticed that `go-to-definition` in vscode on a go file was taking a long time, and consistently saw the following log when navigating within a package (specifically, I was using go to definition to navigate within a package. I'm operating within a large monorepo, with some heavily interlinked packages) ``` [Trace - 23:17:36.892 PM] Received response 'textDocument/definition - (213)' in 11214ms. ``` I pulled up the ""Trace Information"" tab in the debug server, and found a log for `textDocument/Definition` RPC. This log looks to consist of `cache.parseGo` and `cache.TypeCheck` events, but many of these events are replicated, seemly indicating that duplicate work is build done. I see multiple packages being parsed many times (up to ~20, looks to be dependent on imports), with all of its files listed underneath ``` 0s textDocument/definition 13.862321388s start=""textDocument/definition"" method=""textDocument/definition"" direction=""in"" id=""#20"" 13.862319081s label= status.code=""OK"" 74.474µs queued 27.786µs start=""queued"" 178.05µs source.Identifier 13.861909568s start=""source.Identifier"" ... 3.12062168s cache.typeCheck 192.827411ms start=""cache.typeCheck"" package=""foo [bar.test]"" 3.120790449s cache.parseGo 196.421µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... 3.590160298s cache.typeCheck 317.260966ms start=""cache.typeCheck"" package=""foo [baz.test]"" 3.590357772s cache.parseGo 274.427µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... 5.043508487s cache.typeCheck 175.931042ms start=""cache.typeCheck"" package=""foo [foo2.test]"" 5.492814972s cache.parseGo 351.925µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... ``` Appears that there's duplicate work being done - I looked through the codebase for these events and found many todos added in https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320. (eg [a](https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320#diff-e230acde030eabf6ec5a1c93adfd0517b7d7eca5f5246f383ea510b752f3b703R475) [b](https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320#diff-e230acde030eabf6ec5a1c93adfd0517b7d7eca5f5246f383ea510b752f3b703R577)). Is there any planned work to speed up the `cache.typeCheck` and `cache.parseGo` operations? Happy to DM the full trace file to someone if that would help!",1.0,"x/tools/gopls: textDocument/definition is slow in large codebase - ### gopls version ``` golang.org/x/tools/gopls v0.9.4 golang.org/x/tools/gopls@v0.9.4 h1:YhHOxVi++ILnY+QnH9FGtRKZZrunSaR7OW8/dCp7bBk= github.com/BurntSushi/toml@v1.2.0 h1:Rt8g24XnyGTyglgET/PRUNlrUeu9F5L+7FilkXfZgs0= github.com/google/go-cmp@v0.5.8 h1:e6P7q2lk1O+qJJb4BtCQXlK8vWEO8V1ZeuEdJNOqZyg= github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0= golang.org/x/exp/typeparams@v0.0.0-20220722155223-a9213eeb770e h1:7Xs2YCOpMlNqSQSmrrnhlzBXIE/bpMecZplbLePTJvE= golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s= golang.org/x/sync@v0.0.0-20220722155255-886fb9371eb4 h1:uVc8UZUe6tr40fFVnUP5Oj+veunVezqYl9z7DYw9xzw= golang.org/x/sys@v0.0.0-20220722155257-8c9f86f7a55f h1:v4INt8xihDGvnrfjMDVXGxw9wrfxYyCjk0KbXjhR55s= golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk= golang.org/x/tools@v0.1.13-0.20220812184215-3f9b119300de h1:b68wxF4nfQjj1XTRHtjVjCximbhAwjztuzDEFGU+n9o= honnef.co/go/tools@v0.3.2 h1:ytYb4rOqyp1TSa2EPvNVwtPQJctSELKaMyLfqNP4+34= mvdan.cc/gofumpt@v0.3.1 h1:avhhrOmv0IuvQVK7fvwV91oFSGAk5/6Po8GXTzICeu8= mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc= go: go1.17.6 ``` ### go env ``` GO111MODULE=""on"" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/ubuntu/.cache/go-build"" GOENV=""/home/ubuntu/.config/go/env"" GOEXE="""" GOEXPERIMENT="""" GOFLAGS=""-mod=readonly"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOINSECURE="""" GOMODCACHE=""/home/ubuntu/co/backend/go/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""linux"" GOPATH=""/home/ubuntu/co/backend/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/home/ubuntu/co/backend/opt/go1.17.6"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/home/ubuntu/co/backend/opt/go1.17.6/pkg/tool/linux_amd64"" GOVCS="""" GOVERSION=""go1.17.6"" 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-build457205370=/tmp/go-build -gno-record-gcc-switches"" ``` # What Happened I noticed that `go-to-definition` in vscode on a go file was taking a long time, and consistently saw the following log when navigating within a package (specifically, I was using go to definition to navigate within a package. I'm operating within a large monorepo, with some heavily interlinked packages) ``` [Trace - 23:17:36.892 PM] Received response 'textDocument/definition - (213)' in 11214ms. ``` I pulled up the ""Trace Information"" tab in the debug server, and found a log for `textDocument/Definition` RPC. This log looks to consist of `cache.parseGo` and `cache.TypeCheck` events, but many of these events are replicated, seemly indicating that duplicate work is build done. I see multiple packages being parsed many times (up to ~20, looks to be dependent on imports), with all of its files listed underneath ``` 0s textDocument/definition 13.862321388s start=""textDocument/definition"" method=""textDocument/definition"" direction=""in"" id=""#20"" 13.862319081s label= status.code=""OK"" 74.474µs queued 27.786µs start=""queued"" 178.05µs source.Identifier 13.861909568s start=""source.Identifier"" ... 3.12062168s cache.typeCheck 192.827411ms start=""cache.typeCheck"" package=""foo [bar.test]"" 3.120790449s cache.parseGo 196.421µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... 3.590160298s cache.typeCheck 317.260966ms start=""cache.typeCheck"" package=""foo [baz.test]"" 3.590357772s cache.parseGo 274.427µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... 5.043508487s cache.typeCheck 175.931042ms start=""cache.typeCheck"" package=""foo [foo2.test]"" 5.492814972s cache.parseGo 351.925µs start=""cache.parseGo"" file=""foo/file_a.go"" .... ... ... ``` Appears that there's duplicate work being done - I looked through the codebase for these events and found many todos added in https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320. (eg [a](https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320#diff-e230acde030eabf6ec5a1c93adfd0517b7d7eca5f5246f383ea510b752f3b703R475) [b](https://github.com/golang/tools/commit/f79f3aac190554ef62f0257555394b31c29f0320#diff-e230acde030eabf6ec5a1c93adfd0517b7d7eca5f5246f383ea510b752f3b703R577)). Is there any planned work to speed up the `cache.typeCheck` and `cache.parseGo` operations? Happy to DM the full trace file to someone if that would help!",1,x tools gopls textdocument definition is slow in large codebase please answer these questions before submitting your issue thanks gopls version golang org x tools gopls golang org x tools gopls yhhoxvi ilny github com burntsushi toml github com google go cmp github com sergi go diff golang org x exp typeparams bpmeczplbleptjve golang org x mod dev golang org x sync golang org x sys golang org x text golang org x tools honnef co go tools mvdan cc gofumpt mvdan cc xurls tzxjvaj go go env on goarch gobin gocache home ubuntu cache go build goenv home ubuntu config go env goexe goexperiment goflags mod readonly gohostarch gohostos linux goinsecure gomodcache home ubuntu co backend go pkg mod gonoproxy gonosumdb goos linux gopath home ubuntu co backend go goprivate goproxy goroot home ubuntu co backend opt gosumdb sum golang org gotmpdir gotooldir home ubuntu co backend opt pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what happened i noticed that go to definition in vscode on a go file was taking a long time and consistently saw the following log when navigating within a package specifically i was using go to definition to navigate within a package i m operating within a large monorepo with some heavily interlinked packages received response textdocument definition in i pulled up the trace information tab in the debug server and found a log for textdocument definition rpc this log looks to consist of cache parsego and cache typecheck events but many of these events are replicated seemly indicating that duplicate work is build done i see multiple packages being parsed many times up to looks to be dependent on imports with all of its files listed underneath textdocument definition start textdocument definition method textdocument definition direction in id label status code ok queued start queued source identifier start source identifier cache typecheck start cache typecheck package foo cache parsego start cache parsego file foo file a go cache typecheck start cache typecheck package foo cache parsego start cache parsego file foo file a go cache typecheck start cache typecheck package foo cache parsego start cache parsego file foo file a go appears that there s duplicate work being done i looked through the codebase for these events and found many todos added in eg is there any planned work to speed up the cache typecheck and cache parsego operations happy to dm the full trace file to someone if that would help ,1 32561,6086592786.0,IssuesEvent,2017-06-18 03:04:18,golang/go,https://api.github.com/repos/golang/go,opened,Unusual code in proc.go could use documentation,Documentation,"### What version of Go are you using (`go version`)? go version devel +d293c85e39 Sat Jun 17 08:17:14 2017 +0000 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? ```GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/velovix/go"" GORACE="""" GOROOT=""/home/velovix/go-source"" GOTOOLDIR=""/home/velovix/go-source/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build407292918=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` Please see this discussion on golang-nuts: https://groups.google.com/d/topic/golang-nuts/FnF3oZeJ7aY/discussion There is some code at lines 198-202 in `/src/runtime/proc.go` that could do with a bit of documentation. The code in question can be found [here](https://github.com/golang/go/blob/df0892cbf854e76fae6e875043b05c194e37f52d/src/runtime/proc.go#L208) on Github. Here is my current draft: ``` // In case exit fails to stop the program, try to stop it by causing a // panic. If that doesn't work, stall the program. // This is here to help catch problems with new ports, where exit may not // be properly implemented. ``` I will send in a CL if that looks okay.",1.0,"Unusual code in proc.go could use documentation - ### What version of Go are you using (`go version`)? go version devel +d293c85e39 Sat Jun 17 08:17:14 2017 +0000 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? ```GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/velovix/go"" GORACE="""" GOROOT=""/home/velovix/go-source"" GOTOOLDIR=""/home/velovix/go-source/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build407292918=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` Please see this discussion on golang-nuts: https://groups.google.com/d/topic/golang-nuts/FnF3oZeJ7aY/discussion There is some code at lines 198-202 in `/src/runtime/proc.go` that could do with a bit of documentation. The code in question can be found [here](https://github.com/golang/go/blob/df0892cbf854e76fae6e875043b05c194e37f52d/src/runtime/proc.go#L208) on Github. Here is my current draft: ``` // In case exit fails to stop the program, try to stop it by causing a // panic. If that doesn't work, stall the program. // This is here to help catch problems with new ports, where exit may not // be properly implemented. ``` I will send in a CL if that looks okay.",1,unusual code in proc go could use documentation what version of go are you using go version go version devel sat jun linux what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath home velovix go gorace goroot home velovix go source gotooldir home velovix go source pkg tool linux gccgo gccgo cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config please see this discussion on golang nuts there is some code at lines in src runtime proc go that could do with a bit of documentation the code in question can be found on github here is my current draft in case exit fails to stop the program try to stop it by causing a panic if that doesn t work stall the program this is here to help catch problems with new ports where exit may not be properly implemented i will send in a cl if that looks okay ,1 272950,20764837320.0,IssuesEvent,2022-03-15 19:38:09,golang/go,https://api.github.com/repos/golang/go,closed,x/website: FAQ needs to have a preamble re: generics,Documentation NeedsFix early-in-cycle release-blocker,The [FAQ](https://go.dev/doc/faq) need to be updated with a preamble/disclaimer as it was not written with generics in mind.,1.0,x/website: FAQ needs to have a preamble re: generics - The [FAQ](https://go.dev/doc/faq) need to be updated with a preamble/disclaimer as it was not written with generics in mind.,1,x website faq needs to have a preamble re generics the need to be updated with a preamble disclaimer as it was not written with generics in mind ,1 26813,5289694231.0,IssuesEvent,2017-02-08 17:59:40,golang/go,https://api.github.com/repos/golang/go,closed,crypto/tls: session resumption (session id caching),Documentation,"### What version of Go are you using (`go version`)? `go version go1.7.4 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ``` ### What did you do? I have 2 web servers, one that supports TLS session resumption based on a session cache and another that supports session cache and session tickets. https://play.golang.org/p/9n4OZRjqHh ### What did you expect to see? I had expected the 2nd connection to each server to resume the session. ### What did you see instead? `DidResume` is only `true` for the server that supports session _ticket_ resumption. It appears that session ID caching is not supported in client or server mode. Perhaps the documentation for `ClientSessionCache` could be a bit more explicit that it is only a cache for session tickets.",1.0,"crypto/tls: session resumption (session id caching) - ### What version of Go are you using (`go version`)? `go version go1.7.4 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ``` ### What did you do? I have 2 web servers, one that supports TLS session resumption based on a session cache and another that supports session cache and session tickets. https://play.golang.org/p/9n4OZRjqHh ### What did you expect to see? I had expected the 2nd connection to each server to resume the session. ### What did you see instead? `DidResume` is only `true` for the server that supports session _ticket_ resumption. It appears that session ID caching is not supported in client or server mode. Perhaps the documentation for `ClientSessionCache` could be a bit more explicit that it is only a cache for session tickets.",1,crypto tls session resumption session id caching what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin what did you do i have web servers one that supports tls session resumption based on a session cache and another that supports session cache and session tickets what did you expect to see i had expected the connection to each server to resume the session what did you see instead didresume is only true for the server that supports session ticket resumption it appears that session id caching is not supported in client or server mode perhaps the documentation for clientsessioncache could be a bit more explicit that it is only a cache for session tickets ,1 278393,21076126545.0,IssuesEvent,2022-04-02 06:49:18,golang/go,https://api.github.com/repos/golang/go,closed,strings: Document use of simple case-folding in EqualFold ,Documentation help wanted NeedsFix,"At the moment, the documentation for [`EqualFold`](https://pkg.go.dev/strings#EqualFold) says: > EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under Unicode case-folding, which is a more general form of case-insensitivity. However, this is under-specified. `EqualFold` uses simple case-folding, not full case-folding, which can be surprising. For example, Python 3 and Swift default to full case folding: ``` $ python3 > ""ß"".casefold() 'ss' $ swift > import Foundation > ""ß"".folding(options: [.caseInsensitive], locale: nil) $R0: String = ""ss"" ``` I think it would be better to explicitly state that simple case-folding is being used. Perhaps something like: ``` EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under simple Unicode case-folding, which is a more general form of case-insensitivity. For more information, see https://www.unicode.org/Public/UNIDATA/CaseFolding.txt. In general, EqualFold(s1, s2) == (ToLower(s1) == ToLower(s2)). ``` Perhaps it would be also helpful to have an example like: ```go func ExampleEqualFold() { fmt.Println(strings.EqualFold(""AB"", ""ab"")) // true because comparison uses simple case-folding fmt.Println(strings.EqualFold(""ß"", ""ss"")) // false because comparison does not use full case-folding // Output: true // Output: false } ``` One can also add a fuzz test if so desired: ```go func FuzzEqualFold(f *testing.F) { f.Fuzz(func(t *testing.T, s1 string, s2 string) { lower := strings.ToLower(s1) == strings.ToLower(s2) equalFold := strings.EqualFold(s1, s2) if lower != equalFold { t.Fatalf(""mismatch between ToLower and EqualFold: s1 = %s, s2 = %s, via Lower = %v, via EqualFold = %v"", s1, s2, lower, equalFold) } ) } ```",1.0,"strings: Document use of simple case-folding in EqualFold - At the moment, the documentation for [`EqualFold`](https://pkg.go.dev/strings#EqualFold) says: > EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under Unicode case-folding, which is a more general form of case-insensitivity. However, this is under-specified. `EqualFold` uses simple case-folding, not full case-folding, which can be surprising. For example, Python 3 and Swift default to full case folding: ``` $ python3 > ""ß"".casefold() 'ss' $ swift > import Foundation > ""ß"".folding(options: [.caseInsensitive], locale: nil) $R0: String = ""ss"" ``` I think it would be better to explicitly state that simple case-folding is being used. Perhaps something like: ``` EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under simple Unicode case-folding, which is a more general form of case-insensitivity. For more information, see https://www.unicode.org/Public/UNIDATA/CaseFolding.txt. In general, EqualFold(s1, s2) == (ToLower(s1) == ToLower(s2)). ``` Perhaps it would be also helpful to have an example like: ```go func ExampleEqualFold() { fmt.Println(strings.EqualFold(""AB"", ""ab"")) // true because comparison uses simple case-folding fmt.Println(strings.EqualFold(""ß"", ""ss"")) // false because comparison does not use full case-folding // Output: true // Output: false } ``` One can also add a fuzz test if so desired: ```go func FuzzEqualFold(f *testing.F) { f.Fuzz(func(t *testing.T, s1 string, s2 string) { lower := strings.ToLower(s1) == strings.ToLower(s2) equalFold := strings.EqualFold(s1, s2) if lower != equalFold { t.Fatalf(""mismatch between ToLower and EqualFold: s1 = %s, s2 = %s, via Lower = %v, via EqualFold = %v"", s1, s2, lower, equalFold) } ) } ```",1,strings document use of simple case folding in equalfold at the moment the documentation for says equalfold reports whether s and t interpreted as utf strings are equal under unicode case folding which is a more general form of case insensitivity however this is under specified equalfold uses simple case folding not full case folding which can be surprising for example python and swift default to full case folding ß casefold ss swift import foundation ß folding options locale nil string ss i think it would be better to explicitly state that simple case folding is being used perhaps something like equalfold reports whether s and t interpreted as utf strings are equal under simple unicode case folding which is a more general form of case insensitivity for more information see in general equalfold tolower tolower perhaps it would be also helpful to have an example like go func exampleequalfold fmt println strings equalfold ab ab true because comparison uses simple case folding fmt println strings equalfold ß ss false because comparison does not use full case folding output true output false one can also add a fuzz test if so desired go func fuzzequalfold f testing f f fuzz func t testing t string string lower strings tolower strings tolower equalfold strings equalfold if lower equalfold t fatalf mismatch between tolower and equalfold s s via lower v via equalfold v lower equalfold ,1 69695,9321396990.0,IssuesEvent,2019-03-27 03:42:15,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document that gofiles on command line must be in same directory,Documentation GoCommand NeedsFix help wanted,"### What version of Go are you using (`go version`)? `go version go1.9rc2 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)?

``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build182434083=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ```
### What did you do? I read https://golang.org/cmd/go/#hdr-Compile_and_run_Go_program, it said: > Usage: > > go run [build flags] [-exec xprog] gofiles... [arguments...] > > Run compiles and runs the main package comprising the named Go source files. **A Go source file is defined to be a file ending in a literal "".go"" suffix.** > > [more details that are not relevant] Notice there are no restrictions on the prefix of the file, what directory it's in, or what build constraints the file has. Then I ran: ```bash mkdir -p $GOPATH/src/new/package cd $GOPATH/src/new/package echo 'package main; import ""fmt""; func main() { fmt.Println(""go"") }' > main.go go run main.go mv main.go 123.go go run 123.go mv 123.go _underscore.go go run _underscore.go mv _underscore.go .dot.go go run .dot.go mv .dot.go thisis.notgo go run thisis.notgo rm thisis.notgo go run ``` (Credit goes to @natefinch for discovering this at https://twitter.com/NateTheFinch/status/898585298111787009.) ### What did you expect to see? ``` go go go go go run: no go files listed go run: no go files listed ``` ### What did you see instead? ``` go go package main: no Go files in /Users/Gopher/go/src/new/package package main: no Go files in /Users/Gopher/go/src/new/package go run: no go files listed go run: no go files listed ``` It looks like the .go file starting with _ or . gets ignored, probably related to the logic `go/build` has to ignore files beginning with _ and . in normal Go packages. **Edit:** Upon further reading, I think this section from https://golang.org/cmd/go/#hdr-Description_of_package_lists applies and explains the behavior: > As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory. > > Directory and file names that begin with ""."" or ""_"" are ignored by the go tool, as are directories named ""testdata"".",1.0,"cmd/go: document that gofiles on command line must be in same directory - ### What version of Go are you using (`go version`)? `go version go1.9rc2 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)?

``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build182434083=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ```
### What did you do? I read https://golang.org/cmd/go/#hdr-Compile_and_run_Go_program, it said: > Usage: > > go run [build flags] [-exec xprog] gofiles... [arguments...] > > Run compiles and runs the main package comprising the named Go source files. **A Go source file is defined to be a file ending in a literal "".go"" suffix.** > > [more details that are not relevant] Notice there are no restrictions on the prefix of the file, what directory it's in, or what build constraints the file has. Then I ran: ```bash mkdir -p $GOPATH/src/new/package cd $GOPATH/src/new/package echo 'package main; import ""fmt""; func main() { fmt.Println(""go"") }' > main.go go run main.go mv main.go 123.go go run 123.go mv 123.go _underscore.go go run _underscore.go mv _underscore.go .dot.go go run .dot.go mv .dot.go thisis.notgo go run thisis.notgo rm thisis.notgo go run ``` (Credit goes to @natefinch for discovering this at https://twitter.com/NateTheFinch/status/898585298111787009.) ### What did you expect to see? ``` go go go go go run: no go files listed go run: no go files listed ``` ### What did you see instead? ``` go go package main: no Go files in /Users/Gopher/go/src/new/package package main: no Go files in /Users/Gopher/go/src/new/package go run: no go files listed go run: no go files listed ``` It looks like the .go file starting with _ or . gets ignored, probably related to the logic `go/build` has to ignore files beginning with _ and . in normal Go packages. **Edit:** Upon further reading, I think this section from https://golang.org/cmd/go/#hdr-Description_of_package_lists applies and explains the behavior: > As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory. > > Directory and file names that begin with ""."" or ""_"" are ignored by the go tool, as are directories named ""testdata"".",1,cmd go document that gofiles on command line must be in same directory what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users dmitri dropbox work golanding users dmitri dropbox work goland gorace goroot usr local go gotooldir usr local go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders tw t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config what did you do i read it said usage go run gofiles run compiles and runs the main package comprising the named go source files a go source file is defined to be a file ending in a literal go suffix notice there are no restrictions on the prefix of the file what directory it s in or what build constraints the file has then i ran bash mkdir p gopath src new package cd gopath src new package echo package main import fmt func main fmt println go main go go run main go mv main go go go run go mv go underscore go go run underscore go mv underscore go dot go go run dot go mv dot go thisis notgo go run thisis notgo rm thisis notgo go run credit goes to natefinch for discovering this at what did you expect to see go go go go go run no go files listed go run no go files listed what did you see instead go go package main no go files in users gopher go src new package package main no go files in users gopher go src new package go run no go files listed go run no go files listed it looks like the go file starting with or gets ignored probably related to the logic go build has to ignore files beginning with and in normal go packages edit upon further reading i think this section from applies and explains the behavior as a special case if the package list is a list of go files from a single directory the command is applied to a single synthesized package made up of exactly those files ignoring any build constraints in those files and ignoring any other files in the directory directory and file names that begin with or are ignored by the go tool as are directories named testdata ,1 44714,7125828430.0,IssuesEvent,2018-01-20 01:58:53,golang/go,https://api.github.com/repos/golang/go,closed,doc: unclear if maps are ok for concurrent reads,Documentation,"It isn't specified anywhere in the docs if concurrent reads from a map (or any other type for that matter) are ok in Go. While this may be obvious to some, it would be good to put it somewhere. Potential candidates: https://golang.org/ref/mem https://golang.org/doc/faq#atomic_maps Some context: https://groups.google.com/forum/m/#!topic/golang-nuts/3FVAs9dPR8k",1.0,"doc: unclear if maps are ok for concurrent reads - It isn't specified anywhere in the docs if concurrent reads from a map (or any other type for that matter) are ok in Go. While this may be obvious to some, it would be good to put it somewhere. Potential candidates: https://golang.org/ref/mem https://golang.org/doc/faq#atomic_maps Some context: https://groups.google.com/forum/m/#!topic/golang-nuts/3FVAs9dPR8k",1,doc unclear if maps are ok for concurrent reads it isn t specified anywhere in the docs if concurrent reads from a map or any other type for that matter are ok in go while this may be obvious to some it would be good to put it somewhere potential candidates some context ,1 64006,8705368795.0,IssuesEvent,2018-12-05 22:11:23,golang/go,https://api.github.com/repos/golang/go,closed,doc: add release notes for go run supporting for 'go run pkg' or 'go run .',Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ```bash GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GORACE="""" GOROOT=""/usr/local/go"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build166682806=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? navigated to https://tip.golang.org/doc/go1.11 ### What did you expect to see? release notes about `go run` now having support for `go run pkg` or `go run .` ### What did you see instead? nothing on that topic ref: - https://github.com/golang/go/issues/22726 ",1.0,"doc: add release notes for go run supporting for 'go run pkg' or 'go run .' - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ```bash GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GORACE="""" GOROOT=""/usr/local/go"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build166682806=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? navigated to https://tip.golang.org/doc/go1.11 ### What did you expect to see? release notes about `go run` now having support for `go run pkg` or `go run .` ### What did you see instead? nothing on that topic ref: - https://github.com/golang/go/issues/22726 ",1,doc add release notes for go run supporting for go run pkg or go run please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env bash goarch gohostarch gohostos linux goos linux gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do navigated to what did you expect to see release notes about go run now having support for go run pkg or go run what did you see instead nothing on that topic ref ,1 191571,15297575146.0,IssuesEvent,2021-02-24 08:36:59,golang/go,https://api.github.com/repos/golang/go,closed,hash/maphash: typo in the documentation of Hash,Documentation NeedsFix,"The word Seed appears twice, want once. https://github.com/golang/go/blob/66c27093d0df8be8a75b1ae35fe4ab2003fe028e/src/hash/maphash/maphash.go#L37 https://golang.org/pkg/hash/maphash/#Hash",1.0,"hash/maphash: typo in the documentation of Hash - The word Seed appears twice, want once. https://github.com/golang/go/blob/66c27093d0df8be8a75b1ae35fe4ab2003fe028e/src/hash/maphash/maphash.go#L37 https://golang.org/pkg/hash/maphash/#Hash",1,hash maphash typo in the documentation of hash the word seed appears twice want once ,1 103377,11355142859.0,IssuesEvent,2020-01-24 19:19:29,golang/go,https://api.github.com/repos/golang/go,opened,doc/go1.14: GOINSECURE needs a release note,Documentation release-blocker,"I was reading through https://nullprogram.com/blog/2020/01/21l (via Golang Weekly) and realized that we forgot to add a release note for #32966. `GOINSECURE` is a nice feature for local development, so we should make sure it is mentioned in the release notes.",1.0,"doc/go1.14: GOINSECURE needs a release note - I was reading through https://nullprogram.com/blog/2020/01/21l (via Golang Weekly) and realized that we forgot to add a release note for #32966. `GOINSECURE` is a nice feature for local development, so we should make sure it is mentioned in the release notes.",1,doc goinsecure needs a release note i was reading through via golang weekly and realized that we forgot to add a release note for goinsecure is a nice feature for local development so we should make sure it is mentioned in the release notes ,1 400037,27266359620.0,IssuesEvent,2023-02-22 18:21:39,golang/go,https://api.github.com/repos/golang/go,opened,doc: write release notes for Go 1.21,Documentation NeedsFix release-blocker umbrella,"This is the tracking issue for writing the Go 1.21 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.21. When the Go 1.21 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are https://github.com/golang/go/issues/51400, https://github.com/golang/go/issues/47694, https://github.com/golang/go/issues/44513, etc. ",1.0,"doc: write release notes for Go 1.21 - This is the tracking issue for writing the Go 1.21 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.21. When the Go 1.21 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are https://github.com/golang/go/issues/51400, https://github.com/golang/go/issues/47694, https://github.com/golang/go/issues/44513, etc. ",1,doc write release notes for go this is the tracking issue for writing the go release notes the version at tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 414245,27982451500.0,IssuesEvent,2023-03-26 10:13:32,golang/go,https://api.github.com/repos/golang/go,closed,sync/map: misleading documentation about the map.LoadOrStore functions,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
1.20.1
### Does this issue reproduce with the latest release? Yep ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
Not super relevant, this is an issue with the documentation ### What did you do? ### What did you expect to see? The documentation for LoadOrStore says the following: > LoadOrStore returns the existing value for the key if present. Otherwise, it stores and returns the given value. > The loaded result is true if the value was loaded, false if stored. However, this is very misleading: while TECHNICALLY this is correct, it's very easy to understand it backwards. look at this test: ``` func Test(t *testing.T) { exampleMap := new(sync.Map) val, x := policyEnablement.LoadOrStore(""key1"", true) fmt.Println(val, x) val, x = policyEnablement.LoadOrStore(""key1"", false) fmt.Println(val, x) } ``` The output is: ``` === RUN Test true false // <--------- ""false if stored"" true true // <--------- ""true if the value was loaded"" ``` I think that clarifying the documentation with slightly more verbose explanation would help. ### What did you see instead? ",1.0,"sync/map: misleading documentation about the map.LoadOrStore functions - ### What version of Go are you using (`go version`)? 
$ go version
1.20.1
### Does this issue reproduce with the latest release? Yep ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
Not super relevant, this is an issue with the documentation ### What did you do? ### What did you expect to see? The documentation for LoadOrStore says the following: > LoadOrStore returns the existing value for the key if present. Otherwise, it stores and returns the given value. > The loaded result is true if the value was loaded, false if stored. However, this is very misleading: while TECHNICALLY this is correct, it's very easy to understand it backwards. look at this test: ``` func Test(t *testing.T) { exampleMap := new(sync.Map) val, x := policyEnablement.LoadOrStore(""key1"", true) fmt.Println(val, x) val, x = policyEnablement.LoadOrStore(""key1"", false) fmt.Println(val, x) } ``` The output is: ``` === RUN Test true false // <--------- ""false if stored"" true true // <--------- ""true if the value was loaded"" ``` I think that clarifying the documentation with slightly more verbose explanation would help. ### What did you see instead? ",1,sync map misleading documentation about the map loadorstore functions please answer these questions before submitting your issue thanks what version of go are you using go version go version does this issue reproduce with the latest release yep what operating system and processor architecture are you using go env go env output go env not super relevant this is an issue with the documentation what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best what did you expect to see the documentation for loadorstore says the following loadorstore returns the existing value for the key if present otherwise it stores and returns the given value the loaded result is true if the value was loaded false if stored however this is very misleading while technically this is correct it s very easy to understand it backwards look at this test func test t testing t examplemap new sync map val x policyenablement loadorstore true fmt println val x val x policyenablement loadorstore false fmt println val x the output is run test true false false if stored true true true if the value was loaded i think that clarifying the documentation with slightly more verbose explanation would help what did you see instead ,1 175948,14546069068.0,IssuesEvent,2020-12-15 20:38:31,golang/go,https://api.github.com/repos/golang/go,closed,x/pkgsite: replace links to godoc.org in x/* repos,Documentation NeedsFix pkgsite,"A number of packages within x/ repos still link to self-documentation hosted on godoc.org (for example: x/tools/cmd/stringer, x/tools/cmd/present). Given that the plan is to eventually redirect this traffic to pkg.go.dev (https://blog.golang.org/pkg.go.dev-2020), we should proactively update these links to point to pkg.go.dev. CC @julieqiu ",1.0,"x/pkgsite: replace links to godoc.org in x/* repos - A number of packages within x/ repos still link to self-documentation hosted on godoc.org (for example: x/tools/cmd/stringer, x/tools/cmd/present). Given that the plan is to eventually redirect this traffic to pkg.go.dev (https://blog.golang.org/pkg.go.dev-2020), we should proactively update these links to point to pkg.go.dev. CC @julieqiu ",1,x pkgsite replace links to godoc org in x repos a number of packages within x repos still link to self documentation hosted on godoc org for example x tools cmd stringer x tools cmd present given that the plan is to eventually redirect this traffic to pkg go dev we should proactively update these links to point to pkg go dev cc julieqiu ,1 136304,18726697622.0,IssuesEvent,2021-11-03 16:58:42,golang/go,https://api.github.com/repos/golang/go,closed,archive/zip: Reader.Open panics on empty string [1.16 backport],Security release-blocker CherryPickApproved,"@FiloSottile requested issue #48085 to be considered for backport to the next 1.16 minor release. > Thank you for reporting this to security@golang.org. Invalid input should not cause programs to panic, if the input could be attacker controlled. If this required a call to `Open("""")` to trigger, it could have been borderline, since it's hard for an attacker to control the argument to Open. However, the reproducer in https://github.com/golang/go/issues/48085#issuecomment-912659635 triggers a panic with a real file name. > > ``` > package main > > import ""archive/zip"" > > func main() { > reader, err := zip.OpenReader(""liquibase-core-4.4.3-sources.zip"") > if err != nil { > panic(err) > } > > reader.Open(""META-INF/MANIFEST.MF"") > } > ``` > > We'll backport this as a security fix in the PUBLIC track. @gopherbot, please open backport issues. ",True,"archive/zip: Reader.Open panics on empty string [1.16 backport] - @FiloSottile requested issue #48085 to be considered for backport to the next 1.16 minor release. > Thank you for reporting this to security@golang.org. Invalid input should not cause programs to panic, if the input could be attacker controlled. If this required a call to `Open("""")` to trigger, it could have been borderline, since it's hard for an attacker to control the argument to Open. However, the reproducer in https://github.com/golang/go/issues/48085#issuecomment-912659635 triggers a panic with a real file name. > > ``` > package main > > import ""archive/zip"" > > func main() { > reader, err := zip.OpenReader(""liquibase-core-4.4.3-sources.zip"") > if err != nil { > panic(err) > } > > reader.Open(""META-INF/MANIFEST.MF"") > } > ``` > > We'll backport this as a security fix in the PUBLIC track. @gopherbot, please open backport issues. ",0,archive zip reader open panics on empty string filosottile requested issue to be considered for backport to the next minor release thank you for reporting this to security golang org invalid input should not cause programs to panic if the input could be attacker controlled if this required a call to open to trigger it could have been borderline since it s hard for an attacker to control the argument to open however the reproducer in triggers a panic with a real file name package main import archive zip func main reader err zip openreader liquibase core sources zip if err nil panic err reader open meta inf manifest mf we ll backport this as a security fix in the public track gopherbot please open backport issues ,0 347820,24900729297.0,IssuesEvent,2022-10-28 20:34:16,golang/go,https://api.github.com/repos/golang/go,closed,testing: silly typo in documentation,Documentation,"### What version of Go are you using (`go version`)? 
$ go version
1.19.2
### Does this issue reproduce with the latest release? y ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the docs. ### What did you expect to see? Fewer typos. ### What did you see instead? In the FuzzJSONMarshaling example: ``` t.Error(""Marshal: %v"", err) ``` Either this shouldn't have the ""%v"", or it should be `t.Errorf`. ",1.0,"testing: silly typo in documentation - ### What version of Go are you using (`go version`)? 
$ go version
1.19.2
### Does this issue reproduce with the latest release? y ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the docs. ### What did you expect to see? Fewer typos. ### What did you see instead? In the FuzzJSONMarshaling example: ``` t.Error(""Marshal: %v"", err) ``` Either this shouldn't have the ""%v"", or it should be `t.Errorf`. ",1,testing silly typo in documentation what version of go are you using go version go version does this issue reproduce with the latest release y what operating system and processor architecture are you using go env n a what did you do read the docs what did you expect to see fewer typos what did you see instead in the fuzzjsonmarshaling example t error marshal v err either this shouldn t have the v or it should be t errorf ,1 62464,8613956615.0,IssuesEvent,2018-11-19 16:16:12,golang/go,https://api.github.com/repos/golang/go,closed,cmd/link: difference between s.P and s.Size,Documentation," ### What version of Go are you using (`go version`)? go version devel +66fa0ae2e6 Thu Nov 8 14:29:02 2018 -0600 aix/ppc64 ### Does this issue reproduce with the latest release? I don't know. But I think so. ### What operating system and processor architecture are you using (`go env`)? I'm on aix/ppc64. But I've quickly tried on linux/amd64 and I have the same issue. ### What did you do? This is linked with //go:cgo_import_dynamic. My program looks like this: ``` package main import ( ""fmt"" _ ""unsafe"" ) //go:cgo_import_dynamic libc_exit exit ""libc.so"" //go:linkname libc_exit libc_exit var libc_exit uintptr func main() { fmt.Printf(""0x%x\n"", &libc_exit) } ``` During XCOFF creation (doxcoff), I'm trying to add a relocation from ""libc_exit"" symbol to a new needed symbol ""exit"". (The same can be done in doelf on linux/amd64) My code looks like: ``` s := ctxt.Syms.Lookup(""libc_exit"", 0) extsym := ctxt.Syms.Lookup(s.Extname(), 0) // setup of extsym s.AddAddr(ctxt.Arch, extsym) ``` Before this operation, s.Size = 8 and len(s.P) = 0. I'm not sure if it's wanted but as libc_exit is linkname to a bss symbol, it's not that strange. Therefore, when I do s.AddAddr(ctxt.Arch, extsym), I've s.Size = 16 and len(s.P) = 16. But I don't want that as the relocation will be at off = 8 and ""libc_exit"" should have only 8 bytes. So, I've tried with s.SetAddr(ctxt.Arch, 0, extsym) to set these 8 bytes. But in this case, during relocsym I've this error: libc_exit: invalid relocation exit: 0+8 not in [0,0) (numbers in order: r.Off, s.Size, 0, len(s.P)) because s.P isn't growth during this operation. If I increase s.P manually, everything is OK: ``` s.AddBytes(make([]byte, 8)) s.SetAddr(ctxt.Arch, 0, extsym) ``` Therefore, I'm understanding it's not possible to create such relocation with the current sym functions. This might not be a problem, but the second behavior doesn't seem intended. Is this a bug ? ",1.0,"cmd/link: difference between s.P and s.Size - ### What version of Go are you using (`go version`)? go version devel +66fa0ae2e6 Thu Nov 8 14:29:02 2018 -0600 aix/ppc64 ### Does this issue reproduce with the latest release? I don't know. But I think so. ### What operating system and processor architecture are you using (`go env`)? I'm on aix/ppc64. But I've quickly tried on linux/amd64 and I have the same issue. ### What did you do? This is linked with //go:cgo_import_dynamic. My program looks like this: ``` package main import ( ""fmt"" _ ""unsafe"" ) //go:cgo_import_dynamic libc_exit exit ""libc.so"" //go:linkname libc_exit libc_exit var libc_exit uintptr func main() { fmt.Printf(""0x%x\n"", &libc_exit) } ``` During XCOFF creation (doxcoff), I'm trying to add a relocation from ""libc_exit"" symbol to a new needed symbol ""exit"". (The same can be done in doelf on linux/amd64) My code looks like: ``` s := ctxt.Syms.Lookup(""libc_exit"", 0) extsym := ctxt.Syms.Lookup(s.Extname(), 0) // setup of extsym s.AddAddr(ctxt.Arch, extsym) ``` Before this operation, s.Size = 8 and len(s.P) = 0. I'm not sure if it's wanted but as libc_exit is linkname to a bss symbol, it's not that strange. Therefore, when I do s.AddAddr(ctxt.Arch, extsym), I've s.Size = 16 and len(s.P) = 16. But I don't want that as the relocation will be at off = 8 and ""libc_exit"" should have only 8 bytes. So, I've tried with s.SetAddr(ctxt.Arch, 0, extsym) to set these 8 bytes. But in this case, during relocsym I've this error: libc_exit: invalid relocation exit: 0+8 not in [0,0) (numbers in order: r.Off, s.Size, 0, len(s.P)) because s.P isn't growth during this operation. If I increase s.P manually, everything is OK: ``` s.AddBytes(make([]byte, 8)) s.SetAddr(ctxt.Arch, 0, extsym) ``` Therefore, I'm understanding it's not possible to create such relocation with the current sym functions. This might not be a problem, but the second behavior doesn't seem intended. Is this a bug ? ",1,cmd link difference between s p and s size what version of go are you using go version go version devel thu nov aix does this issue reproduce with the latest release i don t know but i think so what operating system and processor architecture are you using go env i m on aix but i ve quickly tried on linux and i have the same issue what did you do this is linked with go cgo import dynamic my program looks like this package main import fmt unsafe go cgo import dynamic libc exit exit libc so go linkname libc exit libc exit var libc exit uintptr func main fmt printf x n libc exit during xcoff creation doxcoff i m trying to add a relocation from libc exit symbol to a new needed symbol exit the same can be done in doelf on linux my code looks like s ctxt syms lookup libc exit extsym ctxt syms lookup s extname setup of extsym s addaddr ctxt arch extsym before this operation s size and len s p i m not sure if it s wanted but as libc exit is linkname to a bss symbol it s not that strange therefore when i do s addaddr ctxt arch extsym i ve s size and len s p but i don t want that as the relocation will be at off and libc exit should have only bytes so i ve tried with s setaddr ctxt arch extsym to set these bytes but in this case during relocsym i ve this error libc exit invalid relocation exit not in numbers in order r off s size len s p because s p isn t growth during this operation if i increase s p manually everything is ok s addbytes make byte s setaddr ctxt arch extsym therefore i m understanding it s not possible to create such relocation with the current sym functions this might not be a problem but the second behavior doesn t seem intended is this a bug ,1 91784,26486495872.0,IssuesEvent,2023-01-17 18:29:01,golang/go,https://api.github.com/repos/golang/go,closed,x/build: 2 out of 3 host-ios-arm64-corellium-ios are missing,Builders NeedsFix mobile,"According to farmer.golang.org, some of the machines are missing: `host-ios-arm64-corellium-ios: 1/1 (2 missing)` @golang/ios @steeve @changkun",1.0,"x/build: 2 out of 3 host-ios-arm64-corellium-ios are missing - According to farmer.golang.org, some of the machines are missing: `host-ios-arm64-corellium-ios: 1/1 (2 missing)` @golang/ios @steeve @changkun",0,x build out of host ios corellium ios are missing according to farmer golang org some of the machines are missing host ios corellium ios missing golang ios steeve changkun,0 90325,10678700100.0,IssuesEvent,2019-10-21 17:48:09,golang/go,https://api.github.com/repos/golang/go,closed,io: CopyBuffer should document when buf is not used,Documentation NeedsDecision,"The follow is the comment for io.CopyBuffer, // CopyBuffer is identical to Copy except that it stages through the // provided buffer (if one is required) rather than allocating a // temporary one. If buf is nil, one is allocated; otherwise if it has // zero length, CopyBuffer panics. func CopyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) which is not precise enough, in the case of src implements the WriterTo interface or the case of if dst implements the ReaderFrom interface , buf will be ignore ,which is not mentioned at all. Which is very easy to lead people to wrong way. ",1.0,"io: CopyBuffer should document when buf is not used - The follow is the comment for io.CopyBuffer, // CopyBuffer is identical to Copy except that it stages through the // provided buffer (if one is required) rather than allocating a // temporary one. If buf is nil, one is allocated; otherwise if it has // zero length, CopyBuffer panics. func CopyBuffer(dst Writer, src Reader, buf []byte) (written int64, err error) which is not precise enough, in the case of src implements the WriterTo interface or the case of if dst implements the ReaderFrom interface , buf will be ignore ,which is not mentioned at all. Which is very easy to lead people to wrong way. ",1,io copybuffer should document when buf is not used the follow is the comment for io copybuffer copybuffer is identical to copy except that it stages through the provided buffer if one is required rather than allocating a temporary one if buf is nil one is allocated otherwise if it has zero length copybuffer panics func copybuffer dst writer src reader buf byte written err error which is not precise enough in the case of src implements the writerto interface or the case of if dst implements the readerfrom interface buf will be ignore which is not mentioned at all which is very easy to lead people to wrong way ,1 36074,5030162240.0,IssuesEvent,2016-12-15 23:33:56,golang/go,https://api.github.com/repos/golang/go,closed,net/http: TestServerTimeouts flake,NeedsInvestigation Testing,"https://storage.googleapis.com/go-build-log/00bd9228/linux-amd64-race_7b9a8856.log ``` 2016/11/23 21:53:28 http: TLS handshake error from 127.0.0.1:41658: read tcp 127.0.0.1:34022->127.0.0.1:41658: use of closed network connection --- FAIL: TestServerTimeouts (0.79s) serve_test.go:512: http Get #2: Get http://127.0.0.1:38239: http: server closed idle connection FAIL FAIL net/http 11.248s ```",1.0,"net/http: TestServerTimeouts flake - https://storage.googleapis.com/go-build-log/00bd9228/linux-amd64-race_7b9a8856.log ``` 2016/11/23 21:53:28 http: TLS handshake error from 127.0.0.1:41658: read tcp 127.0.0.1:34022->127.0.0.1:41658: use of closed network connection --- FAIL: TestServerTimeouts (0.79s) serve_test.go:512: http Get #2: Get http://127.0.0.1:38239: http: server closed idle connection FAIL FAIL net/http 11.248s ```",0,net http testservertimeouts flake http tls handshake error from read tcp use of closed network connection fail testservertimeouts serve test go http get get http server closed idle connection fail fail net http ,0 117479,9936815271.0,IssuesEvent,2019-07-02 20:08:59,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: TestScript/mod_sumdb_golang currently failing,NeedsInvestigation Soon Testing modules release-blocker,"There is a new `cmd/go` failure in the `longtest` builder: https://build.golang.org/log/6f541b96e3d3bd306c36aa040dc7341d544552ce It is reproducible locally, but the first failure in the dashboard is at an unrelated CL. That suggests that something has changed in the interaction with the proxy: for some reason we're apparently needing to download additional checksum tiles.
``` --- FAIL: TestScript (0.00s) --- FAIL: TestScript/mod_sumdb_golang (9.24s) script_test.go:191: # Test default GOPROXY and GOSUMDB (0.022s) # download direct from github (8.049s) # download from proxy.golang.org with go.sum entry already (1.151s) > go clean -modcache > env GOSUMDB= > env GOPROXY= > go get -x -d rsc.io/quote [stderr] # get https://proxy.golang.org/rsc.io/quote/@v/v1.5.2.mod # get https://proxy.golang.org/rsc.io/quote/@v/v1.5.2.mod: 200 OK (0.118s) # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.mod # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.mod: 200 OK (0.001s) # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.mod # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.mod: 200 OK (0.002s) # get https://proxy.golang.org/rsc.io/quote/@v/list # get https://proxy.golang.org/rsc.io/quote/@v/list: 200 OK (0.009s) go: finding rsc.io/quote v3.0.0+incompatible # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.info # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.info: 200 OK (0.005s) # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.mod # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.mod: 200 OK (0.079s) # get https://proxy.golang.org/sumdb/sum.golang.org/supported # get https://proxy.golang.org/sumdb/sum.golang.org/supported: 410 Gone (0.001s) # get https://sum.golang.org/tile/8/0/162.p/142 # get https://sum.golang.org/tile/8/1/000.p/162 # get https://sum.golang.org/tile/8/1/000.p/162: 200 OK (0.009s) # get https://sum.golang.org/tile/8/0/162.p/142: 200 OK (0.009s) # get https://sum.golang.org/lookup/rsc.io/quote@v3.0.0+incompatible # get https://sum.golang.org/lookup/rsc.io/quote@v3.0.0+incompatible: 200 OK (0.069s) # get https://sum.golang.org/tile/8/0/162.p/229 # get https://sum.golang.org/tile/8/0/162.p/229: 200 OK (0.002s) go: downloading rsc.io/quote v3.0.0+incompatible # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.zip # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.zip: 200 OK (0.077s) go: extracting rsc.io/quote v3.0.0+incompatible go: downloading rsc.io/sampler v1.3.0 # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.zip # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.zip: 200 OK (0.001s) go: extracting rsc.io/sampler v1.3.0 go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.zip # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.zip: 200 OK (0.019s) go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c > ! stderr github > stderr proxy.golang.org/rsc.io/quote > ! stderr sum.golang.org/tile FAIL: testdata/script/mod_sumdb_golang.txt:26: unexpected match for `(?m)sum.golang.org/tile` found in stderr: sum.golang.org/tile FAIL FAIL cmd/go 230.892s FAIL ```
CC @rsc @FiloSottile @heschik @hyangah @katiehockman @jayconrod ",1.0,"cmd/go: TestScript/mod_sumdb_golang currently failing - There is a new `cmd/go` failure in the `longtest` builder: https://build.golang.org/log/6f541b96e3d3bd306c36aa040dc7341d544552ce It is reproducible locally, but the first failure in the dashboard is at an unrelated CL. That suggests that something has changed in the interaction with the proxy: for some reason we're apparently needing to download additional checksum tiles.
``` --- FAIL: TestScript (0.00s) --- FAIL: TestScript/mod_sumdb_golang (9.24s) script_test.go:191: # Test default GOPROXY and GOSUMDB (0.022s) # download direct from github (8.049s) # download from proxy.golang.org with go.sum entry already (1.151s) > go clean -modcache > env GOSUMDB= > env GOPROXY= > go get -x -d rsc.io/quote [stderr] # get https://proxy.golang.org/rsc.io/quote/@v/v1.5.2.mod # get https://proxy.golang.org/rsc.io/quote/@v/v1.5.2.mod: 200 OK (0.118s) # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.mod # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.mod: 200 OK (0.001s) # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.mod # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.mod: 200 OK (0.002s) # get https://proxy.golang.org/rsc.io/quote/@v/list # get https://proxy.golang.org/rsc.io/quote/@v/list: 200 OK (0.009s) go: finding rsc.io/quote v3.0.0+incompatible # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.info # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.info: 200 OK (0.005s) # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.mod # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.mod: 200 OK (0.079s) # get https://proxy.golang.org/sumdb/sum.golang.org/supported # get https://proxy.golang.org/sumdb/sum.golang.org/supported: 410 Gone (0.001s) # get https://sum.golang.org/tile/8/0/162.p/142 # get https://sum.golang.org/tile/8/1/000.p/162 # get https://sum.golang.org/tile/8/1/000.p/162: 200 OK (0.009s) # get https://sum.golang.org/tile/8/0/162.p/142: 200 OK (0.009s) # get https://sum.golang.org/lookup/rsc.io/quote@v3.0.0+incompatible # get https://sum.golang.org/lookup/rsc.io/quote@v3.0.0+incompatible: 200 OK (0.069s) # get https://sum.golang.org/tile/8/0/162.p/229 # get https://sum.golang.org/tile/8/0/162.p/229: 200 OK (0.002s) go: downloading rsc.io/quote v3.0.0+incompatible # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.zip # get https://proxy.golang.org/rsc.io/quote/@v/v3.0.0+incompatible.zip: 200 OK (0.077s) go: extracting rsc.io/quote v3.0.0+incompatible go: downloading rsc.io/sampler v1.3.0 # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.zip # get https://proxy.golang.org/rsc.io/sampler/@v/v1.3.0.zip: 200 OK (0.001s) go: extracting rsc.io/sampler v1.3.0 go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.zip # get https://proxy.golang.org/golang.org/x/text/@v/v0.0.0-20170915032832-14c0d48ead0c.zip: 200 OK (0.019s) go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c > ! stderr github > stderr proxy.golang.org/rsc.io/quote > ! stderr sum.golang.org/tile FAIL: testdata/script/mod_sumdb_golang.txt:26: unexpected match for `(?m)sum.golang.org/tile` found in stderr: sum.golang.org/tile FAIL FAIL cmd/go 230.892s FAIL ```
CC @rsc @FiloSottile @heschik @hyangah @katiehockman @jayconrod ",0,cmd go testscript mod sumdb golang currently failing there is a new cmd go failure in the longtest builder it is reproducible locally but the first failure in the dashboard is at an unrelated cl that suggests that something has changed in the interaction with the proxy for some reason we re apparently needing to download additional checksum tiles fail testscript fail testscript mod sumdb golang script test go test default goproxy and gosumdb download direct from github download from proxy golang org with go sum entry already go clean modcache env gosumdb env goproxy go get x d rsc io quote get get ok get get ok get get ok get get ok go finding rsc io quote incompatible get get ok get get ok get get gone get get get ok get ok get get ok get get ok go downloading rsc io quote incompatible get get ok go extracting rsc io quote incompatible go downloading rsc io sampler get get ok go extracting rsc io sampler go downloading golang org x text get get ok go extracting golang org x text stderr github stderr proxy golang org rsc io quote stderr sum golang org tile fail testdata script mod sumdb golang txt unexpected match for m sum golang org tile found in stderr sum golang org tile fail fail cmd go fail cc rsc filosottile heschik hyangah katiehockman jayconrod ,0 25480,5168404704.0,IssuesEvent,2017-01-17 21:29:48,golang/go,https://api.github.com/repos/golang/go,closed,"README.md: outdated install instructions, GOROOT setting is too prominent",Documentation NeedsFix,"CL c497c9ea4bbe90833ee0bb8660fe91b8f17adee7 updated the installation instructions in `doc/install.html` to clarify that GOROOT should only be set when using a custom install path. This fixed #6613 (doc: clarify that GOROOT is only necessary for non-standard install locations), but the `README.md` file (the one you see when you visit github.com/golang/go) was not updated, and the **Binary distribution** section still starts like this: > If you have just untarred a binary Go distribution, you need to set the environment variable $GOROOT which is not ideal.",1.0,"README.md: outdated install instructions, GOROOT setting is too prominent - CL c497c9ea4bbe90833ee0bb8660fe91b8f17adee7 updated the installation instructions in `doc/install.html` to clarify that GOROOT should only be set when using a custom install path. This fixed #6613 (doc: clarify that GOROOT is only necessary for non-standard install locations), but the `README.md` file (the one you see when you visit github.com/golang/go) was not updated, and the **Binary distribution** section still starts like this: > If you have just untarred a binary Go distribution, you need to set the environment variable $GOROOT which is not ideal.",1,readme md outdated install instructions goroot setting is too prominent cl updated the installation instructions in doc install html to clarify that goroot should only be set when using a custom install path this fixed doc clarify that goroot is only necessary for non standard install locations but the readme md file the one you see when you visit github com golang go was not updated and the binary distribution section still starts like this if you have just untarred a binary go distribution you need to set the environment variable goroot which is not ideal ,1 426585,29576891865.0,IssuesEvent,2023-06-07 00:03:31,golang/go,https://api.github.com/repos/golang/go,closed,spec: Index expressions spec is fragmented for map type code,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.2 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
```
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/paj/Library/Caches/go-build""
GOENV=""/Users/paj/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/paj/.asdf/installs/golang/1.20.2/packages/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/paj/.asdf/installs/golang/1.20.2/packages""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/paj/.asdf/installs/golang/1.20.2/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/paj/.asdf/installs/golang/1.20.2/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.20.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/4d/zd6b5xpn7rq00306yspzfy3r0000gn/T/go-build17349328=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Reading the Index expressions spec at https://go.dev/ref/spec#Map_types to determine how to handle the case where a key is not present in a map. ### What did you expect to see? Information about the above. ### What did you see instead? Information about type parameter types, introduced in 68da368a4e . ### Note Pull request incoming.",1.0,"spec: Index expressions spec is fragmented for map type code - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.2 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
```
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/paj/Library/Caches/go-build""
GOENV=""/Users/paj/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/paj/.asdf/installs/golang/1.20.2/packages/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/paj/.asdf/installs/golang/1.20.2/packages""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/paj/.asdf/installs/golang/1.20.2/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/paj/.asdf/installs/golang/1.20.2/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.20.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/4d/zd6b5xpn7rq00306yspzfy3r0000gn/T/go-build17349328=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Reading the Index expressions spec at https://go.dev/ref/spec#Map_types to determine how to handle the case where a key is not present in a map. ### What did you expect to see? Information about the above. ### What did you see instead? Information about type parameter types, introduced in 68da368a4e . ### Note Pull request incoming.",1,spec index expressions spec is fragmented for map type code what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output goarch gobin gocache users paj library caches go build goenv users paj library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users paj asdf installs golang packages pkg mod gonoproxy gonosumdb goos darwin gopath users paj asdf installs golang packages goprivate goproxy goroot users paj asdf installs golang go gosumdb sum golang org gotmpdir gotooldir users paj asdf installs golang go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do reading the index expressions spec at to determine how to handle the case where a key is not present in a map what did you expect to see information about the above what did you see instead information about type parameter types introduced in note pull request incoming ,1 57150,8147679940.0,IssuesEvent,2018-08-22 01:10:56,golang/go,https://api.github.com/repos/golang/go,closed,web: remove content other than documentation from primary Go source tree,Documentation NeedsDecision,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? every ### What did you do? ``` $ du -h SRC/blog 19M blog/content 19M blog ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? no blog content ### What did you see instead? no Now the Go blog content takes about 19MB in source code repos. As I'd tried to remove blog directory and repack the whole GOROOT, the pkg reduce about 16MB. -rw-r--r-- 1 root staff 82M Sep 18 11:29 go1.9.linux-amd64..no_blog.tar.gz -rw-r--r-- 1 root root 98M Aug 25 06:44 go1.9.linux-amd64.tar.gz",1.0,"web: remove content other than documentation from primary Go source tree - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? every ### What did you do? ``` $ du -h SRC/blog 19M blog/content 19M blog ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? no blog content ### What did you see instead? no Now the Go blog content takes about 19MB in source code repos. As I'd tried to remove blog directory and repack the whole GOROOT, the pkg reduce about 16MB. -rw-r--r-- 1 root staff 82M Sep 18 11:29 go1.9.linux-amd64..no_blog.tar.gz -rw-r--r-- 1 root root 98M Aug 25 06:44 go1.9.linux-amd64.tar.gz",1,web remove content other than documentation from primary go source tree please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env every what did you do du h src blog blog content blog if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see no blog content what did you see instead no now the go blog content takes about in source code repos as i d tried to remove blog directory and repack the whole goroot the pkg reduce about rw r r root staff sep linux no blog tar gz rw r r root root aug linux tar gz,1 106988,11503919930.0,IssuesEvent,2020-02-12 22:05:22,golang/go,https://api.github.com/repos/golang/go,closed,wiki: clarify Assembly Policy for crypto,Documentation,"Current [Assembly Policy](https://github.com/golang/go/wiki/AssemblyPolicy) establish general guidelines for inclusion of assembly implementations. However there is some [confusion](https://groups.google.com/forum/#!topic/golang-dev/_ZwBZJaDw_U) about it application to crypto. I think we should clarify the following questions: - Are assembly implementations of new (to go) modes/hashes/block-ciphers allowed at all? - If they are allowed, we should have a list of deprecated stuff, that is **intended** to be slow e. g. rc4. - Are there any additional requirements for testing crypto asm? - Can I (or anyone without great background in crypto) +2 straightforward cases e. g. https://go-review.googlesource.com/c/go/+/125316 ? - If we are not going to accept new assembly implemntaions, than we must do something with CLs sent before creation of assembly policy, that are still in review, e. g. https://go-review.googlesource.com/c/go/+/109135 ",1.0,"wiki: clarify Assembly Policy for crypto - Current [Assembly Policy](https://github.com/golang/go/wiki/AssemblyPolicy) establish general guidelines for inclusion of assembly implementations. However there is some [confusion](https://groups.google.com/forum/#!topic/golang-dev/_ZwBZJaDw_U) about it application to crypto. I think we should clarify the following questions: - Are assembly implementations of new (to go) modes/hashes/block-ciphers allowed at all? - If they are allowed, we should have a list of deprecated stuff, that is **intended** to be slow e. g. rc4. - Are there any additional requirements for testing crypto asm? - Can I (or anyone without great background in crypto) +2 straightforward cases e. g. https://go-review.googlesource.com/c/go/+/125316 ? - If we are not going to accept new assembly implemntaions, than we must do something with CLs sent before creation of assembly policy, that are still in review, e. g. https://go-review.googlesource.com/c/go/+/109135 ",1,wiki clarify assembly policy for crypto current establish general guidelines for inclusion of assembly implementations however there is some about it application to crypto i think we should clarify the following questions are assembly implementations of new to go modes hashes block ciphers allowed at all if they are allowed we should have a list of deprecated stuff that is intended to be slow e g are there any additional requirements for testing crypto asm can i or anyone without great background in crypto straightforward cases e g if we are not going to accept new assembly implemntaions than we must do something with cls sent before creation of assembly policy that are still in review e g ,1 253434,19101002693.0,IssuesEvent,2021-11-29 22:32:43,golang/go,https://api.github.com/repos/golang/go,closed,encoding/xml: mismatching namespace error misses a space char,Documentation NeedsFix,"### What version of Go are you using (`go version`)? 
1.17
### Does this issue reproduce with the latest release? Reproducible on the tip. ### What operating system and processor architecture are you using (`go env`)? linux/amd64. ### What did you do? `go run example.go` (https://play.golang.org/p/dU4NQ2vTVyF): ```go package main import ( ""fmt"" ""encoding/xml"" ""strings"" ) func main() { const input = `` d := xml.NewDecoder(strings.NewReader(input)) d.Token() // read StartElement _, err := d.Token() // read EndElement fmt.Println(err) } ``` ### What did you expect to see? ``` XML syntax error on line 1: element in space a closed by in space b ``` ### What did you see instead? ``` XML syntax error on line 1: element in space aclosed by in space b ``` Note the diff: ```diff - XML syntax error on line 1: element in space aclosed by in space b + XML syntax error on line 1: element in space a closed by in space b ``` ",1.0,"encoding/xml: mismatching namespace error misses a space char - ### What version of Go are you using (`go version`)? 
1.17
### Does this issue reproduce with the latest release? Reproducible on the tip. ### What operating system and processor architecture are you using (`go env`)? linux/amd64. ### What did you do? `go run example.go` (https://play.golang.org/p/dU4NQ2vTVyF): ```go package main import ( ""fmt"" ""encoding/xml"" ""strings"" ) func main() { const input = `` d := xml.NewDecoder(strings.NewReader(input)) d.Token() // read StartElement _, err := d.Token() // read EndElement fmt.Println(err) } ``` ### What did you expect to see? ``` XML syntax error on line 1: element in space a closed by in space b ``` ### What did you see instead? ``` XML syntax error on line 1: element in space aclosed by in space b ``` Note the diff: ```diff - XML syntax error on line 1: element in space aclosed by in space b + XML syntax error on line 1: element in space a closed by in space b ``` ",1,encoding xml mismatching namespace error misses a space char what version of go are you using go version does this issue reproduce with the latest release reproducible on the tip what operating system and processor architecture are you using go env linux what did you do go run example go go package main import fmt encoding xml strings func main const input d xml newdecoder strings newreader input d token read startelement err d token read endelement fmt println err what did you expect to see xml syntax error on line element in space a closed by in space b what did you see instead xml syntax error on line element in space aclosed by in space b note the diff diff xml syntax error on line element in space aclosed by in space b xml syntax error on line element in space a closed by in space b ,1 72930,9632630654.0,IssuesEvent,2019-05-15 16:38:19,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: replace directives are not thoroughly documented,Documentation GoCommand modules," ### What version of Go are you using (`go version`)? 
$ go version
go version devel +f0c383b833 Wed May 1 16:53:19 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read `go help modules` and `go help go.mod`. ### What did you expect to see? Some discussion of what replacements are and what they do. ### What did you see instead? The only documentation I can find is these lines in `go help go.mod`: ``` replace bad/thing v1.4.5 => good/thing v1.4.5 ``` ``` replace, to replace a module version with a different module version. Exclude and replace apply only in the main module's go.mod and are ignored in dependencies. See https://research.swtch.com/vgo-mvs for details. ``` I think there's probably more to say about how replace works. For example, it doesn't explicitly state that the thing to replace is on the left side of the arrow. It also doesn't mention that the version on the left is optional.",1.0,"cmd/go: replace directives are not thoroughly documented - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +f0c383b833 Wed May 1 16:53:19 2019 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read `go help modules` and `go help go.mod`. ### What did you expect to see? Some discussion of what replacements are and what they do. ### What did you see instead? The only documentation I can find is these lines in `go help go.mod`: ``` replace bad/thing v1.4.5 => good/thing v1.4.5 ``` ``` replace, to replace a module version with a different module version. Exclude and replace apply only in the main module's go.mod and are ignored in dependencies. See https://research.swtch.com/vgo-mvs for details. ``` I think there's probably more to say about how replace works. For example, it doesn't explicitly state that the thing to replace is on the left side of the arrow. It also doesn't mention that the version on the left is optional.",1,cmd go replace directives are not thoroughly documented what version of go are you using go version go version go version devel wed may linux does this issue reproduce with the latest release yes what did you do read go help modules and go help go mod what did you expect to see some discussion of what replacements are and what they do what did you see instead the only documentation i can find is these lines in go help go mod replace bad thing good thing replace to replace a module version with a different module version exclude and replace apply only in the main module s go mod and are ignored in dependencies see for details i think there s probably more to say about how replace works for example it doesn t explicitly state that the thing to replace is on the left side of the arrow it also doesn t mention that the version on the left is optional ,1 337946,24563349809.0,IssuesEvent,2022-10-12 22:56:54,golang/go,https://api.github.com/repos/golang/go,closed,runtime/cgo: incorrectly handle SIGPIPE(and other signals) from non-Go thread,Documentation NeedsFix compiler/runtime," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/secret/.cache/go-build""
GOENV=""/home/secret/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/secret/go/pkg/mod""
GOOS=""linux""
GOPATH=""/home/secret/go""
GOPROXY=""https://goproxy.cn|https://proxy.golang.org|direct""
GOROOT=""/data00/home/secret/go1.19""
GOSUMDB=""sum.golang.google.cn""
GOTMPDIR=""""
GOTOOLDIR=""/data00/home/secret/go1.19/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build457638227=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Following code is a minimal example. SIGPIPE raised from linux socket write, but can be reproduced by the following form. According to the [document](https://pkg.go.dev/os/signal#hdr-SIGPIPE), SIGPIPE should be caught by default, without affect program, just like the kill line in `test` function. But in sub-thread created by pthread, the SIGPIPE trigger the runtime.raisebadsignal, and make program exit, like kill line in `subThread` function (uncomment it). ```go package main /* #include #include #include #include #define gettid() syscall(SYS_gettid) void *subThread(void *_) { // kill(gettid(), SIGPIPE); // kill by thread id return NULL; } void test() { pthread_t thread_id; pthread_create(&thread_id, NULL, subThread, NULL); pthread_join(thread_id, NULL); kill(gettid(), SIGPIPE); } */ import ""C"" func main() { C.test() // should not exit select {} } ``` ### What did you expect to see? Go runtime catch the SIGPIPE from thread created by pthread, and everything works fine. ### What did you see instead? (uncomment kill function in `subThread`) kill in `subThread` make program exit, kill in `test` make program continue running.",1.0,"runtime/cgo: incorrectly handle SIGPIPE(and other signals) from non-Go thread - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/secret/.cache/go-build""
GOENV=""/home/secret/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/secret/go/pkg/mod""
GOOS=""linux""
GOPATH=""/home/secret/go""
GOPROXY=""https://goproxy.cn|https://proxy.golang.org|direct""
GOROOT=""/data00/home/secret/go1.19""
GOSUMDB=""sum.golang.google.cn""
GOTMPDIR=""""
GOTOOLDIR=""/data00/home/secret/go1.19/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build457638227=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Following code is a minimal example. SIGPIPE raised from linux socket write, but can be reproduced by the following form. According to the [document](https://pkg.go.dev/os/signal#hdr-SIGPIPE), SIGPIPE should be caught by default, without affect program, just like the kill line in `test` function. But in sub-thread created by pthread, the SIGPIPE trigger the runtime.raisebadsignal, and make program exit, like kill line in `subThread` function (uncomment it). ```go package main /* #include #include #include #include #define gettid() syscall(SYS_gettid) void *subThread(void *_) { // kill(gettid(), SIGPIPE); // kill by thread id return NULL; } void test() { pthread_t thread_id; pthread_create(&thread_id, NULL, subThread, NULL); pthread_join(thread_id, NULL); kill(gettid(), SIGPIPE); } */ import ""C"" func main() { C.test() // should not exit select {} } ``` ### What did you expect to see? Go runtime catch the SIGPIPE from thread created by pthread, and everything works fine. ### What did you see instead? (uncomment kill function in `subThread`) kill in `subThread` make program exit, kill in `test` make program continue running.",1,runtime cgo incorrectly handle sigpipe and other signals from non go thread please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home secret cache go build goenv home secret config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home secret go pkg mod goos linux gopath home secret go goproxy goroot home secret gosumdb sum golang google cn gotmpdir gotooldir home secret pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread wl no gc sections fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do following code is a minimal example sigpipe raised from linux socket write but can be reproduced by the following form according to the sigpipe should be caught by default without affect program just like the kill line in test function but in sub thread created by pthread the sigpipe trigger the runtime raisebadsignal and make program exit like kill line in subthread function uncomment it go package main include include include include define gettid syscall sys gettid void subthread void kill gettid sigpipe kill by thread id return null void test pthread t thread id pthread create thread id null subthread null pthread join thread id null kill gettid sigpipe import c func main c test should not exit select what did you expect to see go runtime catch the sigpipe from thread created by pthread and everything works fine what did you see instead uncomment kill function in subthread kill in subthread make program exit kill in test make program continue running ,1 272766,23701168011.0,IssuesEvent,2022-08-29 19:08:31,golang/go,https://api.github.com/repos/golang/go,closed,misc/cgo: TestSignalForwardingExternal sometimes fails with wrong signal SIGINT [1.18 backport],Testing CherryPickApproved,"@ianlancetaylor requested issue #53907 to be considered for backport to the next 1.18 minor release. > @gopherbot Please open backport to 1.18. > > This is a test-only fix that avoids occasional test failures on s390x and possibly other systems. ",1.0,"misc/cgo: TestSignalForwardingExternal sometimes fails with wrong signal SIGINT [1.18 backport] - @ianlancetaylor requested issue #53907 to be considered for backport to the next 1.18 minor release. > @gopherbot Please open backport to 1.18. > > This is a test-only fix that avoids occasional test failures on s390x and possibly other systems. ",0,misc cgo testsignalforwardingexternal sometimes fails with wrong signal sigint ianlancetaylor requested issue to be considered for backport to the next minor release gopherbot please open backport to this is a test only fix that avoids occasional test failures on and possibly other systems ,0 105766,11457742941.0,IssuesEvent,2020-02-07 00:46:46,golang/go,https://api.github.com/repos/golang/go,opened,wiki: Go-Release-Cycle has an out of date statement on backporting policy,Documentation NeedsDecision,"There is a statement in the [Release Maintenance](https://golang.org/wiki/Go-Release-Cycle#release-maintenance) section of the Go Release Cycle wiki page that is out of date: > Minor releases to address non-security problems for Go 1.x stop once Go 1.x+1 is released. I plan to edit the page to make it say: > Minor releases to address non-security problems for Go 1.x stop once Go 1.x+2 is released. This is because we've accepted a backport policy clarification in proposal #34536, where the last two releases are supported equally. (Filing this issue before making the change, as documented in the first paragraph of that wiki page.) /cc @rsc @andybons @cagedmantis @toothrot",1.0,"wiki: Go-Release-Cycle has an out of date statement on backporting policy - There is a statement in the [Release Maintenance](https://golang.org/wiki/Go-Release-Cycle#release-maintenance) section of the Go Release Cycle wiki page that is out of date: > Minor releases to address non-security problems for Go 1.x stop once Go 1.x+1 is released. I plan to edit the page to make it say: > Minor releases to address non-security problems for Go 1.x stop once Go 1.x+2 is released. This is because we've accepted a backport policy clarification in proposal #34536, where the last two releases are supported equally. (Filing this issue before making the change, as documented in the first paragraph of that wiki page.) /cc @rsc @andybons @cagedmantis @toothrot",1,wiki go release cycle has an out of date statement on backporting policy there is a statement in the  section of the go release cycle wiki page that is out of date minor releases to address non security problems for go x stop once go x is released i plan to edit the page to make it say minor releases to address non security problems for go x stop once go x is released this is because we ve accepted a backport policy clarification in proposal where the last two releases are supported equally filing this issue before making the change as documented in the first paragraph of that wiki page cc rsc andybons cagedmantis toothrot,1 42498,6986348380.0,IssuesEvent,2017-12-14 02:52:28,golang/go,https://api.github.com/repos/golang/go,closed,testing: deferred func runs before parallel subtest,Documentation,"Also, Run's result was wrong. #### What did you do? I deferred a function in a package-scope test, then ran a parallel subtest that assumed the deferred function would run after it completes, but this wasn't the case, and Run returned true when the subtest failed. Basically, this: ```go func TestFoo(t *testing.T) { defer bar() // Runs before baz var passed = t.Run(""subtest"", func(t *testing.T) { t.Parallel() baz() // Runs after bar t.Fail() } // Passed is true // ... } ``` It doesn't matter whether the package-scope test is parallel. A full example: https://play.golang.org/p/pMsKhRvjiW. Note that you'll have to run it locally. The documentation for testing.T.Run says: ``` func (t *T) Run(name string, f func(t *T)) bool Run runs f as a subtest of t called name. It reports whether f succeeded. Run runs f in a separate goroutine and will block until all its parallel subtests have completed. Run may be called simultaneously from multiple goroutines, but all such calls must return before the outer test function for t returns. ``` This seems to say that Run always returns an accurate status of the subtest, even if it's parallel, which means the subtest must finish before the Run call completes, and thus before the parent test returns, after which its deferred functions run, but I'm seeing such a deferred function run first. The discussion in https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks similarly indicates to me this is incorrect behavior, specifically the paragraphs starting with ""Subtests can also be used to control parallelism"" and ""Run does not return until parallel subtests have completed"". The documentation for testing.T.Parallel says: ``` func (t *T) Parallel() Parallel signals that this test is to be run in parallel with (and only with) other parallel tests. When a test is run multiple times due to use of -test.count or -test.cpu, multiple instances of a single test never run in parallel with each other. ``` This doesn't seem to augment Run's documentation's guarantees, but I'm not sure. I feel like I must be missing something obvious, but a colleague agreed with my interpretation. #### What did you expect to see? ``` $ go test -v === RUN TestFoo === RUN TestFoo/sub --- PASS: TestFoo (0.00s) t_test.go:34: passed: actual true, expected true --- PASS: TestFoo/sub (0.00s) PASS ok t 0.036s ``` #### What did you see instead? ``` $ go test -v === RUN TestFoo === RUN TestFoo/sub --- FAIL: TestFoo (0.00s) t_test.go:34: passed: actual true, expected true --- FAIL: TestFoo/sub (0.10s) t_test.go:24: Get http://127.0.0.1:61311: dial tcp 127.0.0.1:61311: getsockopt: connection refused t_test.go:28: response: actual nil, expected not nil FAIL exit status 1 FAIL t 0.141s ``` #### System details ``` go version go1.9.2 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/willfaught/Developer/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_1/ggvd2t1x7hz_185crsb36zlr0000gp/T/go-build590837635=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOROOT/bin/go version: go version go1.9.2 darwin/amd64 GOROOT/bin/go tool compile -V: compile version go1.9.2 uname -v: Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1003 lldb --version: lldb-900.0.57 Swift-4.0 ```",1.0,"testing: deferred func runs before parallel subtest - Also, Run's result was wrong. #### What did you do? I deferred a function in a package-scope test, then ran a parallel subtest that assumed the deferred function would run after it completes, but this wasn't the case, and Run returned true when the subtest failed. Basically, this: ```go func TestFoo(t *testing.T) { defer bar() // Runs before baz var passed = t.Run(""subtest"", func(t *testing.T) { t.Parallel() baz() // Runs after bar t.Fail() } // Passed is true // ... } ``` It doesn't matter whether the package-scope test is parallel. A full example: https://play.golang.org/p/pMsKhRvjiW. Note that you'll have to run it locally. The documentation for testing.T.Run says: ``` func (t *T) Run(name string, f func(t *T)) bool Run runs f as a subtest of t called name. It reports whether f succeeded. Run runs f in a separate goroutine and will block until all its parallel subtests have completed. Run may be called simultaneously from multiple goroutines, but all such calls must return before the outer test function for t returns. ``` This seems to say that Run always returns an accurate status of the subtest, even if it's parallel, which means the subtest must finish before the Run call completes, and thus before the parent test returns, after which its deferred functions run, but I'm seeing such a deferred function run first. The discussion in https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks similarly indicates to me this is incorrect behavior, specifically the paragraphs starting with ""Subtests can also be used to control parallelism"" and ""Run does not return until parallel subtests have completed"". The documentation for testing.T.Parallel says: ``` func (t *T) Parallel() Parallel signals that this test is to be run in parallel with (and only with) other parallel tests. When a test is run multiple times due to use of -test.count or -test.cpu, multiple instances of a single test never run in parallel with each other. ``` This doesn't seem to augment Run's documentation's guarantees, but I'm not sure. I feel like I must be missing something obvious, but a colleague agreed with my interpretation. #### What did you expect to see? ``` $ go test -v === RUN TestFoo === RUN TestFoo/sub --- PASS: TestFoo (0.00s) t_test.go:34: passed: actual true, expected true --- PASS: TestFoo/sub (0.00s) PASS ok t 0.036s ``` #### What did you see instead? ``` $ go test -v === RUN TestFoo === RUN TestFoo/sub --- FAIL: TestFoo (0.00s) t_test.go:34: passed: actual true, expected true --- FAIL: TestFoo/sub (0.10s) t_test.go:24: Get http://127.0.0.1:61311: dial tcp 127.0.0.1:61311: getsockopt: connection refused t_test.go:28: response: actual nil, expected not nil FAIL exit status 1 FAIL t 0.141s ``` #### System details ``` go version go1.9.2 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/willfaught/Developer/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_1/ggvd2t1x7hz_185crsb36zlr0000gp/T/go-build590837635=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOROOT/bin/go version: go version go1.9.2 darwin/amd64 GOROOT/bin/go tool compile -V: compile version go1.9.2 uname -v: Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1003 lldb --version: lldb-900.0.57 Swift-4.0 ```",1,testing deferred func runs before parallel subtest also run s result was wrong what did you do i deferred a function in a package scope test then ran a parallel subtest that assumed the deferred function would run after it completes but this wasn t the case and run returned true when the subtest failed basically this go func testfoo t testing t defer bar runs before baz var passed t run subtest func t testing t t parallel baz runs after bar t fail passed is true it doesn t matter whether the package scope test is parallel a full example note that you ll have to run it locally the documentation for testing t run says func t t run name string f func t t bool run runs f as a subtest of t called name it reports whether f succeeded run runs f in a separate goroutine and will block until all its parallel subtests have completed run may be called simultaneously from multiple goroutines but all such calls must return before the outer test function for t returns this seems to say that run always returns an accurate status of the subtest even if it s parallel which means the subtest must finish before the run call completes and thus before the parent test returns after which its deferred functions run but i m seeing such a deferred function run first the discussion in similarly indicates to me this is incorrect behavior specifically the paragraphs starting with subtests can also be used to control parallelism and run does not return until parallel subtests have completed the documentation for testing t parallel says func t t parallel parallel signals that this test is to be run in parallel with and only with other parallel tests when a test is run multiple times due to use of test count or test cpu multiple instances of a single test never run in parallel with each other this doesn t seem to augment run s documentation s guarantees but i m not sure i feel like i must be missing something obvious but a colleague agreed with my interpretation what did you expect to see go test v run testfoo run testfoo sub pass testfoo t test go passed actual true expected true pass testfoo sub pass ok t what did you see instead go test v run testfoo run testfoo sub fail testfoo t test go passed actual true expected true fail testfoo sub t test go get dial tcp getsockopt connection refused t test go response actual nil expected not nil fail exit status fail t system details go version darwin goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users willfaught developer go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version fri sep pdt root xnu release productname mac os x productversion buildversion lldb version lldb swift ,1 367890,25767454240.0,IssuesEvent,2022-12-09 03:54:49,golang/go,https://api.github.com/repos/golang/go,closed,wiki: CodeReviewComments change - Justify variable name length,Documentation NeedsDecision,"From https://github.com/golang/go/wiki/CodeReviewComments#variable-names: > Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer `c` to `lineCount`. Prefer `i` to `sliceIndex`. > The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (`i`, `r`). More unusual things and global variables need more descriptive names. Similarly to https://github.com/golang/go/issues/38912, I don't understand why this is suggested. The comments there have some explanations I don't agree with, but they also suggest that I'm free to do things my own way if I disagree with the document. Literally this is of course true, but the spirit of it conflicts with the introduction of the page: > This is a laundry list of common mistakes, not a comprehensive style guide. It says that violating this would be a *mistake*. That's a pretty strong word, so the section on variable names can easily be (mis?)interpreted as [canonical](https://google.github.io/styleguide/go/#canonical). I'll assume that the introduction is the better source of truth. Including justification would also suit the described use case of the document: > so that a single detailed explanation can be referred to by shorthands If someone's PR gets a comment with a link to this section, I imagine a detailed explanation would mean a less divisive resolution. Could the variable naming convention section be enhanced to include justification?",1.0,"wiki: CodeReviewComments change - Justify variable name length - From https://github.com/golang/go/wiki/CodeReviewComments#variable-names: > Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer `c` to `lineCount`. Prefer `i` to `sliceIndex`. > The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (`i`, `r`). More unusual things and global variables need more descriptive names. Similarly to https://github.com/golang/go/issues/38912, I don't understand why this is suggested. The comments there have some explanations I don't agree with, but they also suggest that I'm free to do things my own way if I disagree with the document. Literally this is of course true, but the spirit of it conflicts with the introduction of the page: > This is a laundry list of common mistakes, not a comprehensive style guide. It says that violating this would be a *mistake*. That's a pretty strong word, so the section on variable names can easily be (mis?)interpreted as [canonical](https://google.github.io/styleguide/go/#canonical). I'll assume that the introduction is the better source of truth. Including justification would also suit the described use case of the document: > so that a single detailed explanation can be referred to by shorthands If someone's PR gets a comment with a link to this section, I imagine a detailed explanation would mean a less divisive resolution. Could the variable naming convention section be enhanced to include justification?",1,wiki codereviewcomments change justify variable name length from variable names in go should be short rather than long this is especially true for local variables with limited scope prefer c to linecount prefer i to sliceindex the basic rule the further from its declaration that a name is used the more descriptive the name must be for a method receiver one or two letters is sufficient common variables such as loop indices and readers can be a single letter i r more unusual things and global variables need more descriptive names similarly to i don t understand why this is suggested the comments there have some explanations i don t agree with but they also suggest that i m free to do things my own way if i disagree with the document literally this is of course true but the spirit of it conflicts with the introduction of the page this is a laundry list of common mistakes not a comprehensive style guide it says that violating this would be a mistake that s a pretty strong word so the section on variable names can easily be mis interpreted as i ll assume that the introduction is the better source of truth including justification would also suit the described use case of the document so that a single detailed explanation can be referred to by shorthands if someone s pr gets a comment with a link to this section i imagine a detailed explanation would mean a less divisive resolution could the variable naming convention section be enhanced to include justification ,1 23115,4877616701.0,IssuesEvent,2016-11-16 16:06:26,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: clarify docs for Tx.Stmt().Close(),Documentation NeedsInvestigation,"`Tx.Stmt()` example (https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql.go#L1332) shows the following code: ``` res, err := tx.Stmt(updateMoney).Exec(123.45, 98293203) ``` Looking at that code I assume there is no need to explicitly close the `Stmt` returned from `tx.Stmt(updateMoney)` because example does not even store references to it. On the other hand, tests (https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql_test.go#L577 and https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql_test.go#L665) are explicitly closing that `Stmt`. So I wonder - is there an actual need to `.Close()` the prepared statements returned from `tx.Stmt()` or rollback/commit will close them automatically? /cc @bradfitz ",1.0,"database/sql: clarify docs for Tx.Stmt().Close() - `Tx.Stmt()` example (https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql.go#L1332) shows the following code: ``` res, err := tx.Stmt(updateMoney).Exec(123.45, 98293203) ``` Looking at that code I assume there is no need to explicitly close the `Stmt` returned from `tx.Stmt(updateMoney)` because example does not even store references to it. On the other hand, tests (https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql_test.go#L577 and https://github.com/golang/go/blob/733aefd06e5cf708637308a4ad7a048aa97db5cd/src/database/sql/sql_test.go#L665) are explicitly closing that `Stmt`. So I wonder - is there an actual need to `.Close()` the prepared statements returned from `tx.Stmt()` or rollback/commit will close them automatically? /cc @bradfitz ",1,database sql clarify docs for tx stmt close tx stmt example shows the following code res err tx stmt updatemoney exec looking at that code i assume there is no need to explicitly close the stmt returned from tx stmt updatemoney because example does not even store references to it on the other hand tests and are explicitly closing that stmt so i wonder is there an actual need to close the prepared statements returned from tx stmt or rollback commit will close them automatically cc bradfitz ,1 27064,4273109921.0,IssuesEvent,2016-07-13 16:18:31,golang/go,https://api.github.com/repos/golang/go,closed,runtime: runtime-lldb test failure on Mac OS,OS-Darwin Testing,"Came across this while releasing go1.7rc1 on my Macbook Air: ``` --- FAIL: TestLldbPython (2.26s) runtime-lldb_test.go:182: Unexpected lldb output: Created target Created breakpoint Process launched Hit breakpoint Stopped at main.go:10 Stopped in main.main intvar = None FAIL FAIL runtime 28.910s ``` TryBots are happy, though, so could be an issue with whatever Python version I have installed on this machine?",1.0,"runtime: runtime-lldb test failure on Mac OS - Came across this while releasing go1.7rc1 on my Macbook Air: ``` --- FAIL: TestLldbPython (2.26s) runtime-lldb_test.go:182: Unexpected lldb output: Created target Created breakpoint Process launched Hit breakpoint Stopped at main.go:10 Stopped in main.main intvar = None FAIL FAIL runtime 28.910s ``` TryBots are happy, though, so could be an issue with whatever Python version I have installed on this machine?",0,runtime runtime lldb test failure on mac os came across this while releasing on my macbook air fail testlldbpython runtime lldb test go unexpected lldb output created target created breakpoint process launched hit breakpoint stopped at main go stopped in main main intvar none fail fail runtime trybots are happy though so could be an issue with whatever python version i have installed on this machine ,0 47882,7359096522.0,IssuesEvent,2018-03-10 02:02:30,golang/go,https://api.github.com/repos/golang/go,closed,text/scanner: add examples,Documentation help wanted,"I recently worked with the text/scanner package and, although the documentation was straight forward, it could stand to use more [examples](https://golang.org/pkg/text/scanner/#pkg-examples). I've been looking for opportunities to contribute to Go and I wouldn't mind working on improving the examples of the text/scanner package. I would like to add examples detailing the use of white space modifiers and tokens, as well as the various scanner and position methods. I would keep each example succinct, of course. Are there particular guidelines to follow when it comes to examples?",1.0,"text/scanner: add examples - I recently worked with the text/scanner package and, although the documentation was straight forward, it could stand to use more [examples](https://golang.org/pkg/text/scanner/#pkg-examples). I've been looking for opportunities to contribute to Go and I wouldn't mind working on improving the examples of the text/scanner package. I would like to add examples detailing the use of white space modifiers and tokens, as well as the various scanner and position methods. I would keep each example succinct, of course. Are there particular guidelines to follow when it comes to examples?",1,text scanner add examples i recently worked with the text scanner package and although the documentation was straight forward it could stand to use more i ve been looking for opportunities to contribute to go and i wouldn t mind working on improving the examples of the text scanner package i would like to add examples detailing the use of white space modifiers and tokens as well as the various scanner and position methods i would keep each example succinct of course are there particular guidelines to follow when it comes to examples ,1 389692,26830072290.0,IssuesEvent,2023-02-02 15:26:50,golang/go,https://api.github.com/repos/golang/go,closed,x/website: go1.20 docs refer to strings.Clone as new,Documentation NeedsFix website,"### What did you do? Visited https://go.dev/doc/go1.20 ### What did you expect to see? No reference to strings.Clone as being new. I believe it was introduced in Go 1.18 for strings (https://go.dev/doc/go1.18) (but in 1.20 for bytes 🙂 ) ### What did you see instead? The following reference to a new function: `The new [Clone](https://go.dev/pkg/strings/#Clone) function allocates a copy of a string.` ",1.0,"x/website: go1.20 docs refer to strings.Clone as new - ### What did you do? Visited https://go.dev/doc/go1.20 ### What did you expect to see? No reference to strings.Clone as being new. I believe it was introduced in Go 1.18 for strings (https://go.dev/doc/go1.18) (but in 1.20 for bytes 🙂 ) ### What did you see instead? The following reference to a new function: `The new [Clone](https://go.dev/pkg/strings/#Clone) function allocates a copy of a string.` ",1,x website docs refer to strings clone as new what did you do visited what did you expect to see no reference to strings clone as being new i believe it was introduced in go for strings but in for bytes 🙂 what did you see instead the following reference to a new function the new function allocates a copy of a string ,1 300179,22644648211.0,IssuesEvent,2022-07-01 07:29:31,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: cover tool help command syntax does not work on Windows ,Documentation WaitingForInfo NeedsFix," ### What version of Go are you using (`go version`)? 
1.17.5
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Windows ### What did you do? Running 'go tool cover -help' issues a help message that includes this command suggestion: ` go tool cover -func=c.out ` This works on the Mac and Linux, but not on Windows. On Windows it produces the following error message: ` too many arguments For usage information, run ""go tool cover -help"" ` The correct way to call this is: ` go tool cover -func c.out ` This works on all platforms. Note that this bad usage pattern is sprinkled throughout the go ecosystem. For example, this web page: https://pkg.go.dev/cmd/cover, has this line: ` Cover is a program for analyzing the coverage profiles generated by 'go test -coverprofile=cover.out'. ` However, running that line in a windows cmd terminal produces: ` no required module provides package .out; to add it: go get .out ` Or here: https://pkg.go.dev/cmd/go#hdr-Build_constraints, it uses examples of `-buildmode=mode`, even though the documentation earlier specs it as `-buildmode mode`. This clearly is a longstanding problem that should be easy to clean up. ",1.0,"cmd/go: cover tool help command syntax does not work on Windows - ### What version of Go are you using (`go version`)? 
1.17.5
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Windows ### What did you do? Running 'go tool cover -help' issues a help message that includes this command suggestion: ` go tool cover -func=c.out ` This works on the Mac and Linux, but not on Windows. On Windows it produces the following error message: ` too many arguments For usage information, run ""go tool cover -help"" ` The correct way to call this is: ` go tool cover -func c.out ` This works on all platforms. Note that this bad usage pattern is sprinkled throughout the go ecosystem. For example, this web page: https://pkg.go.dev/cmd/cover, has this line: ` Cover is a program for analyzing the coverage profiles generated by 'go test -coverprofile=cover.out'. ` However, running that line in a windows cmd terminal produces: ` no required module provides package .out; to add it: go get .out ` Or here: https://pkg.go.dev/cmd/go#hdr-Build_constraints, it uses examples of `-buildmode=mode`, even though the documentation earlier specs it as `-buildmode mode`. This clearly is a longstanding problem that should be easy to clean up. ",1,cmd go cover tool help command syntax does not work on windows what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env windows what did you do running go tool cover help issues a help message that includes this command suggestion go tool cover func c out this works on the mac and linux but not on windows on windows it produces the following error message too many arguments for usage information run go tool cover help the correct way to call this is go tool cover func c out this works on all platforms note that this bad usage pattern is sprinkled throughout the go ecosystem for example this web page has this line cover is a program for analyzing the coverage profiles generated by go test coverprofile cover out however running that line in a windows cmd terminal produces no required module provides package out to add it go get out or here it uses examples of buildmode mode even though the documentation earlier specs it as buildmode mode this clearly is a longstanding problem that should be easy to clean up ,1 82063,10268250761.0,IssuesEvent,2019-08-23 05:33:24,golang/go,https://api.github.com/repos/golang/go,closed,unsafe docs and SliceHeader: I am not sure what is defined here,Documentation,"### What version of Go are you using (`go version`)? 1.12, but N/A ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for `unsafe`. ### What did you expect to see? Something that did not confuse me. ### What did you see instead? Something that confused me. > In general, `reflect.SliceHeader and` `reflect.StringHeader` should be used only as `*reflect.SliceHeader` and `*reflect.StringHeader` pointing at actual slices or strings, never as plain structs. A program should not declare or allocate variables of these struct types. This has an accompanying example: ``` // INVALID: a directly-declared header will not hold Data as a reference. var hdr reflect.StringHeader hdr.Data = uintptr(unsafe.Pointer(p)) hdr.Len = n s := *(*string)(unsafe.Pointer(&hdr)) // p possibly already lost ``` What's not obvious to me: Is the *only* reason this is ""INVALID"" that p might already be lost, such that a `runtime.KeepAlive(p)` after the last line would have saved it? Or is this also intended to cover the possibility that some future version of Go may have additional unspecified magic in a slice object which is not in the `SliceHeader` parts, such that simply creating a SliceHeader (or a StringHeader) doesn't actually make a thing which could be a valid object? I've been writing code which has a pointer (which is persistent, and in a data structure which survives past the current scope, thus at no risk of being garbage collected), and which does something to the effect of: ``` asUint16 := *(*[]uint16)(unsafe.Pointer(&reflect.SliceHeader{Data: uintptr(unsafe.Pointer(obj.ptr)), Len: int(obj.len), Cap: int(obj.len)})) ``` In fact, obj.ptr isn't going away, so I'm not worried about garbage collection. But if an actual Slice were not exactly the same size as a SliceHeader, but rather, the SliceHeader were just a *prefix* of the actual internal slice representation... This code would in fact be just plain wrong, because other code might try to access the ""rest"" of the slice object, and not find it. Instead, I'd need to do something like: ``` var u []uint16 h := (*reflect.SliceHeader)&u h.Data, h.Len, h.Cap = uintptr(obj.ptr), obj.len, obj.len ``` Which is, I suppose, certainly no harder to read, but I'm not sure whether it offers any semantic difference, apart from `u` holding the reference to the pointer, in a way that a temporary slice header object wouldn't. (Related-ish: #20171, #19367.) ",1.0,"unsafe docs and SliceHeader: I am not sure what is defined here - ### What version of Go are you using (`go version`)? 1.12, but N/A ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for `unsafe`. ### What did you expect to see? Something that did not confuse me. ### What did you see instead? Something that confused me. > In general, `reflect.SliceHeader and` `reflect.StringHeader` should be used only as `*reflect.SliceHeader` and `*reflect.StringHeader` pointing at actual slices or strings, never as plain structs. A program should not declare or allocate variables of these struct types. This has an accompanying example: ``` // INVALID: a directly-declared header will not hold Data as a reference. var hdr reflect.StringHeader hdr.Data = uintptr(unsafe.Pointer(p)) hdr.Len = n s := *(*string)(unsafe.Pointer(&hdr)) // p possibly already lost ``` What's not obvious to me: Is the *only* reason this is ""INVALID"" that p might already be lost, such that a `runtime.KeepAlive(p)` after the last line would have saved it? Or is this also intended to cover the possibility that some future version of Go may have additional unspecified magic in a slice object which is not in the `SliceHeader` parts, such that simply creating a SliceHeader (or a StringHeader) doesn't actually make a thing which could be a valid object? I've been writing code which has a pointer (which is persistent, and in a data structure which survives past the current scope, thus at no risk of being garbage collected), and which does something to the effect of: ``` asUint16 := *(*[]uint16)(unsafe.Pointer(&reflect.SliceHeader{Data: uintptr(unsafe.Pointer(obj.ptr)), Len: int(obj.len), Cap: int(obj.len)})) ``` In fact, obj.ptr isn't going away, so I'm not worried about garbage collection. But if an actual Slice were not exactly the same size as a SliceHeader, but rather, the SliceHeader were just a *prefix* of the actual internal slice representation... This code would in fact be just plain wrong, because other code might try to access the ""rest"" of the slice object, and not find it. Instead, I'd need to do something like: ``` var u []uint16 h := (*reflect.SliceHeader)&u h.Data, h.Len, h.Cap = uintptr(obj.ptr), obj.len, obj.len ``` Which is, I suppose, certainly no harder to read, but I'm not sure whether it offers any semantic difference, apart from `u` holding the reference to the pointer, in a way that a temporary slice header object wouldn't. (Related-ish: #20171, #19367.) ",1,unsafe docs and sliceheader i am not sure what is defined here what version of go are you using go version but n a does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env n a what did you do read the documentation for unsafe what did you expect to see something that did not confuse me what did you see instead something that confused me in general reflect sliceheader and reflect stringheader should be used only as reflect sliceheader and reflect stringheader pointing at actual slices or strings never as plain structs a program should not declare or allocate variables of these struct types this has an accompanying example invalid a directly declared header will not hold data as a reference var hdr reflect stringheader hdr data uintptr unsafe pointer p hdr len n s string unsafe pointer hdr p possibly already lost what s not obvious to me is the only reason this is invalid that p might already be lost such that a runtime keepalive p after the last line would have saved it or is this also intended to cover the possibility that some future version of go may have additional unspecified magic in a slice object which is not in the sliceheader parts such that simply creating a sliceheader or a stringheader doesn t actually make a thing which could be a valid object i ve been writing code which has a pointer which is persistent and in a data structure which survives past the current scope thus at no risk of being garbage collected and which does something to the effect of unsafe pointer reflect sliceheader data uintptr unsafe pointer obj ptr len int obj len cap int obj len in fact obj ptr isn t going away so i m not worried about garbage collection but if an actual slice were not exactly the same size as a sliceheader but rather the sliceheader were just a prefix of the actual internal slice representation this code would in fact be just plain wrong because other code might try to access the rest of the slice object and not find it instead i d need to do something like var u h reflect sliceheader u h data h len h cap uintptr obj ptr obj len obj len which is i suppose certainly no harder to read but i m not sure whether it offers any semantic difference apart from u holding the reference to the pointer in a way that a temporary slice header object wouldn t related ish ,1 32182,6038104812.0,IssuesEvent,2017-06-09 20:29:49,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: typo in test.go doc,Documentation NeedsFix Suggested,"In the doc string in src/cmd/go/test.go, line 65 it says: '...no arguments. It compiles...'. There are two spaces before the 'It', should be only one.",1.0,"cmd/go: typo in test.go doc - In the doc string in src/cmd/go/test.go, line 65 it says: '...no arguments. It compiles...'. There are two spaces before the 'It', should be only one.",1,cmd go typo in test go doc in the doc string in src cmd go test go line it says no arguments it compiles there are two spaces before the it should be only one ,1 175472,14530066888.0,IssuesEvent,2020-12-14 18:42:36,golang/go,https://api.github.com/repos/golang/go,closed,x/pkgsite: document that GitHub PRs are accepted in the CONTRIBUTING.md,Documentation NeedsFix Suggested help wanted pkgsite,"Per https://golang.org/doc/contribute.html#sending_a_change_github, x/pkgsite accepts PRs. We should add this to the [CONTRIBUTING.md](https://github.com/golang/pkgsite/blob/master/CONTRIBUTING.md#getting-started), so that new contributors are aware of this option for contributing. ",1.0,"x/pkgsite: document that GitHub PRs are accepted in the CONTRIBUTING.md - Per https://golang.org/doc/contribute.html#sending_a_change_github, x/pkgsite accepts PRs. We should add this to the [CONTRIBUTING.md](https://github.com/golang/pkgsite/blob/master/CONTRIBUTING.md#getting-started), so that new contributors are aware of this option for contributing. ",1,x pkgsite document that github prs are accepted in the contributing md per x pkgsite accepts prs we should add this to the so that new contributors are aware of this option for contributing ,1 56614,13893832039.0,IssuesEvent,2020-10-19 13:59:39,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go/internal/renameio: TestConcurrentReadsAndWrites failure on ios-arm64-corellium builder,Builders NeedsInvestigation OS-Darwin mobile,"The `ios-arm64-corellium` builder seems to be affected by the same `darwin` kernel bug reported in #33041. Perhaps we should expand the `skip` for that bug to also apply to `ios-arm64-corellium`, although it's not obvious to me how we could apply the skip to only the affected kernel. CC @cherrymui @dmitshur [2020-10-17T00:26:52-a2eb53c/ios-arm64-corellium](https://build.golang.org/log/a6130e0004d62ba55ad1eced5a39806618b7b0c5) [2020-10-16T18:54:38-570b49d/ios-arm64-corellium](https://build.golang.org/log/162b21b2e9af2efa400c3bcc8466c4cf67a298d1) [2020-10-12T17:23:06-1aa43a5/ios-arm64-corellium](https://build.golang.org/log/ed899e6a1307915bb9270cbc83e7e06cb1926328) [2020-10-06T19:39:32-1fb149f/ios-arm64-corellium](https://build.golang.org/log/74a338f801881c51267dcfec563e2a1c8e0359c4) ",1.0,"cmd/go/internal/renameio: TestConcurrentReadsAndWrites failure on ios-arm64-corellium builder - The `ios-arm64-corellium` builder seems to be affected by the same `darwin` kernel bug reported in #33041. Perhaps we should expand the `skip` for that bug to also apply to `ios-arm64-corellium`, although it's not obvious to me how we could apply the skip to only the affected kernel. CC @cherrymui @dmitshur [2020-10-17T00:26:52-a2eb53c/ios-arm64-corellium](https://build.golang.org/log/a6130e0004d62ba55ad1eced5a39806618b7b0c5) [2020-10-16T18:54:38-570b49d/ios-arm64-corellium](https://build.golang.org/log/162b21b2e9af2efa400c3bcc8466c4cf67a298d1) [2020-10-12T17:23:06-1aa43a5/ios-arm64-corellium](https://build.golang.org/log/ed899e6a1307915bb9270cbc83e7e06cb1926328) [2020-10-06T19:39:32-1fb149f/ios-arm64-corellium](https://build.golang.org/log/74a338f801881c51267dcfec563e2a1c8e0359c4) ",0,cmd go internal renameio testconcurrentreadsandwrites failure on ios corellium builder the ios corellium builder seems to be affected by the same darwin kernel bug reported in perhaps we should expand the skip for that bug to also apply to ios corellium although it s not obvious to me how we could apply the skip to only the affected kernel cc cherrymui dmitshur ,0 9404,6886910800.0,IssuesEvent,2017-11-21 21:14:29,golang/go,https://api.github.com/repos/golang/go,closed,crypto/aes: linux/arm64 Go 1.9 performance is +20X slower than OpenSSL,Performance,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9.2 linux/arm64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""arm64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""arm64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH="""" GORACE="""" GOROOT=""/usr/lib/go-1.6"" GOTOOLDIR=""/usr/lib/go-1.6/pkg/tool/linux_arm64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? go test crypto/cipher -bench GCM ### What did you expect to see? Performance can be on par with OpenSSL (https://blog.cloudflare.com/content/images/2017/11/sym_key_1_core.png) ### What did you see instead? +20X slower than OpenSSL( https://blog.cloudflare.com/content/images/2017/11/go_sym_key_1_core.png) ",True,"crypto/aes: linux/arm64 Go 1.9 performance is +20X slower than OpenSSL - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9.2 linux/arm64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""arm64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""arm64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH="""" GORACE="""" GOROOT=""/usr/lib/go-1.6"" GOTOOLDIR=""/usr/lib/go-1.6/pkg/tool/linux_arm64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? go test crypto/cipher -bench GCM ### What did you expect to see? Performance can be on par with OpenSSL (https://blog.cloudflare.com/content/images/2017/11/sym_key_1_core.png) ### What did you see instead? +20X slower than OpenSSL( https://blog.cloudflare.com/content/images/2017/11/go_sym_key_1_core.png) ",0,crypto aes linux go performance is slower than openssl please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath gorace goroot usr lib go gotooldir usr lib go pkg tool linux cc gcc gogccflags fpic pthread fmessage length cxx g cgo enabled what did you do go test crypto cipher bench gcm what did you expect to see performance can be on par with openssl what did you see instead slower than openssl ,0 414321,27984207650.0,IssuesEvent,2023-03-26 14:08:07,golang/go,https://api.github.com/repos/golang/go,closed,io: Documentation of the io package at website is contrary to its documentation in comments inside source code.,Documentation,"### What version of Go are you using (`go version`)? go version go1.20.2 windows/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? O.S. is Microsoft Windows 10. CPU uses Intel x86-64 (a.k.a. AMD64) architecture. ### What did you do? Documentation of the `io` package at website states following. > An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF. Documentation of the same `io` package in comments inside the source code states following. > EOF is the error returned by Read when no more input is available. ### What did you expect to see? I expect to see no controversy in documentation. ### What did you see instead? I saw the controversy in documentation. ",1.0,"io: Documentation of the io package at website is contrary to its documentation in comments inside source code. - ### What version of Go are you using (`go version`)? go version go1.20.2 windows/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? O.S. is Microsoft Windows 10. CPU uses Intel x86-64 (a.k.a. AMD64) architecture. ### What did you do? Documentation of the `io` package at website states following. > An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF. Documentation of the same `io` package in comments inside the source code states following. > EOF is the error returned by Read when no more input is available. ### What did you expect to see? I expect to see no controversy in documentation. ### What did you see instead? I saw the controversy in documentation. ",1,io documentation of the io package at website is contrary to its documentation in comments inside source code what version of go are you using go version go version windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env o s is microsoft windows cpu uses intel a k a architecture what did you do documentation of the io package at website states following an instance of this general case is that a reader returning a non zero number of bytes at the end of the input stream may return either err eof or err nil the next read should return eof documentation of the same io package in comments inside the source code states following eof is the error returned by read when no more input is available what did you expect to see i expect to see no controversy in documentation what did you see instead i saw the controversy in documentation ,1 214635,16569051449.0,IssuesEvent,2021-05-30 02:38:18,golang/go,https://api.github.com/repos/golang/go,closed,go/types: unexport the GoVersion configuration option for Go 1.17,Documentation NeedsFix release-blocker,"`+pkg go/types, type Config struct, GoVersion string` The `GoVersion` field was added to `types.Config` to configure the language version being type checked. CC @griesemer ",1.0,"go/types: unexport the GoVersion configuration option for Go 1.17 - `+pkg go/types, type Config struct, GoVersion string` The `GoVersion` field was added to `types.Config` to configure the language version being type checked. CC @griesemer ",1,go types unexport the goversion configuration option for go pkg go types type config struct goversion string the goversion field was added to types config to configure the language version being type checked cc griesemer ,1 43306,7037406856.0,IssuesEvent,2017-12-28 14:40:44,golang/go,https://api.github.com/repos/golang/go,closed,doc: add Go to the list of languages at syntax-across-languages-per-language,Documentation help wanted,"Looks like Go is missing from the list: http://rigaux.org/language-study/syntax-across-languages-per-language/what-is-missing.html",1.0,"doc: add Go to the list of languages at syntax-across-languages-per-language - Looks like Go is missing from the list: http://rigaux.org/language-study/syntax-across-languages-per-language/what-is-missing.html",1,doc add go to the list of languages at syntax across languages per language looks like go is missing from the list ,1 11613,3508959598.0,IssuesEvent,2016-01-08 20:18:42,golang/go,https://api.github.com/repos/golang/go,closed,math/big: Typo in the documentation of Int.DivMod,Documentation,"The documentation for DivMod, in the big library, suggests that z.DivMod(x,y,w) sets z to the quotient q and w to the modulus m, where q and m satisfy > m = x - y*q with 0 <= m < |q| I believe that this should read > m = x - y*q with 0 <= m < |y| so that it agrees with the reference mentioned in the documentation for DivMod: Raymond T. Boute, “The Euclidean definition of the functions div and mod”. ACM Transactions on Programming Languages and Systems (TOPLAS), 14(2):127-144, New York, NY, USA, 4/1992. ACM press. ",1.0,"math/big: Typo in the documentation of Int.DivMod - The documentation for DivMod, in the big library, suggests that z.DivMod(x,y,w) sets z to the quotient q and w to the modulus m, where q and m satisfy > m = x - y*q with 0 <= m < |q| I believe that this should read > m = x - y*q with 0 <= m < |y| so that it agrees with the reference mentioned in the documentation for DivMod: Raymond T. Boute, “The Euclidean definition of the functions div and mod”. ACM Transactions on Programming Languages and Systems (TOPLAS), 14(2):127-144, New York, NY, USA, 4/1992. ACM press. ",1,math big typo in the documentation of int divmod the documentation for divmod in the big library suggests that z divmod x y w sets z to the quotient q and w to the modulus m where q and m satisfy m x y q with m q i believe that this should read m x y q with m y so that it agrees with the reference mentioned in the documentation for divmod raymond t boute “the euclidean definition of the functions div and mod” acm transactions on programming languages and systems toplas new york ny usa acm press ,1 40053,6796333191.0,IssuesEvent,2017-11-01 18:38:49,golang/go,https://api.github.com/repos/golang/go,closed,os/signal: document how to forward all signals,Documentation HelpWanted,"I'm writing a command line wrapper that sets some state in the world, starts a child process, waits for it to complete, and then unsets some state in the world. So basically something like ```go doSomeStatefulThing() cmd := exec.Command(""subcmd"", args...) cmd.Stdin = os.Stdin cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr err := cmd.Run() undoSomeStatefulThing() return err ``` I missed the line in the `signal.Notify` docs that says > If no signals are provided, all incoming signals will be relayed to c. Otherwise, just the provided signals will. It might be good to provide a second Example for Notify where the args... list is empty, for people who are silly like me and miss the doc. (It might also be good if it was easier to set up a proxied command - it seems like it's easy to miss some of the steps involved in proxying through all FD's/signals in both directions.)",1.0,"os/signal: document how to forward all signals - I'm writing a command line wrapper that sets some state in the world, starts a child process, waits for it to complete, and then unsets some state in the world. So basically something like ```go doSomeStatefulThing() cmd := exec.Command(""subcmd"", args...) cmd.Stdin = os.Stdin cmd.Stdout = os.Stdout cmd.Stderr = os.Stderr err := cmd.Run() undoSomeStatefulThing() return err ``` I missed the line in the `signal.Notify` docs that says > If no signals are provided, all incoming signals will be relayed to c. Otherwise, just the provided signals will. It might be good to provide a second Example for Notify where the args... list is empty, for people who are silly like me and miss the doc. (It might also be good if it was easier to set up a proxied command - it seems like it's easy to miss some of the steps involved in proxying through all FD's/signals in both directions.)",1,os signal document how to forward all signals i m writing a command line wrapper that sets some state in the world starts a child process waits for it to complete and then unsets some state in the world so basically something like go dosomestatefulthing cmd exec command subcmd args cmd stdin os stdin cmd stdout os stdout cmd stderr os stderr err cmd run undosomestatefulthing return err i missed the line in the signal notify docs that says if no signals are provided all incoming signals will be relayed to c otherwise just the provided signals will it might be good to provide a second example for notify where the args list is empty for people who are silly like me and miss the doc it might also be good if it was easier to set up a proxied command it seems like it s easy to miss some of the steps involved in proxying through all fd s signals in both directions ,1 37348,9994595442.0,IssuesEvent,2019-07-11 18:04:31,golang/go,https://api.github.com/repos/golang/go,closed,x/playground: Deploy Playground Automatically,Builders NeedsFix,"We want to reduce toil and ensure that we’re running the latest Playground version for play.golang.org. The current process involves manual steps, which can be error-prone, forgotten, or interruptive. After this work, changes to Playground or a new Go release should be available on play.golang.org shortly after they’re made. In either scenario below, we need to ensure that we're always deploying playground built on the latest stable release of Go. It's possible to get this information from maintner. We have a number of other services that could benefit from CI/CD, but we should focus on solving this issue for playground for the moment, and see what we learn. ### Deploying the latest Playground: It’s possible to configure this flow entirely within Cloud Console and a `cloudbuild.yaml` file. - Grant App Engine access to Cloud Build - Create a cloudbuild.yaml file in the playground repo - Add step for gcloud app deploy - Configure build timeout to avoid currently documented issue - Create a Cloud Build trigger, and link to github.com/golang/playground - The user authorizing this trigger needs to be in the golang github org, and an admin of the playground repo on github. - Convert GO_VERSION in the playground Dockerfile to an ARG with a default value Our docker build step must populate the latest GO_VERSION when it builds. There are other options available for pushing directly from gerrit, but would involve additional manual configuration, as well as figuring out where to store it and document it. ### Deploying Playground with the latest Go release This update flow requires determining the latest stable Go release after it happens, then building deploying Playground with the new release. This workflow more involved, as Cloud Build doesn't provide a way to add the business logic that we want out of the box: mainly that we want to trigger based on the latest stable tagged release of a different repository, and not accidentally downgrade (say, if 1.11.x is tagged after 1.12.x) If either of these workflows feels too difficult to configure, or feels fragile, we should try a gerrit based flow instead. `cloudbuild.yaml` reference: https://cloud.google.com/cloud-build/docs/build-config App Engine automation quickstart: https://cloud.google.com/source-repositories/docs/quickstart-triggering-builds-with-source-repositories Cloud Build API for manual (or programmatic) triggers: https://cloud.google.com/cloud-build/docs/running-builds/start-build-manually",1.0,"x/playground: Deploy Playground Automatically - We want to reduce toil and ensure that we’re running the latest Playground version for play.golang.org. The current process involves manual steps, which can be error-prone, forgotten, or interruptive. After this work, changes to Playground or a new Go release should be available on play.golang.org shortly after they’re made. In either scenario below, we need to ensure that we're always deploying playground built on the latest stable release of Go. It's possible to get this information from maintner. We have a number of other services that could benefit from CI/CD, but we should focus on solving this issue for playground for the moment, and see what we learn. ### Deploying the latest Playground: It’s possible to configure this flow entirely within Cloud Console and a `cloudbuild.yaml` file. - Grant App Engine access to Cloud Build - Create a cloudbuild.yaml file in the playground repo - Add step for gcloud app deploy - Configure build timeout to avoid currently documented issue - Create a Cloud Build trigger, and link to github.com/golang/playground - The user authorizing this trigger needs to be in the golang github org, and an admin of the playground repo on github. - Convert GO_VERSION in the playground Dockerfile to an ARG with a default value Our docker build step must populate the latest GO_VERSION when it builds. There are other options available for pushing directly from gerrit, but would involve additional manual configuration, as well as figuring out where to store it and document it. ### Deploying Playground with the latest Go release This update flow requires determining the latest stable Go release after it happens, then building deploying Playground with the new release. This workflow more involved, as Cloud Build doesn't provide a way to add the business logic that we want out of the box: mainly that we want to trigger based on the latest stable tagged release of a different repository, and not accidentally downgrade (say, if 1.11.x is tagged after 1.12.x) If either of these workflows feels too difficult to configure, or feels fragile, we should try a gerrit based flow instead. `cloudbuild.yaml` reference: https://cloud.google.com/cloud-build/docs/build-config App Engine automation quickstart: https://cloud.google.com/source-repositories/docs/quickstart-triggering-builds-with-source-repositories Cloud Build API for manual (or programmatic) triggers: https://cloud.google.com/cloud-build/docs/running-builds/start-build-manually",0,x playground deploy playground automatically we want to reduce toil and ensure that we’re running the latest playground version for play golang org the current process involves manual steps which can be error prone forgotten or interruptive after this work changes to playground or a new go release should be available on play golang org shortly after they’re made in either scenario below we need to ensure that we re always deploying playground built on the latest stable release of go it s possible to get this information from maintner we have a number of other services that could benefit from ci cd but we should focus on solving this issue for playground for the moment and see what we learn deploying the latest playground it’s possible to configure this flow entirely within cloud console and a cloudbuild yaml file grant app engine access to cloud build create a cloudbuild yaml file in the playground repo add step for gcloud app deploy configure build timeout to avoid currently documented issue create a cloud build trigger and link to github com golang playground the user authorizing this trigger needs to be in the golang github org and an admin of the playground repo on github convert go version in the playground dockerfile to an arg with a default value our docker build step must populate the latest go version when it builds there are other options available for pushing directly from gerrit but would involve additional manual configuration as well as figuring out where to store it and document it deploying playground with the latest go release this update flow requires determining the latest stable go release after it happens then building deploying playground with the new release this workflow more involved as cloud build doesn t provide a way to add the business logic that we want out of the box mainly that we want to trigger based on the latest stable tagged release of a different repository and not accidentally downgrade say if x is tagged after x if either of these workflows feels too difficult to configure or feels fragile we should try a gerrit based flow instead cloudbuild yaml reference app engine automation quickstart cloud build api for manual or programmatic triggers ,0 2867,3675582915.0,IssuesEvent,2016-02-23 00:15:59,golang/go,https://api.github.com/repos/golang/go,closed,runtime: improve performance of == on arrays.,Performance,"What version of Go are you using (go version)? go1.5.3 What operating system and processor architecture are you using? Linux, amd64 What did you do? benchmarked `==` vs `bytes.Equal` for array types What did you expect to see? `==` be as fast as or faster than `bytes.Equal` What did you see instead? `==` is slower than `bytes.Equal` Given: ``` type A [16]byte var a1, a2 A ``` `a1== a2` is slower than `bytes.Equal(a1[:], a2[:])` with the regular gc compiler. On my machine, the two benchmarks: ``` type A [16]byte func BenchmarkEqual(b *testing.B) { a1 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} a2 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} b.ResetTimer() for i := 0; i < b.N; i++ { if a1 != a2 { b.Fatal(""not equal"") } } } func BenchmarkBytesEqual(b *testing.B) { a1 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} a2 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} b.ResetTimer() for i := 0; i < b.N; i++ { if !bytes.Equal(a1[:], a2[:]) { b.Fatal(""not equal"") } } } ``` result in times of: ``` BenchmarkEqual-12 200000000 6.02 ns/op BenchmarkBytesEqual-12 300000000 4.90 ns/op ``` It seems the same optimizations that have been applied to bytes.Equal could be applied to the code generated by the compiler (or the compiler could simply call the equivalent of the bytes.Equal function). I also ran the test with 8, 128, and 1024 byte arrays (as well as 16 bytes). The source code is [a_test.go.txt](https://github.com/golang/go/files/127410/a_test.go.txt). The results: ``` BenchmarkEqual8-12 200000000 5.78 ns/op BenchmarkBytesEqual8-12 300000000 4.89 ns/op BenchmarkEqual16-12 200000000 6.77 ns/op BenchmarkBytesEqual16-12 300000000 5.93 ns/op BenchmarkEqual128-12 200000000 8.48 ns/op BenchmarkBytesEqual128-12 200000000 7.57 ns/op BenchmarkEqual1024-12 50000000 30.1 ns/op BenchmarkBytesEqual1024-12 50000000 30.4 ns/op ``` As a side note, with gccgo the results are the opposite, `==` is faster than `bytes.Equal`. `bytes.Equal` with gccgo is also slower than `bytes.Equal` with the regular gc compiler.",True,"runtime: improve performance of == on arrays. - What version of Go are you using (go version)? go1.5.3 What operating system and processor architecture are you using? Linux, amd64 What did you do? benchmarked `==` vs `bytes.Equal` for array types What did you expect to see? `==` be as fast as or faster than `bytes.Equal` What did you see instead? `==` is slower than `bytes.Equal` Given: ``` type A [16]byte var a1, a2 A ``` `a1== a2` is slower than `bytes.Equal(a1[:], a2[:])` with the regular gc compiler. On my machine, the two benchmarks: ``` type A [16]byte func BenchmarkEqual(b *testing.B) { a1 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} a2 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} b.ResetTimer() for i := 0; i < b.N; i++ { if a1 != a2 { b.Fatal(""not equal"") } } } func BenchmarkBytesEqual(b *testing.B) { a1 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} a2 := A{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16} b.ResetTimer() for i := 0; i < b.N; i++ { if !bytes.Equal(a1[:], a2[:]) { b.Fatal(""not equal"") } } } ``` result in times of: ``` BenchmarkEqual-12 200000000 6.02 ns/op BenchmarkBytesEqual-12 300000000 4.90 ns/op ``` It seems the same optimizations that have been applied to bytes.Equal could be applied to the code generated by the compiler (or the compiler could simply call the equivalent of the bytes.Equal function). I also ran the test with 8, 128, and 1024 byte arrays (as well as 16 bytes). The source code is [a_test.go.txt](https://github.com/golang/go/files/127410/a_test.go.txt). The results: ``` BenchmarkEqual8-12 200000000 5.78 ns/op BenchmarkBytesEqual8-12 300000000 4.89 ns/op BenchmarkEqual16-12 200000000 6.77 ns/op BenchmarkBytesEqual16-12 300000000 5.93 ns/op BenchmarkEqual128-12 200000000 8.48 ns/op BenchmarkBytesEqual128-12 200000000 7.57 ns/op BenchmarkEqual1024-12 50000000 30.1 ns/op BenchmarkBytesEqual1024-12 50000000 30.4 ns/op ``` As a side note, with gccgo the results are the opposite, `==` is faster than `bytes.Equal`. `bytes.Equal` with gccgo is also slower than `bytes.Equal` with the regular gc compiler.",0,runtime improve performance of on arrays what version of go are you using go version what operating system and processor architecture are you using linux what did you do benchmarked vs bytes equal for array types what did you expect to see be as fast as or faster than bytes equal what did you see instead is slower than bytes equal given type a byte var a is slower than bytes equal with the regular gc compiler on my machine the two benchmarks type a byte func benchmarkequal b testing b a a b resettimer for i i b n i if b fatal not equal func benchmarkbytesequal b testing b a a b resettimer for i i b n i if bytes equal b fatal not equal result in times of benchmarkequal ns op benchmarkbytesequal ns op it seems the same optimizations that have been applied to bytes equal could be applied to the code generated by the compiler or the compiler could simply call the equivalent of the bytes equal function i also ran the test with and byte arrays as well as bytes the source code is the results ns op ns op ns op ns op ns op ns op ns op ns op as a side note with gccgo the results are the opposite is faster than bytes equal bytes equal with gccgo is also slower than bytes equal with the regular gc compiler ,0 436747,30567890355.0,IssuesEvent,2023-07-20 19:19:13,golang/go,https://api.github.com/repos/golang/go,reopened,doc: write release notes for Go 1.21,Documentation NeedsFix release-blocker umbrella,"This is the tracking issue for writing the Go 1.21 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.21. When the Go 1.21 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are https://github.com/golang/go/issues/54202, https://github.com/golang/go/issues/51400, https://github.com/golang/go/issues/47694, https://github.com/golang/go/issues/44513, etc. ",1.0,"doc: write release notes for Go 1.21 - This is the tracking issue for writing the Go 1.21 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.21. When the Go 1.21 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are https://github.com/golang/go/issues/54202, https://github.com/golang/go/issues/51400, https://github.com/golang/go/issues/47694, https://github.com/golang/go/issues/44513, etc. ",1,doc write release notes for go this is the tracking issue for writing the go release notes the version at tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 280093,24279971617.0,IssuesEvent,2022-09-28 16:31:36,golang/go,https://api.github.com/repos/golang/go,closed,os/signal: TestTerminalSignal is flaky due to GNU readline,Testing NeedsFix compiler/runtime,"### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.20-9aa7107cb5 Wed Sep 28 03:17:13 2022 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/zeke/.cache/go-build""
GOENV=""/home/zeke/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/zeke/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/zeke/go""
GOPRIVATE=""""
GOPROXY=""https://goproxy.cn,direct""
GOROOT=""/snap/go/9951""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/9951/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/zeke/src/golang/gotip/src/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1116265555=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I have `~/.inputrc` with this content: ```rc set editing-mode vi set keymap vi-command set show-mode-in-prompt on set vi-ins-mode-string \1\e[5 q\2 set vi-cmd-mode-string \1\e[1 q\2 ``` And run the test on tip: ``` ./run.bash go_test:os/signal ``` **Note**: I don't find an easy way to disable the test cache. I ended up add `""-v"", ""-count=1""` to `args` (the `-v` option helps revealing the abnormal behavior of the GNU readline library in the later section): https://github.com/golang/go/blob/a48fc816e703989b54845c5ce557c54a45cbfe9c/src/cmd/dist/test.go#L402-L407 ### What did you expect to see? The tests pass. ### What did you see instead? ``` ##### Building packages and commands. ##### Test execution environment. # GOARCH: amd64 # CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz # GOOS: linux # OS Version: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 ##### Testing packages. --- FAIL: TestTerminalSignal (10.01s) signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[5 qbash-5.1$ PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> \r<41870/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""test program entering read\r\n"" signal_cgo_test.go:145: ""^Zfg\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1885841870/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> g\r\n"" signal_cgo_test.go:145: ""bash: g: command not found\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> \r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> exit $?\r\n"" signal_cgo_test.go:145: ""exit\r\n"" signal_cgo_test.go:145: ""There are stopped jobs.\r\n"" signal_cgo_test.go:237: subprogram failed: signal: killed signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> read 1 byte: \""f\""\r\n"" FAIL FAIL os/signal 11.879s FAIL go tool dist: Failed: exit status 1 ``` ### What's wrong? Now remove `~/.inputrc` and run `gotip tool dist test go_test:os/signal` (which `./run.bash` calls): ```diff === CONT TestTerminalSignal signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""bash-5.1$ PS1='prompt> '\r\n"" - signal_cgo_test.go:145: ""prompt> \r<49327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""test program entering read\r\n"" signal_cgo_test.go:145: ""^Z\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build2200749327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""prompt> fg\r\n"" signal_cgo_test.go:145: ""GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build2200749327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""read newline\r\n"" signal_cgo_test.go:145: ""prompt> exit $?\r\n"" signal_cgo_test.go:145: ""exit\r\n"" --- PASS: TestTerminalSignal (0.13s) ``` Comparing to the output of `gotip test ./os/signal -v -count 1 -run ^TestTerminalSignal$`: ```diff === CONT TestTerminalSignal signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hbash-5.1$ PS1='prompt> '\r\n"" + signal_cgo_test.go:145: ""\x1b[?2004l\r\x1b[?2004hprompt> GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rtest program entering read\r\n"" signal_cgo_test.go:145: ""^Z\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hprompt> fg\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rGO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""read newline\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hprompt> exit $?\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rexit\r\n"" --- PASS: TestTerminalSignal (0.12s) ``` Even though both tests passed, the first one has shown something abnormal (see the highlighted lines in the output). Since `go tool dist test` does not pass `-v` to `go test`, we haven't noticed that. And when a special `~/.inputrc` file is used, the abnormal behavior of readline finally fails the test. I still don't understand why the GNU readline library works correctly when `TestTerminalSignal` is run by `go test` directly, but behaves abnormally when `go test` is called by `go tool dist test`. But the fix is easy, we just need to disable it with the bash option `--noediting`. CL coming soon. ",1.0,"os/signal: TestTerminalSignal is flaky due to GNU readline - ### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.20-9aa7107cb5 Wed Sep 28 03:17:13 2022 +0000 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/zeke/.cache/go-build""
GOENV=""/home/zeke/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/zeke/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/zeke/go""
GOPRIVATE=""""
GOPROXY=""https://goproxy.cn,direct""
GOROOT=""/snap/go/9951""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/9951/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/zeke/src/golang/gotip/src/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1116265555=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I have `~/.inputrc` with this content: ```rc set editing-mode vi set keymap vi-command set show-mode-in-prompt on set vi-ins-mode-string \1\e[5 q\2 set vi-cmd-mode-string \1\e[1 q\2 ``` And run the test on tip: ``` ./run.bash go_test:os/signal ``` **Note**: I don't find an easy way to disable the test cache. I ended up add `""-v"", ""-count=1""` to `args` (the `-v` option helps revealing the abnormal behavior of the GNU readline library in the later section): https://github.com/golang/go/blob/a48fc816e703989b54845c5ce557c54a45cbfe9c/src/cmd/dist/test.go#L402-L407 ### What did you expect to see? The tests pass. ### What did you see instead? ``` ##### Building packages and commands. ##### Test execution environment. # GOARCH: amd64 # CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz # GOOS: linux # OS Version: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 ##### Testing packages. --- FAIL: TestTerminalSignal (10.01s) signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[5 qbash-5.1$ PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> \r<41870/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""test program entering read\r\n"" signal_cgo_test.go:145: ""^Zfg\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1885841870/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> g\r\n"" signal_cgo_test.go:145: ""bash: g: command not found\r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> \r\n"" signal_cgo_test.go:145: ""\x1b[5 qprompt> exit $?\r\n"" signal_cgo_test.go:145: ""exit\r\n"" signal_cgo_test.go:145: ""There are stopped jobs.\r\n"" signal_cgo_test.go:237: subprogram failed: signal: killed signal_cgo_test.go:145: ""\x1b[5 qprompt> \r\x1b[5 qprompt> read 1 byte: \""f\""\r\n"" FAIL FAIL os/signal 11.879s FAIL go tool dist: Failed: exit status 1 ``` ### What's wrong? Now remove `~/.inputrc` and run `gotip tool dist test go_test:os/signal` (which `./run.bash` calls): ```diff === CONT TestTerminalSignal signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""bash-5.1$ PS1='prompt> '\r\n"" - signal_cgo_test.go:145: ""prompt> \r<49327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""test program entering read\r\n"" signal_cgo_test.go:145: ""^Z\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build2200749327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""prompt> fg\r\n"" signal_cgo_test.go:145: ""GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build2200749327/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""read newline\r\n"" signal_cgo_test.go:145: ""prompt> exit $?\r\n"" signal_cgo_test.go:145: ""exit\r\n"" --- PASS: TestTerminalSignal (0.13s) ``` Comparing to the output of `gotip test ./os/signal -v -count 1 -run ^TestTerminalSignal$`: ```diff === CONT TestTerminalSignal signal_cgo_test.go:145: ""PS1='prompt> '\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hbash-5.1$ PS1='prompt> '\r\n"" + signal_cgo_test.go:145: ""\x1b[?2004l\r\x1b[?2004hprompt> GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rtest program entering read\r\n"" signal_cgo_test.go:145: ""^Z\r\n"" signal_cgo_test.go:145: ""[1]+ Stopped GO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hprompt> fg\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rGO_TEST_TERMINAL_SIGNALS=1 /tmp/go-build1103848064/b001/signal.test -test.run=TestTerminalSignal\r\n"" signal_cgo_test.go:145: ""\r\n"" signal_cgo_test.go:145: ""read newline\r\n"" signal_cgo_test.go:145: ""\x1b[?2004hprompt> exit $?\r\n"" signal_cgo_test.go:145: ""\x1b[?2004l\rexit\r\n"" --- PASS: TestTerminalSignal (0.12s) ``` Even though both tests passed, the first one has shown something abnormal (see the highlighted lines in the output). Since `go tool dist test` does not pass `-v` to `go test`, we haven't noticed that. And when a special `~/.inputrc` file is used, the abnormal behavior of readline finally fails the test. I still don't understand why the GNU readline library works correctly when `TestTerminalSignal` is run by `go test` directly, but behaves abnormally when `go test` is called by `go tool dist test`. But the fix is easy, we just need to disable it with the bash option `--noediting`. CL coming soon. ",0,os signal testterminalsignal is flaky due to gnu readline what version of go are you using go version go version go version devel wed sep linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home zeke cache go build goenv home zeke config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home zeke go pkg mod gonoproxy gonosumdb goos linux gopath home zeke go goprivate goproxy goroot snap go gosumdb sum golang org gotmpdir gotooldir snap go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home zeke src golang gotip src go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread wl no gc sections fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do i have inputrc with this content rc set editing mode vi set keymap vi command set show mode in prompt on set vi ins mode string e q set vi cmd mode string e q and run the test on tip run bash go test os signal note i don t find an easy way to disable the test cache i ended up add v count to args the v option helps revealing the abnormal behavior of the gnu readline library in the later section what did you expect to see the tests pass what did you see instead building packages and commands test execution environment goarch cpu intel r core tm cpu goos linux os version linux generic ubuntu smp thu aug utc testing packages fail testterminalsignal signal cgo test go prompt r n signal cgo test go qbash prompt r n signal cgo test go qprompt r qprompt r signal test test run testterminalsignal r n signal cgo test go test program entering read r n signal cgo test go zfg r n signal cgo test go r n signal cgo test go stopped go test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go qprompt r qprompt g r n signal cgo test go bash g command not found r n signal cgo test go qprompt r qprompt r n signal cgo test go qprompt exit r n signal cgo test go exit r n signal cgo test go there are stopped jobs r n signal cgo test go subprogram failed signal killed signal cgo test go qprompt r qprompt read byte f r n fail fail os signal fail go tool dist failed exit status what s wrong now remove inputrc and run gotip tool dist test go test os signal which run bash calls diff cont testterminalsignal signal cgo test go prompt r n signal cgo test go bash prompt r n signal cgo test go prompt r signal test test run testterminalsignal r n signal cgo test go test program entering read r n signal cgo test go z r n signal cgo test go stopped go test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go prompt fg r n signal cgo test go go test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go r n signal cgo test go read newline r n signal cgo test go prompt exit r n signal cgo test go exit r n pass testterminalsignal comparing to the output of gotip test os signal v count run testterminalsignal diff cont testterminalsignal signal cgo test go prompt r n signal cgo test go prompt r n signal cgo test go r go test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go rtest program entering read r n signal cgo test go z r n signal cgo test go stopped go test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go fg r n signal cgo test go rgo test terminal signals tmp go signal test test run testterminalsignal r n signal cgo test go r n signal cgo test go read newline r n signal cgo test go exit r n signal cgo test go rexit r n pass testterminalsignal even though both tests passed the first one has shown something abnormal see the highlighted lines in the output since go tool dist test does not pass v to go test we haven t noticed that and when a special inputrc file is used the abnormal behavior of readline finally fails the test i still don t understand why the gnu readline library works correctly when testterminalsignal is run by go test directly but behaves abnormally when go test is called by go tool dist test but the fix is easy we just need to disable it with the bash option noediting cl coming soon ,0 83642,24112570458.0,IssuesEvent,2022-09-20 12:33:48,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/relui: flaky test timeout,Builders NeedsInvestigation,"``` #!watchflakes post <- pkg == ""golang.org/x/build/internal/relui"" && test == """" && `panic: test timed out` ``` Bug automatically created to track these flakes. — watchflakes ",1.0,"x/build/internal/relui: flaky test timeout - ``` #!watchflakes post <- pkg == ""golang.org/x/build/internal/relui"" && test == """" && `panic: test timed out` ``` Bug automatically created to track these flakes. — watchflakes ",0,x build internal relui flaky test timeout watchflakes post pkg golang org x build internal relui test panic test timed out bug automatically created to track these flakes — watchflakes ,0 38974,10272556151.0,IssuesEvent,2019-08-23 16:45:58,golang/go,https://api.github.com/repos/golang/go,closed,x/build: Migrate to new network storage on MacStadium,Builders NeedsFix,"MacStadium is deprecating the old storage SAN for a new NFS based storage. We should be able to automate moving the data over in `govc`, then updating `makemac` to use the new vSphere datastore name.",1.0,"x/build: Migrate to new network storage on MacStadium - MacStadium is deprecating the old storage SAN for a new NFS based storage. We should be able to automate moving the data over in `govc`, then updating `makemac` to use the new vSphere datastore name.",0,x build migrate to new network storage on macstadium macstadium is deprecating the old storage san for a new nfs based storage we should be able to automate moving the data over in govc then updating makemac to use the new vsphere datastore name ,0 46488,24562153226.0,IssuesEvent,2022-10-12 21:25:03,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: slower performance of array copies on arm64,Performance NeedsInvestigation compiler/runtime,"Originally came up in issue #54467 . If you run this program with `go test -bench=.* issue54467_test.go` on an arm64 machine, it is slower on tip than 1.19. ``` package datamove import ( ""testing"" ) var resultArray []Array func BenchmarkSliceOfArray(b *testing.B) { var r []Array s := make([]Array, 1000) for n := 0; n < b.N; n++ { r = moveSliceOfArrayData(s) } resultArray = r } type Array [2]int func moveSliceOfArrayData(s []Array) []Array { for i := 1; i < len(s); i++ { s[i-1], s[i] = s[i], s[i-1] } return s } ``` With 1.19: ``` BenchmarkSliceOfArray-4 331569 3594 ns/op ``` With tip: ``` BenchmarkSliceOfArray-4 264745 4529 ns/op ``` (Note: don't compare with 1.19.1, it has a separate issue that makes this code slow. Use 1.19.0.) The inner loop with 1.19 looks like this: ``` 0x0018 00024 (issue54467_test.go:22) SUB $1, R3, R4 0x001c 00028 (issue54467_test.go:22) LSL $4, R4, R5 0x0020 00032 (issue54467_test.go:22) MOVD (R0)(R5), R6 0x0024 00036 (issue54467_test.go:22) ADD R4<<4, R0, R4 0x0028 00040 (issue54467_test.go:22) MOVD 8(R4), R7 0x002c 00044 (issue54467_test.go:22) MOVD R6, p..autotmp_5-16(SP) 0x0030 00048 (issue54467_test.go:22) MOVD R7, p..autotmp_5-8(SP) 0x0034 00052 (issue54467_test.go:22) LSL $4, R3, R6 0x0038 00056 (issue54467_test.go:22) MOVD (R0)(R6), R7 0x003c 00060 (issue54467_test.go:22) ADD R3<<4, R0, R8 0x0040 00064 (issue54467_test.go:22) MOVD 8(R8), R9 0x0044 00068 (issue54467_test.go:22) MOVD R7, (R0)(R5) 0x0048 00072 (issue54467_test.go:22) MOVD R9, 8(R4) 0x004c 00076 (issue54467_test.go:22) MOVD p..autotmp_5-16(SP), R4 0x0050 00080 (issue54467_test.go:22) MOVD p..autotmp_5-8(SP), R5 0x0054 00084 (issue54467_test.go:22) MOVD R4, (R0)(R6) 0x0058 00088 (issue54467_test.go:22) MOVD R5, 8(R8) 0x005c 00092 (issue54467_test.go:21) ADD $1, R3, R3 0x0060 00096 (issue54467_test.go:21) CMP R3, R1 0x0064 00100 (issue54467_test.go:21) BGT 24 ``` The inner loop with tip looks like this: ``` 0x0018 00024 (/workdir/issue54467/issue54467_test.go:22) SUB $1, R3, R4 0x001c 00028 (/workdir/issue54467/issue54467_test.go:22) ADD R4<<4, R0, R4 0x0020 00032 (/workdir/issue54467/issue54467_test.go:22) LDP (R4), (R5, R6) 0x0024 00036 (/workdir/issue54467/issue54467_test.go:22) STP (R5, R6), p..autotmp_5-16(SP) 0x0028 00040 (/workdir/issue54467/issue54467_test.go:22) ADD R3<<4, R0, R5 0x002c 00044 (/workdir/issue54467/issue54467_test.go:22) LDP (R5), (R6, R7) 0x0030 00048 (/workdir/issue54467/issue54467_test.go:22) STP (R6, R7), (R4) 0x0034 00052 (/workdir/issue54467/issue54467_test.go:22) LDP p..autotmp_5-16(SP), (R4, R6) 0x0038 00056 (/workdir/issue54467/issue54467_test.go:22) STP (R4, R6), (R5) 0x003c 00060 (/workdir/issue54467/issue54467_test.go:21) ADD $1, R3, R3 0x0040 00064 (/workdir/issue54467/issue54467_test.go:21) CMP R3, R1 0x0044 00068 (/workdir/issue54467/issue54467_test.go:21) BGT 24 ``` Why is the tip inner loop slower? It looks like better code to me. Maybe the multi-load/multi-store ops are slower? @golang/arm ",True,"cmd/compile: slower performance of array copies on arm64 - Originally came up in issue #54467 . If you run this program with `go test -bench=.* issue54467_test.go` on an arm64 machine, it is slower on tip than 1.19. ``` package datamove import ( ""testing"" ) var resultArray []Array func BenchmarkSliceOfArray(b *testing.B) { var r []Array s := make([]Array, 1000) for n := 0; n < b.N; n++ { r = moveSliceOfArrayData(s) } resultArray = r } type Array [2]int func moveSliceOfArrayData(s []Array) []Array { for i := 1; i < len(s); i++ { s[i-1], s[i] = s[i], s[i-1] } return s } ``` With 1.19: ``` BenchmarkSliceOfArray-4 331569 3594 ns/op ``` With tip: ``` BenchmarkSliceOfArray-4 264745 4529 ns/op ``` (Note: don't compare with 1.19.1, it has a separate issue that makes this code slow. Use 1.19.0.) The inner loop with 1.19 looks like this: ``` 0x0018 00024 (issue54467_test.go:22) SUB $1, R3, R4 0x001c 00028 (issue54467_test.go:22) LSL $4, R4, R5 0x0020 00032 (issue54467_test.go:22) MOVD (R0)(R5), R6 0x0024 00036 (issue54467_test.go:22) ADD R4<<4, R0, R4 0x0028 00040 (issue54467_test.go:22) MOVD 8(R4), R7 0x002c 00044 (issue54467_test.go:22) MOVD R6, p..autotmp_5-16(SP) 0x0030 00048 (issue54467_test.go:22) MOVD R7, p..autotmp_5-8(SP) 0x0034 00052 (issue54467_test.go:22) LSL $4, R3, R6 0x0038 00056 (issue54467_test.go:22) MOVD (R0)(R6), R7 0x003c 00060 (issue54467_test.go:22) ADD R3<<4, R0, R8 0x0040 00064 (issue54467_test.go:22) MOVD 8(R8), R9 0x0044 00068 (issue54467_test.go:22) MOVD R7, (R0)(R5) 0x0048 00072 (issue54467_test.go:22) MOVD R9, 8(R4) 0x004c 00076 (issue54467_test.go:22) MOVD p..autotmp_5-16(SP), R4 0x0050 00080 (issue54467_test.go:22) MOVD p..autotmp_5-8(SP), R5 0x0054 00084 (issue54467_test.go:22) MOVD R4, (R0)(R6) 0x0058 00088 (issue54467_test.go:22) MOVD R5, 8(R8) 0x005c 00092 (issue54467_test.go:21) ADD $1, R3, R3 0x0060 00096 (issue54467_test.go:21) CMP R3, R1 0x0064 00100 (issue54467_test.go:21) BGT 24 ``` The inner loop with tip looks like this: ``` 0x0018 00024 (/workdir/issue54467/issue54467_test.go:22) SUB $1, R3, R4 0x001c 00028 (/workdir/issue54467/issue54467_test.go:22) ADD R4<<4, R0, R4 0x0020 00032 (/workdir/issue54467/issue54467_test.go:22) LDP (R4), (R5, R6) 0x0024 00036 (/workdir/issue54467/issue54467_test.go:22) STP (R5, R6), p..autotmp_5-16(SP) 0x0028 00040 (/workdir/issue54467/issue54467_test.go:22) ADD R3<<4, R0, R5 0x002c 00044 (/workdir/issue54467/issue54467_test.go:22) LDP (R5), (R6, R7) 0x0030 00048 (/workdir/issue54467/issue54467_test.go:22) STP (R6, R7), (R4) 0x0034 00052 (/workdir/issue54467/issue54467_test.go:22) LDP p..autotmp_5-16(SP), (R4, R6) 0x0038 00056 (/workdir/issue54467/issue54467_test.go:22) STP (R4, R6), (R5) 0x003c 00060 (/workdir/issue54467/issue54467_test.go:21) ADD $1, R3, R3 0x0040 00064 (/workdir/issue54467/issue54467_test.go:21) CMP R3, R1 0x0044 00068 (/workdir/issue54467/issue54467_test.go:21) BGT 24 ``` Why is the tip inner loop slower? It looks like better code to me. Maybe the multi-load/multi-store ops are slower? @golang/arm ",0,cmd compile slower performance of array copies on originally came up in issue if you run this program with go test bench test go on an machine it is slower on tip than package datamove import testing var resultarray array func benchmarksliceofarray b testing b var r array s make array for n n b n n r movesliceofarraydata s resultarray r type array int func movesliceofarraydata s array array for i i len s i s s s s return s with benchmarksliceofarray ns op with tip benchmarksliceofarray ns op note don t compare with it has a separate issue that makes this code slow use the inner loop with looks like this test go sub test go lsl test go movd test go add test go movd test go movd p autotmp sp test go movd p autotmp sp test go lsl test go movd test go add test go movd test go movd test go movd test go movd p autotmp sp test go movd p autotmp sp test go movd test go movd test go add test go cmp test go bgt the inner loop with tip looks like this workdir test go sub workdir test go add workdir test go ldp workdir test go stp p autotmp sp workdir test go add workdir test go ldp workdir test go stp workdir test go ldp p autotmp sp workdir test go stp workdir test go add workdir test go cmp workdir test go bgt why is the tip inner loop slower it looks like better code to me maybe the multi load multi store ops are slower golang arm ,0 26679,5281003805.0,IssuesEvent,2017-02-07 15:32:48,golang/go,https://api.github.com/repos/golang/go,closed,testing: not clear whether parallel tests can run in parallel with themselves,Documentation,"https://golang.org/pkg/testing/#T.Parallel says: > Parallel signals that this test is to be run in parallel with (and only with) other parallel tests. Is the test itself included in `other parallel tests`? You could understand that `other` means it's not included, but the wording isn't clear to me or a couple of people I've asked. This is important because people (including myself) often write parallel tests in a way that they don't break other parallel tests, but not themselves. For example, it might use `t.Name()` as a unique identifier/key in a database. I ran some quick tests and it does seem like a parallel test never runs in parallel with itself. Will post a doc CL soon.",1.0,"testing: not clear whether parallel tests can run in parallel with themselves - https://golang.org/pkg/testing/#T.Parallel says: > Parallel signals that this test is to be run in parallel with (and only with) other parallel tests. Is the test itself included in `other parallel tests`? You could understand that `other` means it's not included, but the wording isn't clear to me or a couple of people I've asked. This is important because people (including myself) often write parallel tests in a way that they don't break other parallel tests, but not themselves. For example, it might use `t.Name()` as a unique identifier/key in a database. I ran some quick tests and it does seem like a parallel test never runs in parallel with itself. Will post a doc CL soon.",1,testing not clear whether parallel tests can run in parallel with themselves says parallel signals that this test is to be run in parallel with and only with other parallel tests is the test itself included in other parallel tests you could understand that other means it s not included but the wording isn t clear to me or a couple of people i ve asked this is important because people including myself often write parallel tests in a way that they don t break other parallel tests but not themselves for example it might use t name as a unique identifier key in a database i ran some quick tests and it does seem like a parallel test never runs in parallel with itself will post a doc cl soon ,1 184331,14975290134.0,IssuesEvent,2021-01-28 05:47:50,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document new go/build/constraint package,Documentation NeedsFix help wanted release-blocker,"The new `go/build/constraint` package in Go 1.16 should be documented in the final Go 1.16 release notes as part of #40700. CC @rsc.",1.0,"doc/go1.16: document new go/build/constraint package - The new `go/build/constraint` package in Go 1.16 should be documented in the final Go 1.16 release notes as part of #40700. CC @rsc.",1,doc document new go build constraint package the new go build constraint package in go should be documented in the final go release notes as part of cc rsc ,1 57401,14107400780.0,IssuesEvent,2020-11-06 16:14:36,golang/go,https://api.github.com/repos/golang/go,opened,"doc, x/build/dashboard: document Go 1.16 requires at least OpenBSD 6.4, drop OpenBSD 6.2 builders",Builders NeedsDecision release-blocker,"Based on investigation and discussion in #42237 and #42408, and past support policy discussion in https://github.com/golang/go/issues/15227#issuecomment-293319876, we should drop OpenBSD 6.2 support from the upcoming Go 1.16 release. What's needed: - [ ] Disable `openbsd-{386,amd64}-62` builders for Go 1.16 and newer. - [ ] Document in Go 1.16 release notes that Go 1.16 requires at least OpenBSD 6.4: ""Go 1.15 was the last release that ran on OpenBSD 6.2. Go 1.16 requires OpenBSD 6.4 or newer."" - Ideally we should say OpenBSD 6.7 or newer, but we don't have builders to back up such a claim (see #35712), so I think this is the best we can say for now. - Ideally we would've pre-announced this earlier, like in [Go 1.11 release notes](https://golang.org/doc/go1.11#ports). Unfortunately we didn't have the information we have now earlier. Please comment if you think this plan can be improved. CC @golang/release, @ianlancetaylor, @4a6f656c, @prattmic, @bcmills.",1.0,"doc, x/build/dashboard: document Go 1.16 requires at least OpenBSD 6.4, drop OpenBSD 6.2 builders - Based on investigation and discussion in #42237 and #42408, and past support policy discussion in https://github.com/golang/go/issues/15227#issuecomment-293319876, we should drop OpenBSD 6.2 support from the upcoming Go 1.16 release. What's needed: - [ ] Disable `openbsd-{386,amd64}-62` builders for Go 1.16 and newer. - [ ] Document in Go 1.16 release notes that Go 1.16 requires at least OpenBSD 6.4: ""Go 1.15 was the last release that ran on OpenBSD 6.2. Go 1.16 requires OpenBSD 6.4 or newer."" - Ideally we should say OpenBSD 6.7 or newer, but we don't have builders to back up such a claim (see #35712), so I think this is the best we can say for now. - Ideally we would've pre-announced this earlier, like in [Go 1.11 release notes](https://golang.org/doc/go1.11#ports). Unfortunately we didn't have the information we have now earlier. Please comment if you think this plan can be improved. CC @golang/release, @ianlancetaylor, @4a6f656c, @prattmic, @bcmills.",0,doc x build dashboard document go requires at least openbsd drop openbsd builders based on investigation and discussion in and and past support policy discussion in we should drop openbsd support from the upcoming go release what s needed disable openbsd builders for go and newer document in go release notes that go requires at least openbsd go was the last release that ran on openbsd go requires openbsd or newer ideally we should say openbsd or newer but we don t have builders to back up such a claim see so i think this is the best we can say for now ideally we would ve pre announced this earlier like in unfortunately we didn t have the information we have now earlier please comment if you think this plan can be improved cc golang release ianlancetaylor prattmic bcmills ,0 30559,8559914263.0,IssuesEvent,2018-11-08 22:52:36,golang/go,https://api.github.com/repos/golang/go,closed,x/build: “Gerrit User XXX” displayed instead of actual name in Gerrit messages,Builders NeedsFix Soon,"https://github.com/golang/go/pull/28659#issuecomment-437027632 says ""Message from Gerrit User 5056"". This needs to be fixed, and soon. It's easy to fix - the usual Gerrit REST API ChangeInfo uses the right names. I'm perplexed as to why the maintner feed says these things but at least the bot could re-fetch the actual Gerrit comments directly from Gerrit (only when it needs to post one to GitHub, so fairly low rate) to find out real names. #28662 means that from Gerrit I can't tell who is writing the CL and this bug means that from GitHub I can't tell who is reviewing the CL. This is not really an acceptable review process.",1.0,"x/build: “Gerrit User XXX” displayed instead of actual name in Gerrit messages - https://github.com/golang/go/pull/28659#issuecomment-437027632 says ""Message from Gerrit User 5056"". This needs to be fixed, and soon. It's easy to fix - the usual Gerrit REST API ChangeInfo uses the right names. I'm perplexed as to why the maintner feed says these things but at least the bot could re-fetch the actual Gerrit comments directly from Gerrit (only when it needs to post one to GitHub, so fairly low rate) to find out real names. #28662 means that from Gerrit I can't tell who is writing the CL and this bug means that from GitHub I can't tell who is reviewing the CL. This is not really an acceptable review process.",0,x build “gerrit user xxx” displayed instead of actual name in gerrit messages says message from gerrit user this needs to be fixed and soon it s easy to fix the usual gerrit rest api changeinfo uses the right names i m perplexed as to why the maintner feed says these things but at least the bot could re fetch the actual gerrit comments directly from gerrit only when it needs to post one to github so fairly low rate to find out real names means that from gerrit i can t tell who is writing the cl and this bug means that from github i can t tell who is reviewing the cl this is not really an acceptable review process ,0 28622,8195313989.0,IssuesEvent,2018-08-31 05:14:55,golang/go,https://api.github.com/repos/golang/go,opened,"x/build: add a Windows Server, version 1803 (~""Windows 10"") builder",Builders OS-Windows,"GCE supports ""Windows Server, version 1803"": https://cloud.google.com/compute/docs/instances/windows/ We should run such a builder. See: https://go-review.googlesource.com/c/go/+/131976 https://docs.microsoft.com/en-us/windows-server/get-started/get-started-with-1803 It would've prevented #25722. /cc @johnsonj (who noted these things on CL 131976), @dmitshur ",1.0,"x/build: add a Windows Server, version 1803 (~""Windows 10"") builder - GCE supports ""Windows Server, version 1803"": https://cloud.google.com/compute/docs/instances/windows/ We should run such a builder. See: https://go-review.googlesource.com/c/go/+/131976 https://docs.microsoft.com/en-us/windows-server/get-started/get-started-with-1803 It would've prevented #25722. /cc @johnsonj (who noted these things on CL 131976), @dmitshur ",0,x build add a windows server version windows builder gce supports windows server version we should run such a builder see it would ve prevented cc johnsonj who noted these things on cl dmitshur ,0 79555,10131824854.0,IssuesEvent,2019-08-01 20:34:19,golang/go,https://api.github.com/repos/golang/go,closed,doc: summarize net/http noteworthy improvements for Go1.13,Documentation,This issue is a placeholder for us to comb through the net/http improvements such as https://github.com/golang/go/issues/30377#issuecomment-469959340 from @vancluever in which we now use SendFile/ReadFrom for Transport.Body if possible,1.0,doc: summarize net/http noteworthy improvements for Go1.13 - This issue is a placeholder for us to comb through the net/http improvements such as https://github.com/golang/go/issues/30377#issuecomment-469959340 from @vancluever in which we now use SendFile/ReadFrom for Transport.Body if possible,1,doc summarize net http noteworthy improvements for this issue is a placeholder for us to comb through the net http improvements such as from vancluever in which we now use sendfile readfrom for transport body if possible,1 11035,3454434494.0,IssuesEvent,2015-12-17 15:54:52,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document ListenAndServe does keep-alive stuff,Documentation,"Document that ListenAndServe is more than just Listen + Server. See comments in #12731 ",1.0,"net/http: document ListenAndServe does keep-alive stuff - Document that ListenAndServe is more than just Listen + Server. See comments in #12731 ",1,net http document listenandserve does keep alive stuff document that listenandserve is more than just listen server see comments in ,1 272360,20743963172.0,IssuesEvent,2022-03-14 20:36:43,golang/go,https://api.github.com/repos/golang/go,closed,x/website: update to latest spec just before release,Documentation NeedsFix release-blocker,"To get the most up-to-date spec into the 1.18 release, rather than cherry-picking possibly multiple CLs until the release, we should create a single CL (immediately before the release) in the release branch which contains a 1:1 copy of the latest spec at tip. cc: @dmitshur ",1.0,"x/website: update to latest spec just before release - To get the most up-to-date spec into the 1.18 release, rather than cherry-picking possibly multiple CLs until the release, we should create a single CL (immediately before the release) in the release branch which contains a 1:1 copy of the latest spec at tip. cc: @dmitshur ",1,x website update to latest spec just before release to get the most up to date spec into the release rather than cherry picking possibly multiple cls until the release we should create a single cl immediately before the release in the release branch which contains a copy of the latest spec at tip cc dmitshur ,1 54687,7918267974.0,IssuesEvent,2018-07-04 12:45:37,golang/go,https://api.github.com/repos/golang/go,closed,x/perf: error in README file,Documentation,"Installation instructions say: > The easiest way to install is to run `go get -u golang.org/x/perf`. But running the above command gives: ``` package golang.org/x/perf: no Go files in /Users/gbbr/go/src/golang.org/x/perf ``` I guess correct instruction would be: > The easiest way to install is to run `go get -u golang.org/x/perf/...`.",1.0,"x/perf: error in README file - Installation instructions say: > The easiest way to install is to run `go get -u golang.org/x/perf`. But running the above command gives: ``` package golang.org/x/perf: no Go files in /Users/gbbr/go/src/golang.org/x/perf ``` I guess correct instruction would be: > The easiest way to install is to run `go get -u golang.org/x/perf/...`.",1,x perf error in readme file installation instructions say the easiest way to install is to run go get u golang org x perf but running the above command gives package golang org x perf no go files in users gbbr go src golang org x perf i guess correct instruction would be the easiest way to install is to run go get u golang org x perf ,1 34965,6397004404.0,IssuesEvent,2017-08-04 16:53:55,golang/go,https://api.github.com/repos/golang/go,closed,doc/editors: mention that Gogland can be distributed as part of Jetbrains paid IDEs,Documentation,"### What version of Go are you using (`go version`)? n/a ### What operating system and processor architecture are you using (`go env`)? n/a ### What did you do? on http://tip.golang.org/doc/editors.html, this sentence is not totally true: ```text Gogland: Gogland is distributed either as a standalone IDE or as a plugin for the IntelliJ Platform IDEs ``` I prefere this one: ```text Gogland: Gogland is distributed either as a standalone IDE or as a plugin for Intellij IDEA Ultimate and other Jetbrain paid IDEs. ``` ### What did you expect to see? n/a ### What did you see instead? n/a ",1.0,"doc/editors: mention that Gogland can be distributed as part of Jetbrains paid IDEs - ### What version of Go are you using (`go version`)? n/a ### What operating system and processor architecture are you using (`go env`)? n/a ### What did you do? on http://tip.golang.org/doc/editors.html, this sentence is not totally true: ```text Gogland: Gogland is distributed either as a standalone IDE or as a plugin for the IntelliJ Platform IDEs ``` I prefere this one: ```text Gogland: Gogland is distributed either as a standalone IDE or as a plugin for Intellij IDEA Ultimate and other Jetbrain paid IDEs. ``` ### What did you expect to see? n/a ### What did you see instead? n/a ",1,doc editors mention that gogland can be distributed as part of jetbrains paid ides what version of go are you using go version n a what operating system and processor architecture are you using go env n a what did you do on this sentence is not totally true text gogland gogland is distributed either as a standalone ide or as a plugin for the intellij platform ides i prefere this one text gogland gogland is distributed either as a standalone ide or as a plugin for intellij idea ultimate and other jetbrain paid ides what did you expect to see n a what did you see instead n a ,1 10687,7276863376.0,IssuesEvent,2018-02-21 17:35:43,golang/go,https://api.github.com/repos/golang/go,closed,math: Sqrt not intrinsified on mips64,Performance,"``` $ go version go version go1.10 linux/amd64 ``` ``` func f(x float64) float64 { return math.Sqrt(x) } ``` `GOARCH=mips`: ``` 0x0000 00000 (test.go:5) MOVF """".x(FP), F1 0x0004 00004 (test.go:5) MOVF """".x+4(FP), F0 0x0008 00008 (test.go:6) SQRTD F0, F0 ``` but with `GOARCH=mips64`: ``` 0x002c 00044 (test.go:5) MOVD """".x(FP), F0 0x0030 00048 (test.go:6) MOVD F0, 8(R29) 0x0034 00052 (test.go:6) CALL math.Sqrt(SB) ```",True,"math: Sqrt not intrinsified on mips64 - ``` $ go version go version go1.10 linux/amd64 ``` ``` func f(x float64) float64 { return math.Sqrt(x) } ``` `GOARCH=mips`: ``` 0x0000 00000 (test.go:5) MOVF """".x(FP), F1 0x0004 00004 (test.go:5) MOVF """".x+4(FP), F0 0x0008 00008 (test.go:6) SQRTD F0, F0 ``` but with `GOARCH=mips64`: ``` 0x002c 00044 (test.go:5) MOVD """".x(FP), F0 0x0030 00048 (test.go:6) MOVD F0, 8(R29) 0x0034 00052 (test.go:6) CALL math.Sqrt(SB) ```",0,math sqrt not intrinsified on go version go version linux func f x return math sqrt x goarch mips test go movf x fp test go movf x fp test go sqrtd but with goarch test go movd x fp test go movd test go call math sqrt sb ,0 62355,15226318715.0,IssuesEvent,2021-02-18 08:43:28,golang/go,https://api.github.com/repos/golang/go,closed,"runtime: linux-riscv64-jsing failing with ""signal: segmentation fault"" during bootstrapping",Builders NeedsInvestigation arch-riscv,"[2021-02-17T01:29:54-2f0da6d/linux-riscv64-jsing](https://build.golang.org/log/b01082dcad47773ac8a3263387da0287f103ccf6) [2021-02-17T00:04:02-70c37ee/linux-riscv64-jsing](https://build.golang.org/log/58d939e13e25c2cf0498fb55c39fa96f503ef6cf) [2021-02-16T22:18:37-8482559/linux-riscv64-jsing](https://build.golang.org/log/c3ce06b6e076ba525d9eca538672e1a33402da4b) [2021-01-19T19:43:25-5f4716e/linux-riscv64-jsing](https://build.golang.org/log/7ff01b7de98be68ce16a5f871eb4dc4a113eb5d3) CC @4a6f656c ",1.0,"runtime: linux-riscv64-jsing failing with ""signal: segmentation fault"" during bootstrapping - [2021-02-17T01:29:54-2f0da6d/linux-riscv64-jsing](https://build.golang.org/log/b01082dcad47773ac8a3263387da0287f103ccf6) [2021-02-17T00:04:02-70c37ee/linux-riscv64-jsing](https://build.golang.org/log/58d939e13e25c2cf0498fb55c39fa96f503ef6cf) [2021-02-16T22:18:37-8482559/linux-riscv64-jsing](https://build.golang.org/log/c3ce06b6e076ba525d9eca538672e1a33402da4b) [2021-01-19T19:43:25-5f4716e/linux-riscv64-jsing](https://build.golang.org/log/7ff01b7de98be68ce16a5f871eb4dc4a113eb5d3) CC @4a6f656c ",0,runtime linux jsing failing with signal segmentation fault during bootstrapping cc ,0 6503,3025028806.0,IssuesEvent,2015-08-03 04:01:35,golang/go,https://api.github.com/repos/golang/go,closed,doc: 1.5 release notes don't mention linker's new -X pkg.name=value syntax,Documentation,"[CL 10310](https://go-review.googlesource.com/#/c/10310/) introduced the new syntax for linker's -X flag. While the old syntax is still accepted, the CL states that it may be deprecated some day. It should be added to the release notes, possibly with a recommendation to replace scripts with old syntax to the new one.",1.0,"doc: 1.5 release notes don't mention linker's new -X pkg.name=value syntax - [CL 10310](https://go-review.googlesource.com/#/c/10310/) introduced the new syntax for linker's -X flag. While the old syntax is still accepted, the CL states that it may be deprecated some day. It should be added to the release notes, possibly with a recommendation to replace scripts with old syntax to the new one.",1,doc release notes don t mention linker s new x pkg name value syntax introduced the new syntax for linker s x flag while the old syntax is still accepted the cl states that it may be deprecated some day it should be added to the release notes possibly with a recommendation to replace scripts with old syntax to the new one ,1 86504,10508518969.0,IssuesEvent,2019-09-27 08:50:32,golang/go,https://api.github.com/repos/golang/go,closed,x/tour: instructions for running Go tour offline are malformatted,Documentation NeedsFix help wanted,"There seem to be two issues with the instructions for how to run the Go tour offline [here](https://tour.golang.org/welcome/3). First, on my Fedora system, even though I have installed Go 1.10.1 from binary rpms, running `go tool tour` doesn't work (perhaps this requires installing a distinct Fedora package that is not mentioned): ``` $ go tool tour go tool: no such tool ""tour"" $ ``` The second issue is that, before trying to run these commands: ``` $ go get golang.org/x/tour/gotour $ gotour ``` the reader should be reminded to add `${GOPATH}/bin` to their search path.",1.0,"x/tour: instructions for running Go tour offline are malformatted - There seem to be two issues with the instructions for how to run the Go tour offline [here](https://tour.golang.org/welcome/3). First, on my Fedora system, even though I have installed Go 1.10.1 from binary rpms, running `go tool tour` doesn't work (perhaps this requires installing a distinct Fedora package that is not mentioned): ``` $ go tool tour go tool: no such tool ""tour"" $ ``` The second issue is that, before trying to run these commands: ``` $ go get golang.org/x/tour/gotour $ gotour ``` the reader should be reminded to add `${GOPATH}/bin` to their search path.",1,x tour instructions for running go tour offline are malformatted there seem to be two issues with the instructions for how to run the go tour offline first on my fedora system even though i have installed go from binary rpms running go tool tour doesn t work perhaps this requires installing a distinct fedora package that is not mentioned go tool tour go tool no such tool tour the second issue is that before trying to run these commands go get golang org x tour gotour gotour the reader should be reminded to add gopath bin to their search path ,1 399825,27257367447.0,IssuesEvent,2023-02-22 12:33:22,golang/go,https://api.github.com/repos/golang/go,opened,crypto: document that GenerateKey functions are not deterministic,Documentation NeedsFix,"In Go 1.20 we finally made crypto/ecdsa.GenerateKey call MaybeReadByte, so that now all GenerateKey implementation are non-deterministic, avoiding applications relying on the internals of our implementation, which would stop us from ever changing them. We should document this.",1.0,"crypto: document that GenerateKey functions are not deterministic - In Go 1.20 we finally made crypto/ecdsa.GenerateKey call MaybeReadByte, so that now all GenerateKey implementation are non-deterministic, avoiding applications relying on the internals of our implementation, which would stop us from ever changing them. We should document this.",1,crypto document that generatekey functions are not deterministic in go we finally made crypto ecdsa generatekey call maybereadbyte so that now all generatekey implementation are non deterministic avoiding applications relying on the internals of our implementation which would stop us from ever changing them we should document this ,1 25476,5168164356.0,IssuesEvent,2017-01-17 20:50:24,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go bug help message is outdated,Documentation NeedsFix,"``` $ gotip version go version devel +39e31d5ec0 Thu Jan 12 04:50:46 2017 +0000 linux/amd64 ``` Change 896ac677b5e3e80278cc1ce179d8a077ac3a6d2f modified the `bug` subcommand to make it open the system browser and pre-fill an issue template (instead of just dumping the infos to the screen), but the subcommand help string was not updated accordingly. It is certainly unexpected that a command that is currently documented like this: ``` $ gotip bug -h usage: bug Bug prints information that helps file effective bug reports. Bugs may be reported at https://golang.org/issue/new. ``` opens my browser and uses it to display a pre-filled github issue.",1.0,"cmd/go: go bug help message is outdated - ``` $ gotip version go version devel +39e31d5ec0 Thu Jan 12 04:50:46 2017 +0000 linux/amd64 ``` Change 896ac677b5e3e80278cc1ce179d8a077ac3a6d2f modified the `bug` subcommand to make it open the system browser and pre-fill an issue template (instead of just dumping the infos to the screen), but the subcommand help string was not updated accordingly. It is certainly unexpected that a command that is currently documented like this: ``` $ gotip bug -h usage: bug Bug prints information that helps file effective bug reports. Bugs may be reported at https://golang.org/issue/new. ``` opens my browser and uses it to display a pre-filled github issue.",1,cmd go go bug help message is outdated gotip version go version devel thu jan linux change modified the bug subcommand to make it open the system browser and pre fill an issue template instead of just dumping the infos to the screen but the subcommand help string was not updated accordingly it is certainly unexpected that a command that is currently documented like this gotip bug h usage bug bug prints information that helps file effective bug reports bugs may be reported at opens my browser and uses it to display a pre filled github issue ,1 70055,9370499340.0,IssuesEvent,2019-04-03 13:36:06,golang/go,https://api.github.com/repos/golang/go,reopened,"x/tools/cmd/gopls: textDocument/rangeFormatting gives error ""ToUTF16Column: point is missing offset""",Documentation gopls," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190328211700-ab21143f2384
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/home/myitcv/gostuff/src/github.com/myitcv/govim/.bin""
GOCACHE=""/home/myitcv/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/myitcv/gostuff""
GOPROXY=""""
GORACE=""""
GOROOT=""/home/myitcv/gos""
GOTMPDIR=""""
GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/myitcv/gostuff/src/github.com/myitcv/govim/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-build120717318=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Considering the following [`govim`](https://github.com/myitcv/govim/tree/master/cmd/govim) [`testscript`](https://godoc.org/github.com/rogpeppe/go-internal/testscript) in which I attempt to range-format line numbers 3-5 (inc) in `main.go`: ``` vim ex 'e main.go' vim ex '3,5GOVIMGoFmt' vim ex 'noautocmd w' cmp main.go main.go.golden -- go.mod -- module mod -- main.go -- package main func main(){ fmt.Println(""Hello, world"") } -- main.go.golden -- package main func main() { fmt.Println(""Hello, world"") } ``` I get the error: ``` ToUTF16Column: point is missing offset ``` The params sent were: ``` &protocol.DocumentRangeFormattingParams{ TextDocument: protocol.TextDocumentIdentifier{URI:""file://$WORK/main.go""}, Range: protocol.Range{ Start: protocol.Position{Line:2, Character:0}, End: protocol.Position{Line:5, Character:0}, }, Options: protocol.FormattingOptions{}, } ``` ### What did you expect to see? No error. ### What did you see instead? The above error. cc @stamblerre @ianthehat ",1.0,"x/tools/cmd/gopls: textDocument/rangeFormatting gives error ""ToUTF16Column: point is missing offset"" - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190328211700-ab21143f2384
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/home/myitcv/gostuff/src/github.com/myitcv/govim/.bin""
GOCACHE=""/home/myitcv/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/myitcv/gostuff""
GOPROXY=""""
GORACE=""""
GOROOT=""/home/myitcv/gos""
GOTMPDIR=""""
GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/myitcv/gostuff/src/github.com/myitcv/govim/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-build120717318=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Considering the following [`govim`](https://github.com/myitcv/govim/tree/master/cmd/govim) [`testscript`](https://godoc.org/github.com/rogpeppe/go-internal/testscript) in which I attempt to range-format line numbers 3-5 (inc) in `main.go`: ``` vim ex 'e main.go' vim ex '3,5GOVIMGoFmt' vim ex 'noautocmd w' cmp main.go main.go.golden -- go.mod -- module mod -- main.go -- package main func main(){ fmt.Println(""Hello, world"") } -- main.go.golden -- package main func main() { fmt.Println(""Hello, world"") } ``` I get the error: ``` ToUTF16Column: point is missing offset ``` The params sent were: ``` &protocol.DocumentRangeFormattingParams{ TextDocument: protocol.TextDocumentIdentifier{URI:""file://$WORK/main.go""}, Range: protocol.Range{ Start: protocol.Position{Line:2, Character:0}, End: protocol.Position{Line:5, Character:0}, }, Options: protocol.FormattingOptions{}, } ``` ### What did you expect to see? No error. ### What did you see instead? The above error. cc @stamblerre @ianthehat ",1,x tools cmd gopls textdocument rangeformatting gives error point is missing offset what version of go are you using go version go version go version linux go list m golang org x tools golang org x tools does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin home myitcv gostuff src github com myitcv govim bin gocache home myitcv cache go build goexe goflags gohostarch gohostos linux goos linux gopath home myitcv gostuff goproxy gorace goroot home myitcv gos gotmpdir gotooldir home myitcv gos pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod home myitcv gostuff src github com myitcv govim go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do considering the following in which i attempt to range format line numbers inc in main go vim ex e main go vim ex vim ex noautocmd w cmp main go main go golden go mod module mod main go package main func main fmt println hello world main go golden package main func main fmt println hello world i get the error point is missing offset the params sent were protocol documentrangeformattingparams textdocument protocol textdocumentidentifier uri file work main go range protocol range start protocol position line character end protocol position line character options protocol formattingoptions what did you expect to see no error what did you see instead the above error cc stamblerre ianthehat ,1 213576,16527644715.0,IssuesEvent,2021-05-26 22:45:08,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document net changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
net

TODO: https://golang.org/cl/272668: add IP.IsPrivate

TODO: https://golang.org/cl/301709: make go resolver aware of network parameter

TODO: https://golang.org/cl/307030: make ErrClosed and ParseError implement net.Error

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46014."" in the body.",1.0,"doc/go1.17: document net changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
net

TODO: https://golang.org/cl/272668: add IP.IsPrivate

TODO: https://golang.org/cl/301709: make go resolver aware of network parameter

TODO: https://golang.org/cl/307030: make ErrClosed and ParseError implement net.Error

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46014."" in the body.",1,doc document net changes for go as of filing this issue the contained the following html net todo a href add ip isprivate todo a href make go resolver aware of network parameter todo a href make errclosed and parseerror implement net error this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 370179,25892541239.0,IssuesEvent,2022-12-14 19:14:25,golang/go,https://api.github.com/repos/golang/go,closed,spec: document that recursive type declarations through type parameters are not permitted,Documentation,"Here's a type: ```go type Rec[type T Rec[T]] interface{ r(T) } ``` Currently `go2go` complains with confusing errors; the first declaration fails with `Rec is not a generic type` (it obviously is) and the equivalent `type Rec[type T Rec] interface{ r(T) }` fails with `Rec is not an interface` (it also obviously is). I assume this shouldn't be allowed: to know if `Rec[T]` is a valid type for `T` to implement, we need to know if `T` implements `Rec[T]`, which is circular. But I can't find anything in the draft design that would prohibit it. ([playground for convenience](https://go2goplay.golang.org/p/TsopGuR9oFR))",1.0,"spec: document that recursive type declarations through type parameters are not permitted - Here's a type: ```go type Rec[type T Rec[T]] interface{ r(T) } ``` Currently `go2go` complains with confusing errors; the first declaration fails with `Rec is not a generic type` (it obviously is) and the equivalent `type Rec[type T Rec] interface{ r(T) }` fails with `Rec is not an interface` (it also obviously is). I assume this shouldn't be allowed: to know if `Rec[T]` is a valid type for `T` to implement, we need to know if `T` implements `Rec[T]`, which is circular. But I can't find anything in the draft design that would prohibit it. ([playground for convenience](https://go2goplay.golang.org/p/TsopGuR9oFR))",1,spec document that recursive type declarations through type parameters are not permitted here s a type go type rec interface r t currently complains with confusing errors the first declaration fails with rec is not a generic type it obviously is and the equivalent type rec interface r t fails with rec is not an interface it also obviously is i assume this shouldn t be allowed to know if rec is a valid type for t to implement we need to know if t implements rec which is circular but i can t find anything in the draft design that would prohibit it ,1 306638,26485592522.0,IssuesEvent,2023-01-17 17:44:31,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/internal/robustio: TestFileID consistently failing on android builders with EPERM,Testing NeedsFix Tools,"``` #!watchflakes post <- builder ~ `^android-.*` && test == ""TestFileID"" ``` https://build.golang.org/log/2986bd93a11934517802df1e2b7314280acfd478: ``` --- FAIL: TestFileID (0.00s) robustio_test.go:63: link /data/local/tmp/go_android_exec/robustio.test-16829/TestFileID3286931938/002/real /data/local/tmp/go_android_exec/robustio.test-16829/TestFileID3286931938/005/hardlink: permission denied FAIL exitcode=1 FAIL golang.org/x/tools/internal/robustio 2.577s ```",1.0,"x/tools/internal/robustio: TestFileID consistently failing on android builders with EPERM - ``` #!watchflakes post <- builder ~ `^android-.*` && test == ""TestFileID"" ``` https://build.golang.org/log/2986bd93a11934517802df1e2b7314280acfd478: ``` --- FAIL: TestFileID (0.00s) robustio_test.go:63: link /data/local/tmp/go_android_exec/robustio.test-16829/TestFileID3286931938/002/real /data/local/tmp/go_android_exec/robustio.test-16829/TestFileID3286931938/005/hardlink: permission denied FAIL exitcode=1 FAIL golang.org/x/tools/internal/robustio 2.577s ```",0,x tools internal robustio testfileid consistently failing on android builders with eperm watchflakes post builder android test testfileid fail testfileid robustio test go link data local tmp go android exec robustio test real data local tmp go android exec robustio test hardlink permission denied fail exitcode fail golang org x tools internal robustio ,0 30258,5774072367.0,IssuesEvent,2017-04-28 05:29:07,golang/go,https://api.github.com/repos/golang/go,closed, syscall: fix documentation typo,Documentation HelpWanted NeedsFix,"At [https://gowalker.org/syscall#StringToUTF16Ptr](https://gowalker.org/syscall#StringToUTF16Ptr): _(...) with a terminating **NUL** #added. **If s If s** contains (...)_ * _If s_ is duplicated. * Along all the page ([https://gowalker.org/syscall](https://gowalker.org/syscall)) you can find repeatedly _NUL_ instead of _NULL_.",1.0," syscall: fix documentation typo - At [https://gowalker.org/syscall#StringToUTF16Ptr](https://gowalker.org/syscall#StringToUTF16Ptr): _(...) with a terminating **NUL** #added. **If s If s** contains (...)_ * _If s_ is duplicated. * Along all the page ([https://gowalker.org/syscall](https://gowalker.org/syscall)) you can find repeatedly _NUL_ instead of _NULL_.",1, syscall fix documentation typo at with a terminating nul added if s if s contains if s is duplicated along all the page you can find repeatedly nul instead of null ,1 71052,9477307224.0,IssuesEvent,2019-04-19 18:09:11,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go/internal/modfetch: document known bug in `isVendoredPackage`,Documentation NeedsFix Unfortunate modules,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/home/gheibi/.go/bin/""
GOCACHE=""/home/gheibi/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/gheibi/.go/""
GOPROXY=""""
GORACE=""""
GOROOT=""/local/go1.12.1.linux_amd64/go""
GOTMPDIR=""""
GOTOOLDIR=""/local/go1.12.1.linux_amd64/go                                                                                     /pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build865790926=/tmp/go-build""
### What did you do? ``` $grep -A12 ""func isVendoredPackage"" $GOROOT/src/cmd/go/internal/modfetch/coderepo.go ``` https://github.com/golang/go/blob/c8aaec2f70c5ccbca1ec2152c57d19981ac09133/src/cmd/go/internal/modfetch/coderepo.go#L632-L642 ### What did you expect to see? ``` func isVendoredPackage(name string) bool { var i int if strings.HasPrefix(name, ""vendor/"") { i += len(""vendor/"") } else if j := strings.Index(name, ""/vendor/""); j >= 0 { i += j + len(""/vendor/"") } else { return false } return strings.Contains(name[i:], ""/"") } ``` ### What did you see instead? The function is not documented, but it is obvious that it is not doing what the intention is. It seems that the intention is to match against this regex: `(^vendor/|/vendor/).*/` But in fact it does random match by skipping first 8 bytes in case the input contains `/vendor/`. The fix is to add the j to the i as states above. It is quite important to fix it early on, because it may cause go-modules with different hashes and a late fix can cause more hash mismatch of the same content (defy the immutability logic). ",1.0,"cmd/go/internal/modfetch: document known bug in `isVendoredPackage` - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/home/gheibi/.go/bin/""
GOCACHE=""/home/gheibi/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/gheibi/.go/""
GOPROXY=""""
GORACE=""""
GOROOT=""/local/go1.12.1.linux_amd64/go""
GOTMPDIR=""""
GOTOOLDIR=""/local/go1.12.1.linux_amd64/go                                                                                     /pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build865790926=/tmp/go-build""
### What did you do? ``` $grep -A12 ""func isVendoredPackage"" $GOROOT/src/cmd/go/internal/modfetch/coderepo.go ``` https://github.com/golang/go/blob/c8aaec2f70c5ccbca1ec2152c57d19981ac09133/src/cmd/go/internal/modfetch/coderepo.go#L632-L642 ### What did you expect to see? ``` func isVendoredPackage(name string) bool { var i int if strings.HasPrefix(name, ""vendor/"") { i += len(""vendor/"") } else if j := strings.Index(name, ""/vendor/""); j >= 0 { i += j + len(""/vendor/"") } else { return false } return strings.Contains(name[i:], ""/"") } ``` ### What did you see instead? The function is not documented, but it is obvious that it is not doing what the intention is. It seems that the intention is to match against this regex: `(^vendor/|/vendor/).*/` But in fact it does random match by skipping first 8 bytes in case the input contains `/vendor/`. The fix is to add the j to the i as states above. It is quite important to fix it early on, because it may cause go-modules with different hashes and a late fix can cause more hash mismatch of the same content (defy the immutability logic). ",1,cmd go internal modfetch document known bug in isvendoredpackage what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin home gheibi go bin gocache home gheibi cache go build goexe goflags gohostarch gohostos linux goos linux gopath home gheibi go goproxy gorace goroot local linux go gotmpdir gotooldir local linux go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build what did you do grep func isvendoredpackage goroot src cmd go internal modfetch coderepo go what did you expect to see func isvendoredpackage name string bool var i int if strings hasprefix name vendor i len vendor else if j strings index name vendor j i j len vendor else return false return strings contains name what did you see instead the function is not documented but it is obvious that it is not doing what the intention is it seems that the intention is to match against this regex vendor vendor but in fact it does random match by skipping first bytes in case the input contains vendor the fix is to add the j to the i as states above it is quite important to fix it early on because it may cause go modules with different hashes and a late fix can cause more hash mismatch of the same content defy the immutability logic ,1 126958,10441638872.0,IssuesEvent,2019-09-18 11:18:19,golang/go,https://api.github.com/repos/golang/go,closed,x/exp/old/netchan: data race in TestImportHangup,NeedsFix Testing help wanted,"The old netchan package has a data race in TestImportHangup which often (but not always) breaks the x/exp trybots for the linux-amd64-race builder. It repros pretty easily with: ``` bradfitz@go:~/src/golang.org/x/exp/old/netchan$ go test -v -run=TestImportHangup -race -count=5 -cpu=1,2,4 === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup ================== WARNING: DATA RACE Write at 0x00c0000621d0 by goroutine 22: runtime.closechan() /home/bradfitz/go/src/runtime/chan.go:334 +0x0 golang.org/x/exp/old/netchan.(*netChan).close() /home/bradfitz/src/golang.org/x/exp/old/netchan/common.go:246 +0x1b9 golang.org/x/exp/old/netchan.(*Importer).Hangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:261 +0x337 golang.org/x/exp/old/netchan.TestImportHangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:254 +0x2c2 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 Previous read at 0x00c0000621d0 by goroutine 24: runtime.chansend() /home/bradfitz/go/src/runtime/chan.go:142 +0x0 golang.org/x/exp/old/netchan.(*netChan).acked() /home/bradfitz/src/golang.org/x/exp/old/netchan/common.go:332 +0x99 golang.org/x/exp/old/netchan.(*Importer).run() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:123 +0x29a Goroutine 22 (running) created at: testing.(*T).Run() /home/bradfitz/go/src/testing/testing.go:916 +0x651 testing.runTests.func1() /home/bradfitz/go/src/testing/testing.go:1157 +0xa6 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 testing.runTests() /home/bradfitz/go/src/testing/testing.go:1155 +0x521 testing.(*M).Run() /home/bradfitz/go/src/testing/testing.go:1072 +0x2e9 main.main() _testmain.go:68 +0x21e Goroutine 24 (running) created at: golang.org/x/exp/old/netchan.NewImporter() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:50 +0x19a golang.org/x/exp/old/netchan.pair() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:445 +0x1f7 golang.org/x/exp/old/netchan.TestImportHangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:234 +0x50 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 ================== --- FAIL: TestImportHangup (0.00s) testing.go:809: race detected during execution of test === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) ``` What should we do: 1) delete this package? 2) delete this test? 3) fix the code? (@robpike, interested?) I gave it a few minutes but my quick attempts didn't do the trick. I don't have time to learn this package well enough to fix it properly. ",1.0,"x/exp/old/netchan: data race in TestImportHangup - The old netchan package has a data race in TestImportHangup which often (but not always) breaks the x/exp trybots for the linux-amd64-race builder. It repros pretty easily with: ``` bradfitz@go:~/src/golang.org/x/exp/old/netchan$ go test -v -run=TestImportHangup -race -count=5 -cpu=1,2,4 === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup ================== WARNING: DATA RACE Write at 0x00c0000621d0 by goroutine 22: runtime.closechan() /home/bradfitz/go/src/runtime/chan.go:334 +0x0 golang.org/x/exp/old/netchan.(*netChan).close() /home/bradfitz/src/golang.org/x/exp/old/netchan/common.go:246 +0x1b9 golang.org/x/exp/old/netchan.(*Importer).Hangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:261 +0x337 golang.org/x/exp/old/netchan.TestImportHangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:254 +0x2c2 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 Previous read at 0x00c0000621d0 by goroutine 24: runtime.chansend() /home/bradfitz/go/src/runtime/chan.go:142 +0x0 golang.org/x/exp/old/netchan.(*netChan).acked() /home/bradfitz/src/golang.org/x/exp/old/netchan/common.go:332 +0x99 golang.org/x/exp/old/netchan.(*Importer).run() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:123 +0x29a Goroutine 22 (running) created at: testing.(*T).Run() /home/bradfitz/go/src/testing/testing.go:916 +0x651 testing.runTests.func1() /home/bradfitz/go/src/testing/testing.go:1157 +0xa6 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 testing.runTests() /home/bradfitz/go/src/testing/testing.go:1155 +0x521 testing.(*M).Run() /home/bradfitz/go/src/testing/testing.go:1072 +0x2e9 main.main() _testmain.go:68 +0x21e Goroutine 24 (running) created at: golang.org/x/exp/old/netchan.NewImporter() /home/bradfitz/src/golang.org/x/exp/old/netchan/import.go:50 +0x19a golang.org/x/exp/old/netchan.pair() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:445 +0x1f7 golang.org/x/exp/old/netchan.TestImportHangup() /home/bradfitz/src/golang.org/x/exp/old/netchan/netchan_test.go:234 +0x50 testing.tRunner() /home/bradfitz/go/src/testing/testing.go:865 +0x162 ================== --- FAIL: TestImportHangup (0.00s) testing.go:809: race detected during execution of test === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) === RUN TestImportHangup --- PASS: TestImportHangup (0.00s) ``` What should we do: 1) delete this package? 2) delete this test? 3) fix the code? (@robpike, interested?) I gave it a few minutes but my quick attempts didn't do the trick. I don't have time to learn this package well enough to fix it properly. ",0,x exp old netchan data race in testimporthangup the old netchan package has a data race in testimporthangup which often but not always breaks the x exp trybots for the linux race builder it repros pretty easily with bradfitz go src golang org x exp old netchan go test v run testimporthangup race count cpu run testimporthangup pass testimporthangup run testimporthangup pass testimporthangup run testimporthangup pass testimporthangup run testimporthangup warning data race write at by goroutine runtime closechan home bradfitz go src runtime chan go golang org x exp old netchan netchan close home bradfitz src golang org x exp old netchan common go golang org x exp old netchan importer hangup home bradfitz src golang org x exp old netchan import go golang org x exp old netchan testimporthangup home bradfitz src golang org x exp old netchan netchan test go testing trunner home bradfitz go src testing testing go previous read at by goroutine runtime chansend home bradfitz go src runtime chan go golang org x exp old netchan netchan acked home bradfitz src golang org x exp old netchan common go golang org x exp old netchan importer run home bradfitz src golang org x exp old netchan import go goroutine running created at testing t run home bradfitz go src testing testing go testing runtests home bradfitz go src testing testing go testing trunner home bradfitz go src testing testing go testing runtests home bradfitz go src testing testing go testing m run home bradfitz go src testing testing go main main testmain go goroutine running created at golang org x exp old netchan newimporter home bradfitz src golang org x exp old netchan import go golang org x exp old netchan pair home bradfitz src golang org x exp old netchan netchan test go golang org x exp old netchan testimporthangup home bradfitz src golang org x exp old netchan netchan test go testing trunner home bradfitz go src testing testing go fail testimporthangup testing go race detected during execution of test run testimporthangup pass testimporthangup run testimporthangup pass testimporthangup run testimporthangup pass testimporthangup run testimporthangup pass testimporthangup what should we do delete this package delete this test fix the code robpike interested i gave it a few minutes but my quick attempts didn t do the trick i don t have time to learn this package well enough to fix it properly ,0 11047,3454733006.0,IssuesEvent,2015-12-17 17:03:23,golang/go,https://api.github.com/repos/golang/go,closed,"net/http: ServeMux also eliminates repeating ""/""",Documentation,"Just a documentation issue that - `http.ServeMux` (cleanPath) gets also rid of duplicate `/`-s. `http.ServeMux` already contains: > ServeMux also takes care of sanitizing the URL request path, redirecting any request containing . or .. elements to an equivalent .- and ..-free URL. I'm not sure how to reword it nicely to include the case of empty path segments, hence I didn't make a CL. Here's shortest example: ``` package main import (""fmt""; ""net/http"") func main() { http.HandleFunc(""/"", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, ""%s"", r.URL.Path) }) http.ListenAndServe("":8001"", nil) } ``` `/hello////world` will redirect to `/hello/world`. From URI standpoint they are different and both valid (https://tools.ietf.org/html/rfc3986#section-3.3).",1.0,"net/http: ServeMux also eliminates repeating ""/"" - Just a documentation issue that - `http.ServeMux` (cleanPath) gets also rid of duplicate `/`-s. `http.ServeMux` already contains: > ServeMux also takes care of sanitizing the URL request path, redirecting any request containing . or .. elements to an equivalent .- and ..-free URL. I'm not sure how to reword it nicely to include the case of empty path segments, hence I didn't make a CL. Here's shortest example: ``` package main import (""fmt""; ""net/http"") func main() { http.HandleFunc(""/"", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, ""%s"", r.URL.Path) }) http.ListenAndServe("":8001"", nil) } ``` `/hello////world` will redirect to `/hello/world`. From URI standpoint they are different and both valid (https://tools.ietf.org/html/rfc3986#section-3.3).",1,net http servemux also eliminates repeating just a documentation issue that http servemux cleanpath gets also rid of duplicate s http servemux already contains servemux also takes care of sanitizing the url request path redirecting any request containing or elements to an equivalent and free url i m not sure how to reword it nicely to include the case of empty path segments hence i didn t make a cl here s shortest example package main import fmt net http func main http handlefunc func w http responsewriter r http request fmt fprintf w s r url path http listenandserve nil hello world will redirect to hello world from uri standpoint they are different and both valid ,1 50010,7550638635.0,IssuesEvent,2018-04-18 17:32:43,golang/go,https://api.github.com/repos/golang/go,closed,reflect: documentation on NumMethod is incorrect,Documentation,"[Consider the following](https://play.golang.org/p/rsC-F8IYO8w): ```go type iface interface { private() Public() } t := reflect.TypeOf((*iface)(nil)).Elem() for i := 0; i < t.NumMethod(); i++ { fmt.Println(t.Method(i)) } ``` This currently prints: ``` {Public func() 0} {private main func() 1} ``` The documented behavior of `reflect.Type.NumMethod` is: > NumMethod returns the number of **exported** methods in the value's method set. However, you can clearly see that `private` is included as part of the count. It seems to me that for `reflect.Interface`, the `NumMethod` does include unexported methods, while it excludes them for all other kinds.",1.0,"reflect: documentation on NumMethod is incorrect - [Consider the following](https://play.golang.org/p/rsC-F8IYO8w): ```go type iface interface { private() Public() } t := reflect.TypeOf((*iface)(nil)).Elem() for i := 0; i < t.NumMethod(); i++ { fmt.Println(t.Method(i)) } ``` This currently prints: ``` {Public func() 0} {private main func() 1} ``` The documented behavior of `reflect.Type.NumMethod` is: > NumMethod returns the number of **exported** methods in the value's method set. However, you can clearly see that `private` is included as part of the count. It seems to me that for `reflect.Interface`, the `NumMethod` does include unexported methods, while it excludes them for all other kinds.",1,reflect documentation on nummethod is incorrect go type iface interface private public t reflect typeof iface nil elem for i i t nummethod i fmt println t method i this currently prints public func private main func the documented behavior of reflect type nummethod is nummethod returns the number of exported methods in the value s method set however you can clearly see that private is included as part of the count it seems to me that for reflect interface the nummethod does include unexported methods while it excludes them for all other kinds ,1 28771,5536566526.0,IssuesEvent,2017-03-21 19:57:55,golang/go,https://api.github.com/repos/golang/go,closed,"doc: figure out, document amd64 minimum requirements",Documentation NeedsDecision,"In https://golang.org/cl/38320, @khr adds POPCOUNT intrinsics for amd64. I realize that our https://golang.org/wiki/MinimumRequirements doesn't say anything about GOARCH=amd64. (only 386) Which version of amd64 do we assume? Decide and document. /cc @randall77 @ianlancetaylor @griesemer @rsc @mdempsky @josharian @minux @cherrymui @aclements ",1.0,"doc: figure out, document amd64 minimum requirements - In https://golang.org/cl/38320, @khr adds POPCOUNT intrinsics for amd64. I realize that our https://golang.org/wiki/MinimumRequirements doesn't say anything about GOARCH=amd64. (only 386) Which version of amd64 do we assume? Decide and document. /cc @randall77 @ianlancetaylor @griesemer @rsc @mdempsky @josharian @minux @cherrymui @aclements ",1,doc figure out document minimum requirements in khr adds popcount intrinsics for i realize that our doesn t say anything about goarch only which version of do we assume decide and document cc ianlancetaylor griesemer rsc mdempsky josharian minux cherrymui aclements ,1 3809,4054773325.0,IssuesEvent,2016-05-24 13:34:49,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: t*10 seems slower than t<<3+t+t,Performance,"
The code generated by 6g for multiplication with a constant (t*10) appears to run slower
then a "manual" multiplication (t<<3+t+t). Specifically, for math/big,
revision 78944b6b971c, changing line nat.go:869 from:

s[i] = charset[r-t*10]

to:

s[i] = charset[r-t<<3-t-t]

leads to a significant (> 10%) performance improvement for some code:

gotest -bench=String1000*Base10

benchmark                          old ns/op    new ns/op    delta
big.BenchmarkString100Base10            1909         1855   -2.83%
big.BenchmarkString1000Base10          12867        12243   -4.85%
big.BenchmarkString10000Base10         65974        58307  -11.62%
big.BenchmarkString100000Base10     19938530     19831100   -0.54%

The compiler should be able to do the right thing here w/o manual intervention.
",True,"cmd/compile: t*10 seems slower than t<<3+t+t - 
The code generated by 6g for multiplication with a constant (t*10) appears to run slower
then a "manual" multiplication (t<<3+t+t). Specifically, for math/big,
revision 78944b6b971c, changing line nat.go:869 from:

s[i] = charset[r-t*10]

to:

s[i] = charset[r-t<<3-t-t]

leads to a significant (> 10%) performance improvement for some code:

gotest -bench=String1000*Base10

benchmark                          old ns/op    new ns/op    delta
big.BenchmarkString100Base10            1909         1855   -2.83%
big.BenchmarkString1000Base10          12867        12243   -4.85%
big.BenchmarkString10000Base10         65974        58307  -11.62%
big.BenchmarkString100000Base10     19938530     19831100   -0.54%

The compiler should be able to do the right thing here w/o manual intervention.
",0,cmd compile t seems slower than t the code generated by for multiplication with a constant t appears to run slower then a quot manual quot multiplication t lt lt t t specifically for math big revision changing line nat go from s charset to s charset leads to a significant gt performance improvement for some code gotest bench benchmark old ns op new ns op delta big big big big the compiler should be able to do the right thing here w o manual intervention ,0 174087,14446294178.0,IssuesEvent,2020-12-08 00:55:14,golang/go,https://api.github.com/repos/golang/go,closed,"You can only export basic function signatures. @ianlancetaylor, are the rules documented somewhere?",Documentation,"You can only export basic function signatures. @ianlancetaylor, are the rules documented somewhere? _Originally posted by @bradfitz in https://github.com/golang/go/issues/18412#issuecomment-268796091_ FUCK THAT SHIT, GOOGLE CODERS ARE MONKEYS",1.0,"You can only export basic function signatures. @ianlancetaylor, are the rules documented somewhere? - You can only export basic function signatures. @ianlancetaylor, are the rules documented somewhere? _Originally posted by @bradfitz in https://github.com/golang/go/issues/18412#issuecomment-268796091_ FUCK THAT SHIT, GOOGLE CODERS ARE MONKEYS",1,you can only export basic function signatures ianlancetaylor are the rules documented somewhere you can only export basic function signatures ianlancetaylor are the rules documented somewhere originally posted by bradfitz in fuck that shit google coders are monkeys,1 215794,16617611379.0,IssuesEvent,2021-06-02 18:53:37,golang/go,https://api.github.com/repos/golang/go,closed,io/fs: documentation of func Sub,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/harald/.cache/go-build""
GOENV=""/home/harald/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/harald/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/harald/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/golang/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/golang/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16""
GCCGO=""/usr/bin/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-build2438140086=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read the documentation of the func Sub in package io/fs. https://golang.org/pkg/io/fs/#Sub ### What did you expect to see? See below ### What did you see instead? There is a small bug in the description of what func Sub does. In > Otherwise, Sub returns a new FS implementation sub that, in effect, implements sub.Open(dir) as fsys.Open(path.Join(dir, name)). I think it should read ""sub.Open(name)"" instead of ""sub.Open(dir)"".",1.0,"io/fs: documentation of func Sub - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/harald/.cache/go-build""
GOENV=""/home/harald/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/harald/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/harald/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/golang/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/golang/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16""
GCCGO=""/usr/bin/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-build2438140086=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Read the documentation of the func Sub in package io/fs. https://golang.org/pkg/io/fs/#Sub ### What did you expect to see? See below ### What did you see instead? There is a small bug in the description of what func Sub does. In > Otherwise, Sub returns a new FS implementation sub that, in effect, implements sub.Open(dir) as fsys.Open(path.Join(dir, name)). I think it should read ""sub.Open(name)"" instead of ""sub.Open(dir)"".",1,io fs documentation of func sub please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home harald cache go build goenv home harald config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home harald go pkg mod gonoproxy gonosumdb goos linux gopath home harald go goprivate goproxy goroot opt golang go gosumdb sum golang org gotmpdir gotooldir opt golang go pkg tool linux govcs goversion gccgo usr bin gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 read the documentation of the func sub in package io fs what did you expect to see see below what did you see instead there is a small bug in the description of what func sub does in otherwise sub returns a new fs implementation sub that in effect implements sub open dir as fsys open path join dir name i think it should read sub open name instead of sub open dir ,1 12929,8751413009.0,IssuesEvent,2018-12-13 22:15:10,golang/go,https://api.github.com/repos/golang/go,opened,"cmd/go: remote command execution during ""go get -u""",Security,"`go get -u` downloads, updates, and builds source code. It is not supposed to execute arbitrary code. The `go get` command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it’s possible to arrange things so that a Git repository is cloned to a folder named `.git` by using a vanity import path that ends with `/.git`. If the Git repository root contains a `HEAD` file, a `config` file, an `objects` directory, a `refs` directory, with some work to ensure the proper ordering of operations, `go get -u` can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the `config` file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running `go get -u`. Thanks to Etienne Stalmans from the Heroku platform security team for discovering and reporting this issue. This issue is CVE-2018-16873. Fixed in Go 1.11.3 by a commit to be specified later. Fixed in Go 1.10.6 by a commit to be specified later.",True,"cmd/go: remote command execution during ""go get -u"" - `go get -u` downloads, updates, and builds source code. It is not supposed to execute arbitrary code. The `go get` command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it’s possible to arrange things so that a Git repository is cloned to a folder named `.git` by using a vanity import path that ends with `/.git`. If the Git repository root contains a `HEAD` file, a `config` file, an `objects` directory, a `refs` directory, with some work to ensure the proper ordering of operations, `go get -u` can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the `config` file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running `go get -u`. Thanks to Etienne Stalmans from the Heroku platform security team for discovering and reporting this issue. This issue is CVE-2018-16873. Fixed in Go 1.11.3 by a commit to be specified later. Fixed in Go 1.10.6 by a commit to be specified later.",0,cmd go remote command execution during go get u go get u downloads updates and builds source code it is not supposed to execute arbitrary code the go get command is vulnerable to remote code execution when executed with the u flag and the import path of a malicious go package or a package that imports it directly or indirectly specifically it is only vulnerable in gopath mode but not in module mode the distinction is documented at using custom domains it’s possible to arrange things so that a git repository is cloned to a folder named git by using a vanity import path that ends with git if the git repository root contains a head file a config file an objects directory a refs directory with some work to ensure the proper ordering of operations go get u can be tricked into considering the parent directory as a repository root and running git commands on it that will use the config file in the original git repository root for its configuration and if that config file contains malicious commands they will execute on the system running go get u thanks to etienne stalmans from the heroku platform security team for discovering and reporting this issue this issue is cve fixed in go by a commit to be specified later fixed in go by a commit to be specified later ,0 19906,4461572190.0,IssuesEvent,2016-08-24 06:24:49,golang/go,https://api.github.com/repos/golang/go,closed,errors: example_test doesn't use errors package,Documentation,"The example in the errors package doesn't import or use the errors package. The example illustrates how to implement the error interface but doesn't illustrate any feature of the errors package. If it's agreed the example isn't illustrative I'll attempt to claim the issue. ",1.0,"errors: example_test doesn't use errors package - The example in the errors package doesn't import or use the errors package. The example illustrates how to implement the error interface but doesn't illustrate any feature of the errors package. If it's agreed the example isn't illustrative I'll attempt to claim the issue. ",1,errors example test doesn t use errors package the example in the errors package doesn t import or use the errors package the example illustrates how to implement the error interface but doesn t illustrate any feature of the errors package if it s agreed the example isn t illustrative i ll attempt to claim the issue ,1 40866,10586622240.0,IssuesEvent,2019-10-08 20:08:56,golang/go,https://api.github.com/repos/golang/go,closed,"x/build, cmd/go: TestGoGetInsecure failing in release-branch.go1.12",Builders CherryPickApproved Testing release-blocker,"`TestGoGetInsecure` in `cmd/go` is currently failing in the `linux-amd64-longtest` builder on `release-branch.go1.12` (https://build.golang.org/log/01102088d2b8610a921c538f1beb335acb222c51): ``` --- FAIL: TestGoGetInsecure (14.49s) --- FAIL: TestGoGetInsecure/modules (4.12s) go_test.go:3650: running testgo [get -d insecure.go-get-issue-15410.appspot.com/pkg/p] go_test.go:3650: standard error: go_test.go:3650: go get insecure.go-get-issue-15410.appspot.com/pkg/p: unexpected status (http://10.240.0.55:30157/insecure.go-get-issue-15410.appspot.com/pkg/p/@v/list): 410 Gone go_test.go:3650: testgo failed as expected: exit status 1 go_test.go:3653: running testgo [get -d -insecure insecure.go-get-issue-15410.appspot.com/pkg/p] go_test.go:3653: standard error: go_test.go:3653: go get insecure.go-get-issue-15410.appspot.com/pkg/p: unexpected status (http://10.240.0.55:30157/insecure.go-get-issue-15410.appspot.com/pkg/p/@v/list): 410 Gone go_test.go:3653: go [get -d -insecure insecure.go-get-issue-15410.appspot.com/pkg/p] failed unexpectedly in /workdir/tmp/gotest754988467: exit status 1 panic.go:406: ended in /workdir/tmp/gotest754988467 ``` The failure seems to have something to do with a local proxy running on the builder, possibly from #31770 or #14594. Probably we just need to backport https://golang.org/cl/165745 and https://golang.org/cl/167086 to clear `GOPROXY` for the test (#30571).",1.0,"x/build, cmd/go: TestGoGetInsecure failing in release-branch.go1.12 - `TestGoGetInsecure` in `cmd/go` is currently failing in the `linux-amd64-longtest` builder on `release-branch.go1.12` (https://build.golang.org/log/01102088d2b8610a921c538f1beb335acb222c51): ``` --- FAIL: TestGoGetInsecure (14.49s) --- FAIL: TestGoGetInsecure/modules (4.12s) go_test.go:3650: running testgo [get -d insecure.go-get-issue-15410.appspot.com/pkg/p] go_test.go:3650: standard error: go_test.go:3650: go get insecure.go-get-issue-15410.appspot.com/pkg/p: unexpected status (http://10.240.0.55:30157/insecure.go-get-issue-15410.appspot.com/pkg/p/@v/list): 410 Gone go_test.go:3650: testgo failed as expected: exit status 1 go_test.go:3653: running testgo [get -d -insecure insecure.go-get-issue-15410.appspot.com/pkg/p] go_test.go:3653: standard error: go_test.go:3653: go get insecure.go-get-issue-15410.appspot.com/pkg/p: unexpected status (http://10.240.0.55:30157/insecure.go-get-issue-15410.appspot.com/pkg/p/@v/list): 410 Gone go_test.go:3653: go [get -d -insecure insecure.go-get-issue-15410.appspot.com/pkg/p] failed unexpectedly in /workdir/tmp/gotest754988467: exit status 1 panic.go:406: ended in /workdir/tmp/gotest754988467 ``` The failure seems to have something to do with a local proxy running on the builder, possibly from #31770 or #14594. Probably we just need to backport https://golang.org/cl/165745 and https://golang.org/cl/167086 to clear `GOPROXY` for the test (#30571).",0,x build cmd go testgogetinsecure failing in release branch testgogetinsecure in cmd go is currently failing in the linux longtest builder on release branch fail testgogetinsecure fail testgogetinsecure modules go test go running testgo go test go standard error go test go go get insecure go get issue appspot com pkg p unexpected status gone go test go testgo failed as expected exit status go test go running testgo go test go standard error go test go go get insecure go get issue appspot com pkg p unexpected status gone go test go go failed unexpectedly in workdir tmp exit status panic go ended in workdir tmp the failure seems to have something to do with a local proxy running on the builder possibly from or probably we just need to backport and to clear goproxy for the test ,0 54813,13453801575.0,IssuesEvent,2020-09-09 02:00:09,golang/go,https://api.github.com/repos/golang/go,closed,x/build: 2 darwin builders are missing,Builders NeedsInvestigation,"From https://farmer.golang.org/#health: ``` # ""macs"" status: MacStadium Mac VMs # Notes: https://github.com/golang/build/tree/master/env/darwin/macstadium Warn: macstadium_host08a missing, not seen for 55h42m8s Warn: macstadium_host08b missing, not seen for 55h42m6s Warn: 2 machines missing, 10% of capacity Warn: makemac daemon: vm.destroy(""mac_10_12_host08a"") = govc vm.destroy ...: exit status 1, govc: Unable to communicate with the remote host, since it is disconnected. Warn: makemac daemon: vm.destroy(""mac_10_12_host08b"") = govc vm.destroy ...: exit status 1, govc: Unable to communicate with the remote host, since it is disconnected. ``` The machine hosting `macstadium_host08a` and `macstadium_host08b` is being unresponsive. I've taken some initial steps to bring it back up, but this might need more work. I'll resume tomorrow. /cc @toothrot @andybons",1.0,"x/build: 2 darwin builders are missing - From https://farmer.golang.org/#health: ``` # ""macs"" status: MacStadium Mac VMs # Notes: https://github.com/golang/build/tree/master/env/darwin/macstadium Warn: macstadium_host08a missing, not seen for 55h42m8s Warn: macstadium_host08b missing, not seen for 55h42m6s Warn: 2 machines missing, 10% of capacity Warn: makemac daemon: vm.destroy(""mac_10_12_host08a"") = govc vm.destroy ...: exit status 1, govc: Unable to communicate with the remote host, since it is disconnected. Warn: makemac daemon: vm.destroy(""mac_10_12_host08b"") = govc vm.destroy ...: exit status 1, govc: Unable to communicate with the remote host, since it is disconnected. ``` The machine hosting `macstadium_host08a` and `macstadium_host08b` is being unresponsive. I've taken some initial steps to bring it back up, but this might need more work. I'll resume tomorrow. /cc @toothrot @andybons",0,x build darwin builders are missing from macs status macstadium mac vms notes warn macstadium missing not seen for warn macstadium missing not seen for warn machines missing of capacity warn makemac daemon vm destroy mac govc vm destroy exit status govc unable to communicate with the remote host since it is disconnected warn makemac daemon vm destroy mac govc vm destroy exit status govc unable to communicate with the remote host since it is disconnected the machine hosting macstadium and macstadium is being unresponsive i ve taken some initial steps to bring it back up but this might need more work i ll resume tomorrow cc toothrot andybons,0 2782,3009373641.0,IssuesEvent,2015-07-28 05:36:07,golang/go,https://api.github.com/repos/golang/go,closed,x/build: reverse roundtripper hang,Builders,"linux-arm reverse builders all hung. Stacks like: (Note that it's in doHeaderTimeout so it's trying to do timeouts, but then I think the custom reverse RoundTripper blocks forever via *body.Close) ``` goroutine 7484955 [IO wait, 12686 minutes]: net.runtime_pollWait(0x7fb6d49e9c00, 0x72, 0xc82000a150) /home/bradfitz/go/src/runtime/netpoll.go:157 +0x60 net.(*pollDesc).Wait(0xc83d468f40, 0x72, 0x0, 0x0) /home/bradfitz/go/src/net/fd_poll_runtime.go:73 +0x3a net.(*pollDesc).WaitRead(0xc83d468f40, 0x0, 0x0) /home/bradfitz/go/src/net/fd_poll_runtime.go:78 +0x36 net.(*netFD).Read(0xc83d468ee0, 0xc842a80000, 0x2000, 0x2000, 0x0, 0x7fb6d998c050, 0xc82000a150) /home/bradfitz/go/src/net/fd_unix.go:232 +0x23a net.(*conn).Read(0xc83494b180, 0xc842a80000, 0x2000, 0x2000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/net.go:124 +0xe4 crypto/tls.(*block).readFromUntil(0xc8357a5560, 0x7fb6d6b570e8, 0xc83494b180, 0x5, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:455 +0xcc crypto/tls.(*Conn).readRecord(0xc82f821b80, 0xaead17, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:540 +0x2d1 crypto/tls.(*Conn).Read(0xc82f821b80, 0xc82658f000, 0x1000, 0x1000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:901 +0x167 net/http.(*liveSwitchReader).Read(0xc840516258, 0xc82658f000, 0x1000, 0x1000, 0xd, 0x0, 0x0) /home/bradfitz/go/src/net/http/server.go:219 +0xa4 io.(*LimitedReader).Read(0xc820c25000, 0xc82658f000, 0x1000, 0x1000, 0xd, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:427 +0xbd bufio.(*Reader).fill(0xc82ae30d20) /home/bradfitz/go/src/bufio/bufio.go:97 +0x1e9 bufio.(*Reader).ReadSlice(0xc82ae30d20, 0xa, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/bufio/bufio.go:328 +0x21a net/http/internal.readLine(0xc82ae30d20, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/http/internal/chunked.go:110 +0x4b net/http/internal.(*chunkedReader).beginChunk(0xc832efe990) /home/bradfitz/go/src/net/http/internal/chunked.go:47 +0x39 net/http/internal.(*chunkedReader).Read(0xc832efe990, 0xc8332c6000, 0x2000, 0x2000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/http/internal/chunked.go:77 +0xb7 net/http.(*body).readLocked(0xc839cdbc40, 0xc8332c6000, 0x2000, 0x2000, 0x8, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:625 +0x98 net/http.bodyLocked.Read(0xc839cdbc40, 0xc8332c6000, 0x2000, 0x2000, 0x8, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:790 +0x89 io/ioutil.devNull.ReadFrom(0x0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0x659, 0x0, 0x0) /home/bradfitz/go/src/io/ioutil/ioutil.go:151 +0x9e io/ioutil.(*devNull).ReadFrom(0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0xc8329ffe10, 0x0, 0x0) :9 +0xb1 io.copyBuffer(0x7fb6d99901c0, 0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:375 +0x180 io.Copy(0x7fb6d99901c0, 0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0xc841924900, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:351 +0x64 net/http.(*body).Close(0xc839cdbc40, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:768 +0x2d7 main.(*reverseLockedBody).Close(0xc838410740, 0x0, 0x0) /home/bradfitz/src/golang.org/x/build/cmd/coordinator/reverse.go:502 +0x4a golang.org/x/build/buildlet.(*Client).doHeaderTimeout.func2() /home/bradfitz/src/golang.org/x/build/buildlet/buildletclient.go:259 +0x92 created by golang.org/x/build/buildlet.(*Client).doHeaderTimeout /home/bradfitz/src/golang.org/x/build/buildlet/buildletclient.go:267 +0x275 ```",1.0,"x/build: reverse roundtripper hang - linux-arm reverse builders all hung. Stacks like: (Note that it's in doHeaderTimeout so it's trying to do timeouts, but then I think the custom reverse RoundTripper blocks forever via *body.Close) ``` goroutine 7484955 [IO wait, 12686 minutes]: net.runtime_pollWait(0x7fb6d49e9c00, 0x72, 0xc82000a150) /home/bradfitz/go/src/runtime/netpoll.go:157 +0x60 net.(*pollDesc).Wait(0xc83d468f40, 0x72, 0x0, 0x0) /home/bradfitz/go/src/net/fd_poll_runtime.go:73 +0x3a net.(*pollDesc).WaitRead(0xc83d468f40, 0x0, 0x0) /home/bradfitz/go/src/net/fd_poll_runtime.go:78 +0x36 net.(*netFD).Read(0xc83d468ee0, 0xc842a80000, 0x2000, 0x2000, 0x0, 0x7fb6d998c050, 0xc82000a150) /home/bradfitz/go/src/net/fd_unix.go:232 +0x23a net.(*conn).Read(0xc83494b180, 0xc842a80000, 0x2000, 0x2000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/net.go:124 +0xe4 crypto/tls.(*block).readFromUntil(0xc8357a5560, 0x7fb6d6b570e8, 0xc83494b180, 0x5, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:455 +0xcc crypto/tls.(*Conn).readRecord(0xc82f821b80, 0xaead17, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:540 +0x2d1 crypto/tls.(*Conn).Read(0xc82f821b80, 0xc82658f000, 0x1000, 0x1000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/crypto/tls/conn.go:901 +0x167 net/http.(*liveSwitchReader).Read(0xc840516258, 0xc82658f000, 0x1000, 0x1000, 0xd, 0x0, 0x0) /home/bradfitz/go/src/net/http/server.go:219 +0xa4 io.(*LimitedReader).Read(0xc820c25000, 0xc82658f000, 0x1000, 0x1000, 0xd, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:427 +0xbd bufio.(*Reader).fill(0xc82ae30d20) /home/bradfitz/go/src/bufio/bufio.go:97 +0x1e9 bufio.(*Reader).ReadSlice(0xc82ae30d20, 0xa, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/bufio/bufio.go:328 +0x21a net/http/internal.readLine(0xc82ae30d20, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/http/internal/chunked.go:110 +0x4b net/http/internal.(*chunkedReader).beginChunk(0xc832efe990) /home/bradfitz/go/src/net/http/internal/chunked.go:47 +0x39 net/http/internal.(*chunkedReader).Read(0xc832efe990, 0xc8332c6000, 0x2000, 0x2000, 0x0, 0x0, 0x0) /home/bradfitz/go/src/net/http/internal/chunked.go:77 +0xb7 net/http.(*body).readLocked(0xc839cdbc40, 0xc8332c6000, 0x2000, 0x2000, 0x8, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:625 +0x98 net/http.bodyLocked.Read(0xc839cdbc40, 0xc8332c6000, 0x2000, 0x2000, 0x8, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:790 +0x89 io/ioutil.devNull.ReadFrom(0x0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0x659, 0x0, 0x0) /home/bradfitz/go/src/io/ioutil/ioutil.go:151 +0x9e io/ioutil.(*devNull).ReadFrom(0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0xc8329ffe10, 0x0, 0x0) :9 +0xb1 io.copyBuffer(0x7fb6d99901c0, 0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:375 +0x180 io.Copy(0x7fb6d99901c0, 0xc82000a2c0, 0x7fb6d99ae3f0, 0xc839cdbc40, 0xc841924900, 0x0, 0x0) /home/bradfitz/go/src/io/io.go:351 +0x64 net/http.(*body).Close(0xc839cdbc40, 0x0, 0x0) /home/bradfitz/go/src/net/http/transfer.go:768 +0x2d7 main.(*reverseLockedBody).Close(0xc838410740, 0x0, 0x0) /home/bradfitz/src/golang.org/x/build/cmd/coordinator/reverse.go:502 +0x4a golang.org/x/build/buildlet.(*Client).doHeaderTimeout.func2() /home/bradfitz/src/golang.org/x/build/buildlet/buildletclient.go:259 +0x92 created by golang.org/x/build/buildlet.(*Client).doHeaderTimeout /home/bradfitz/src/golang.org/x/build/buildlet/buildletclient.go:267 +0x275 ```",0,x build reverse roundtripper hang linux arm reverse builders all hung stacks like note that it s in doheadertimeout so it s trying to do timeouts but then i think the custom reverse roundtripper blocks forever via body close goroutine net runtime pollwait home bradfitz go src runtime netpoll go net polldesc wait home bradfitz go src net fd poll runtime go net polldesc waitread home bradfitz go src net fd poll runtime go net netfd read home bradfitz go src net fd unix go net conn read home bradfitz go src net net go crypto tls block readfromuntil home bradfitz go src crypto tls conn go crypto tls conn readrecord home bradfitz go src crypto tls conn go crypto tls conn read home bradfitz go src crypto tls conn go net http liveswitchreader read home bradfitz go src net http server go io limitedreader read home bradfitz go src io io go bufio reader fill home bradfitz go src bufio bufio go bufio reader readslice home bradfitz go src bufio bufio go net http internal readline home bradfitz go src net http internal chunked go net http internal chunkedreader beginchunk home bradfitz go src net http internal chunked go net http internal chunkedreader read home bradfitz go src net http internal chunked go net http body readlocked home bradfitz go src net http transfer go net http bodylocked read home bradfitz go src net http transfer go io ioutil devnull readfrom home bradfitz go src io ioutil ioutil go io ioutil devnull readfrom io copybuffer home bradfitz go src io io go io copy home bradfitz go src io io go net http body close home bradfitz go src net http transfer go main reverselockedbody close home bradfitz src golang org x build cmd coordinator reverse go golang org x build buildlet client doheadertimeout home bradfitz src golang org x build buildlet buildletclient go created by golang org x build buildlet client doheadertimeout home bradfitz src golang org x build buildlet buildletclient go ,0 100610,11200291038.0,IssuesEvent,2020-01-03 21:17:55,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go module fetching gives unexpected stderr output,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.5 windows/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\username\AppData\Local\go-build
set GOENV=C:\Users\username\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\username\dev
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=C:\Users\username\Dev\src\path\to\repo\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\username\AppData\Local\Temp\go-build955724962=/tmp/go-build -gno-record-gcc-switches
### What did you do? `go mod download` ### What did you expect to see? As per the documentation of the command, >By default, download reports errors to standard error but is otherwise silent. I expected no output on success. ### What did you see instead? A line to stderr for each module as it is cached: >go: finding golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b ### Discussion This appears to come from here: https://github.com/golang/go/blob/dcd3b2c173b77d93be1c391e3b5f932e0779fb1f/src/cmd/go/internal/modfetch/cache.go#L171 This is an issue since many many CI tools will fail the build on output to stderr. We could redirect to stdout, but then *actual* errors might be missed (although that probably triggers a fail based on exit code). The smallest possible fix would be to update the documentation so that it mentions that caching will also write to stderr, but a ""better"" fix from my point of view would be to either move the caching logs to stdout, and/or hide them completely unless a verbose flag is passed?",1.0,"cmd/go: go module fetching gives unexpected stderr output - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.5 windows/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\username\AppData\Local\go-build
set GOENV=C:\Users\username\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\username\dev
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=C:\Users\username\Dev\src\path\to\repo\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\username\AppData\Local\Temp\go-build955724962=/tmp/go-build -gno-record-gcc-switches
### What did you do? `go mod download` ### What did you expect to see? As per the documentation of the command, >By default, download reports errors to standard error but is otherwise silent. I expected no output on success. ### What did you see instead? A line to stderr for each module as it is cached: >go: finding golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b ### Discussion This appears to come from here: https://github.com/golang/go/blob/dcd3b2c173b77d93be1c391e3b5f932e0779fb1f/src/cmd/go/internal/modfetch/cache.go#L171 This is an issue since many many CI tools will fail the build on output to stderr. We could redirect to stdout, but then *actual* errors might be missed (although that probably triggers a fail based on exit code). The smallest possible fix would be to update the documentation so that it mentions that caching will also write to stderr, but a ""better"" fix from my point of view would be to either move the caching logs to stdout, and/or hide them completely unless a verbose flag is passed?",1,cmd go go module fetching gives unexpected stderr output what version of go are you using go version go version go version windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env set set goarch set gobin set gocache c users username appdata local go build set goenv c users username appdata roaming go env set goexe exe set goflags set gohostarch set gohostos windows set gonoproxy set gonosumdb set goos windows set gopath c users username dev set goprivate set goproxy set goroot c program files go set gosumdb sum golang org set gotmpdir set gotooldir c program files go pkg tool windows set gccgo gccgo set ar ar set cc gcc set cxx g set cgo enabled set gomod c users username dev src path to repo go mod set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags fno caret diagnostics qunused arguments fmessage length fdebug prefix map c users username appdata local temp go tmp go build gno record gcc switches what did you do go mod download what did you expect to see as per the documentation of the command by default download reports errors to standard error but is otherwise silent i expected no output on success what did you see instead a line to stderr for each module as it is cached go finding golang org x sys discussion this appears to come from here this is an issue since many many ci tools will fail the build on output to stderr we could redirect to stdout but then actual errors might be missed although that probably triggers a fail based on exit code the smallest possible fix would be to update the documentation so that it mentions that caching will also write to stderr but a better fix from my point of view would be to either move the caching logs to stdout and or hide them completely unless a verbose flag is passed ,1 52731,27749100446.0,IssuesEvent,2023-03-15 19:14:12,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: missed obvious inlining,Performance compiler/runtime,"I'm debugging a performance regression in [CL 466099](https://go.dev/cl/466099/6). One cause is that the compiler does not inline the call [from `newInlineUnwinder` to `resolveInternal`](https://go-review.git.corp.google.com/c/go/+/466096/5/src/runtime/symtabinl.go#56), even though `resolveInternal` is inlinable according to the `-m` output and the call [from `next` to `resolveInternal`](https://go-review.git.corp.google.com/c/go/+/466096/5/src/runtime/symtabinl.go#78) a few lines down *does* get inlined. This appears to be because [this call to `typecheck.HaveInlineBody`](https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/inline/inl.go;l=860;drc=7fb075ddc00cf73810f0032734ad1ac5f09fbbe1) returns false for `resolveInternal` when we're visiting `newInlineUnwinder` and true when we're visiting `next`. Beyond that I get past my depth. The -m output seems to indicate that the inliner visits `newInlineUnwinder`, then `resolveInternal`, then `next`, which is surprising because that's not in bottom-up order (and this is regardless of source order). If visiting a function is what creates the inline body, then this visit order is clearly a problem. Relevant -m output: ``` ./symtabinl.go:49:6: cannot inline newInlineUnwinder: function too complex: cost 173 exceeds budget 80 ./symtabinl.go:50:21: inlining call to funcdata ./symtabinl.go:60:6: can inline (*inlineUnwinder).resolveInternal with cost 73 as: method(*inlineUnwinder) func(uintptr) { u.pc = pc; u.index = pcdatavalue1(u.f, _PCDATA_InlTreeIndex, pc, u.cache, false) } ./symtab.go:1109:6: cannot inline pcdatavalue1: function too complex: cost 100 exceeds budget 80 ./symtab.go:1113:32: inlining call to pcdatastart ./symtab.go:1113:32: inlining call to add ./symtabinl.go:72:6: cannot inline (*inlineUnwinder).next: function too complex: cost 170 exceeds budget 80 ./symtabinl.go:78:29: inlining call to funcInfo.entry ./symtabinl.go:78:19: inlining call to (*inlineUnwinder).resolveInternal ``` cc @mdempsky @thanm ",True,"cmd/compile: missed obvious inlining - I'm debugging a performance regression in [CL 466099](https://go.dev/cl/466099/6). One cause is that the compiler does not inline the call [from `newInlineUnwinder` to `resolveInternal`](https://go-review.git.corp.google.com/c/go/+/466096/5/src/runtime/symtabinl.go#56), even though `resolveInternal` is inlinable according to the `-m` output and the call [from `next` to `resolveInternal`](https://go-review.git.corp.google.com/c/go/+/466096/5/src/runtime/symtabinl.go#78) a few lines down *does* get inlined. This appears to be because [this call to `typecheck.HaveInlineBody`](https://cs.opensource.google/go/go/+/master:src/cmd/compile/internal/inline/inl.go;l=860;drc=7fb075ddc00cf73810f0032734ad1ac5f09fbbe1) returns false for `resolveInternal` when we're visiting `newInlineUnwinder` and true when we're visiting `next`. Beyond that I get past my depth. The -m output seems to indicate that the inliner visits `newInlineUnwinder`, then `resolveInternal`, then `next`, which is surprising because that's not in bottom-up order (and this is regardless of source order). If visiting a function is what creates the inline body, then this visit order is clearly a problem. Relevant -m output: ``` ./symtabinl.go:49:6: cannot inline newInlineUnwinder: function too complex: cost 173 exceeds budget 80 ./symtabinl.go:50:21: inlining call to funcdata ./symtabinl.go:60:6: can inline (*inlineUnwinder).resolveInternal with cost 73 as: method(*inlineUnwinder) func(uintptr) { u.pc = pc; u.index = pcdatavalue1(u.f, _PCDATA_InlTreeIndex, pc, u.cache, false) } ./symtab.go:1109:6: cannot inline pcdatavalue1: function too complex: cost 100 exceeds budget 80 ./symtab.go:1113:32: inlining call to pcdatastart ./symtab.go:1113:32: inlining call to add ./symtabinl.go:72:6: cannot inline (*inlineUnwinder).next: function too complex: cost 170 exceeds budget 80 ./symtabinl.go:78:29: inlining call to funcInfo.entry ./symtabinl.go:78:19: inlining call to (*inlineUnwinder).resolveInternal ``` cc @mdempsky @thanm ",0,cmd compile missed obvious inlining i m debugging a performance regression in one cause is that the compiler does not inline the call even though resolveinternal is inlinable according to the m output and the call a few lines down does get inlined this appears to be because returns false for resolveinternal when we re visiting newinlineunwinder and true when we re visiting next beyond that i get past my depth the m output seems to indicate that the inliner visits newinlineunwinder then resolveinternal then next which is surprising because that s not in bottom up order and this is regardless of source order if visiting a function is what creates the inline body then this visit order is clearly a problem relevant m output symtabinl go cannot inline newinlineunwinder function too complex cost exceeds budget symtabinl go inlining call to funcdata symtabinl go can inline inlineunwinder resolveinternal with cost as method inlineunwinder func uintptr u pc pc u index u f pcdata inltreeindex pc u cache false symtab go cannot inline function too complex cost exceeds budget symtab go inlining call to pcdatastart symtab go inlining call to add symtabinl go cannot inline inlineunwinder next function too complex cost exceeds budget symtabinl go inlining call to funcinfo entry symtabinl go inlining call to inlineunwinder resolveinternal cc mdempsky thanm ,0 42279,10928262301.0,IssuesEvent,2019-11-22 18:37:27,golang/go,https://api.github.com/repos/golang/go,opened,x/build: add a builder that runs long tests with a gccgo toolchain,Builders NeedsInvestigation,"From the list at [build.golang.org](https://build.golang.org/), there don't seem to be any builders running a gccgo toolchain. It would be useful to have one to make sure we don't regress on gccgo support. For quick reference: [gccgo setup instructions](https://golang.org/doc/install/gccgo)",1.0,"x/build: add a builder that runs long tests with a gccgo toolchain - From the list at [build.golang.org](https://build.golang.org/), there don't seem to be any builders running a gccgo toolchain. It would be useful to have one to make sure we don't regress on gccgo support. For quick reference: [gccgo setup instructions](https://golang.org/doc/install/gccgo)",0,x build add a builder that runs long tests with a gccgo toolchain from the list at there don t seem to be any builders running a gccgo toolchain it would be useful to have one to make sure we don t regress on gccgo support for quick reference ,0 34831,6383514204.0,IssuesEvent,2017-08-03 00:35:36,golang/go,https://api.github.com/repos/golang/go,closed,doc: add note about vendoring,Documentation NeedsFix,"This is a documentation request for [How to Write Go Code](https://golang.org/doc/code.html). Given that the vendoring experiment is going away in 1.7, would it be possible to discuss vendoring and the vendor directory in the How to Write Go Code doc? ",1.0,"doc: add note about vendoring - This is a documentation request for [How to Write Go Code](https://golang.org/doc/code.html). Given that the vendoring experiment is going away in 1.7, would it be possible to discuss vendoring and the vendor directory in the How to Write Go Code doc? ",1,doc add note about vendoring this is a documentation request for given that the vendoring experiment is going away in would it be possible to discuss vendoring and the vendor directory in the how to write go code doc ,1 110350,11698917430.0,IssuesEvent,2020-03-06 14:44:51,golang/go,https://api.github.com/repos/golang/go,closed,doc: missing documentation of quoting the URL of url.Errors in go1.14 release notes,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.14 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/fraenky8/Library/Caches/go-build""
GOENV=""/Users/fraenky8/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOOS=""darwin""
GOPATH=""/Users/fraenky8/Coding/Go""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.14/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.14/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
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/8v/jgh2dzcn62n0lfyws13mc_rw0000gp/T/go-build103321297=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Print a `url.Error`: ```go err := &url.Error{ Op: ""Get"", URL: ""http://localhost/test/path"", Err: errors.New(""EOF""), } fmt.Printf(""something went wrong: %v"", err) ``` ### What did you expect to see? ``` something went wrong: Get http://localhost/test/path: EOF ``` ### What did you see instead? ``` something went wrong: Get ""http://localhost/test/path"": EOF ``` The URL is now quoted. This originates from PR https://github.com/golang/go/pull/29384 and is mentioned here: https://github.com/stellar/go/pull/2325#discussion_r385321367 The documentation in the release notes of go1.14 is missing for this change.",1.0,"doc: missing documentation of quoting the URL of url.Errors in go1.14 release notes - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/fraenky8/Library/Caches/go-build""
GOENV=""/Users/fraenky8/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOOS=""darwin""
GOPATH=""/Users/fraenky8/Coding/Go""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.14/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.14/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
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/8v/jgh2dzcn62n0lfyws13mc_rw0000gp/T/go-build103321297=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Print a `url.Error`: ```go err := &url.Error{ Op: ""Get"", URL: ""http://localhost/test/path"", Err: errors.New(""EOF""), } fmt.Printf(""something went wrong: %v"", err) ``` ### What did you expect to see? ``` something went wrong: Get http://localhost/test/path: EOF ``` ### What did you see instead? ``` something went wrong: Get ""http://localhost/test/path"": EOF ``` The URL is now quoted. This originates from PR https://github.com/golang/go/pull/29384 and is mentioned here: https://github.com/stellar/go/pull/2325#discussion_r385321367 The documentation in the release notes of go1.14 is missing for this change.",1,doc missing documentation of quoting the url of url errors in release notes what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users library caches go build goenv users library application support go env goexe goflags gohostarch gohostos darwin goinsecure goos darwin gopath users coding go goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do print a url error go err url error op get url err errors new eof fmt printf something went wrong v err what did you expect to see something went wrong get eof what did you see instead something went wrong get eof the url is now quoted this originates from pr and is mentioned here the documentation in the release notes of is missing for this change ,1 354373,25163542308.0,IssuesEvent,2022-11-10 18:43:35,golang/go,https://api.github.com/repos/golang/go,closed,os: document that WriteFile is not atomic,Documentation help wanted NeedsFix,"As I was replying to https://github.com/golang/go/issues/56172, I was looking at the docs for https://pkg.go.dev/os#WriteFile, which say: ``` // WriteFile writes data to the named file, creating it if necessary. // If the file does not exist, WriteFile creates it with permissions perm (before umask); // otherwise WriteFile truncates it before writing, without changing permissions. func WriteFile(name string, data []byte, perm FileMode) error { ``` I know that this operation isn't atomic: for example, if a write to the file fails half-way through, we may be left with a partial file. That is why alternatives like https://pkg.go.dev/github.com/google/renameio#WriteFile exist. However, by just reading the docs as a new user, it could be an easy misconception. A lot of the other `os` APIs like `Create`, `Mkdir`, or `Chmod` are atomic at the system level - they only perform a single system call which modifies the filesystem, so we can't be left with partial changes. Perhaps we should add a godoc note that the API is not atomic. That is, that if an error occurs, the file might be left behind. I imagine this won't matter for many cases, but the warning would be very useful for any Go program which cares about invalid or incomplete states. cc @ianlancetaylor @stapelberg ",1.0,"os: document that WriteFile is not atomic - As I was replying to https://github.com/golang/go/issues/56172, I was looking at the docs for https://pkg.go.dev/os#WriteFile, which say: ``` // WriteFile writes data to the named file, creating it if necessary. // If the file does not exist, WriteFile creates it with permissions perm (before umask); // otherwise WriteFile truncates it before writing, without changing permissions. func WriteFile(name string, data []byte, perm FileMode) error { ``` I know that this operation isn't atomic: for example, if a write to the file fails half-way through, we may be left with a partial file. That is why alternatives like https://pkg.go.dev/github.com/google/renameio#WriteFile exist. However, by just reading the docs as a new user, it could be an easy misconception. A lot of the other `os` APIs like `Create`, `Mkdir`, or `Chmod` are atomic at the system level - they only perform a single system call which modifies the filesystem, so we can't be left with partial changes. Perhaps we should add a godoc note that the API is not atomic. That is, that if an error occurs, the file might be left behind. I imagine this won't matter for many cases, but the warning would be very useful for any Go program which cares about invalid or incomplete states. cc @ianlancetaylor @stapelberg ",1,os document that writefile is not atomic as i was replying to i was looking at the docs for which say writefile writes data to the named file creating it if necessary if the file does not exist writefile creates it with permissions perm before umask otherwise writefile truncates it before writing without changing permissions func writefile name string data byte perm filemode error i know that this operation isn t atomic for example if a write to the file fails half way through we may be left with a partial file that is why alternatives like exist however by just reading the docs as a new user it could be an easy misconception a lot of the other os apis like create mkdir or chmod are atomic at the system level they only perform a single system call which modifies the filesystem so we can t be left with partial changes perhaps we should add a godoc note that the api is not atomic that is that if an error occurs the file might be left behind i imagine this won t matter for many cases but the warning would be very useful for any go program which cares about invalid or incomplete states cc ianlancetaylor stapelberg ,1 275064,20905232072.0,IssuesEvent,2022-03-24 00:54:36,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: ""Contribution Guide"" is hard to find",Documentation NeedsFix," ### What is the URL of the page with the issue? https://go.dev/doc/contribute ### What is your user agent? `Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0` ### What did you do? Looked for the contribution guide, since it has been a while. I don't remember the URL of the page. ### What did you expect to see? A link on go.dev/doc. ### What did you see instead? No such link. The way I found it was ""Get Started"" -> ""view the install documentation"" -> ""Installing Go from source"" -> ""contribute your changes,"" following links in a variety of places on their respective pages. Granted, I could have found it from the contribution guidelines here on GitHub, but I didn't expect it to be so hard to find on go.dev. ",1.0,"x/website: ""Contribution Guide"" is hard to find - ### What is the URL of the page with the issue? https://go.dev/doc/contribute ### What is your user agent? `Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0` ### What did you do? Looked for the contribution guide, since it has been a while. I don't remember the URL of the page. ### What did you expect to see? A link on go.dev/doc. ### What did you see instead? No such link. The way I found it was ""Get Started"" -> ""view the install documentation"" -> ""Installing Go from source"" -> ""contribute your changes,"" following links in a variety of places on their respective pages. Granted, I could have found it from the contribution guidelines here on GitHub, but I didn't expect it to be so hard to find on go.dev. ",1,x website contribution guide is hard to find please answer these questions before submitting your issue thanks what is the url of the page with the issue what is your user agent you can find your user agent here mozilla ubuntu linux rv gecko firefox what did you do if possible provide a recipe for reproducing the error looked for the contribution guide since it has been a while i don t remember the url of the page what did you expect to see a link on go dev doc what did you see instead no such link the way i found it was get started view the install documentation installing go from source contribute your changes following links in a variety of places on their respective pages granted i could have found it from the contribution guidelines here on github but i didn t expect it to be so hard to find on go dev ,1 55414,7986133616.0,IssuesEvent,2018-07-19 00:12:45,golang/go,https://api.github.com/repos/golang/go,closed,doc: update FAQ,Documentation NeedsFix,"At the moment, just after the launch of Go 1.11 beta 1, the FAQ needs tidying. Much of the prose is about the earliest parts of the project, and the associated tone isn't right. Meanwhile, much of the modern success story is missing. As a trivial example, surely a project like Kubernetes should be mentioned, and Google's internal use is more extensive than the corresponding question implies. The discussion of Go 2 needs updating, and so on. I'll assign this to myself but am happy to review updates from others. I only ask we keep the answers concise; it's a FAQ, not a manual or design document.",1.0,"doc: update FAQ - At the moment, just after the launch of Go 1.11 beta 1, the FAQ needs tidying. Much of the prose is about the earliest parts of the project, and the associated tone isn't right. Meanwhile, much of the modern success story is missing. As a trivial example, surely a project like Kubernetes should be mentioned, and Google's internal use is more extensive than the corresponding question implies. The discussion of Go 2 needs updating, and so on. I'll assign this to myself but am happy to review updates from others. I only ask we keep the answers concise; it's a FAQ, not a manual or design document.",1,doc update faq at the moment just after the launch of go beta the faq needs tidying much of the prose is about the earliest parts of the project and the associated tone isn t right meanwhile much of the modern success story is missing as a trivial example surely a project like kubernetes should be mentioned and google s internal use is more extensive than the corresponding question implies the discussion of go needs updating and so on i ll assign this to myself but am happy to review updates from others i only ask we keep the answers concise it s a faq not a manual or design document ,1 16202,4028024656.0,IssuesEvent,2016-05-18 03:08:02,golang/go,https://api.github.com/repos/golang/go,closed,crypto/x509: typo in docs for x509.CreateCertificateRequest,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6 darwin/amd64 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOOS=""darwin"" 3. What did you do? (Use play.golang.org to provide a runnable example, if possible.) Read https://golang.org/pkg/crypto/x509/#CreateCertificateRequest 4. What did you expect to see? ""CreateCertificateRequest creates a new certificate request based on a template."" 5. What did you see instead? ""CreateCertificateRequest creates a new certificate based on a template."" This was really confusing for a minute because there is currently no exposed function in x509 that creates a certificate from a request, but that sentence implies that's what CreateCertificateRequest does, even though the name of the function makes it sort of obvious that's not what it does. ",1.0,"crypto/x509: typo in docs for x509.CreateCertificateRequest - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? go version go1.6 darwin/amd64 2. What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOOS=""darwin"" 3. What did you do? (Use play.golang.org to provide a runnable example, if possible.) Read https://golang.org/pkg/crypto/x509/#CreateCertificateRequest 4. What did you expect to see? ""CreateCertificateRequest creates a new certificate request based on a template."" 5. What did you see instead? ""CreateCertificateRequest creates a new certificate based on a template."" This was really confusing for a minute because there is currently no exposed function in x509 that creates a certificate from a request, but that sentence implies that's what CreateCertificateRequest does, even though the name of the function makes it sort of obvious that's not what it does. ",1,crypto typo in docs for createcertificaterequest please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch goos darwin what did you do use play golang org to provide a runnable example if possible read what did you expect to see createcertificaterequest creates a new certificate request based on a template what did you see instead createcertificaterequest creates a new certificate based on a template this was really confusing for a minute because there is currently no exposed function in that creates a certificate from a request but that sentence implies that s what createcertificaterequest does even though the name of the function makes it sort of obvious that s not what it does ,1 395242,27061616551.0,IssuesEvent,2023-02-13 20:15:00,golang/go,https://api.github.com/repos/golang/go,closed,math/big: document unsuitability for cryptography,Documentation,"We mentioned in the Go 1.20 release notes that following our own migration off math/big for cryptography (#52182), the package makes an especially bad choice for cryptographic use. The package docs should mention that too.",1.0,"math/big: document unsuitability for cryptography - We mentioned in the Go 1.20 release notes that following our own migration off math/big for cryptography (#52182), the package makes an especially bad choice for cryptographic use. The package docs should mention that too.",1,math big document unsuitability for cryptography we mentioned in the go release notes that following our own migration off math big for cryptography the package makes an especially bad choice for cryptographic use the package docs should mention that too ,1 189841,15208220023.0,IssuesEvent,2021-02-17 02:05:03,golang/go,https://api.github.com/repos/golang/go,closed,embed: warn about dotfiles in embed.FS documentation,Documentation NeedsFix,"### What version of Go are you using (`go version`)? Tip. 
$ gotip version
go version devel +48be3ed Sat Oct 31 00:35:33 2020 +0000 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you do? Tried out the new embed.FS feature. example.go: ``` package main import ( ""embed"" ""fmt"" ""io/fs"" ) func main() { //go:embed example/* var files embed.FS des, _ := fs.ReadDir(files, ""example"") for _, de := range des { fmt.Printf(""%q\n"", de.Name()) } } ``` example: ``` total 1504 drwxr-xr-x@ 6 adhoc staff 192 Oct 30 21:49 . drwx------ 8 adhoc staff 256 Nov 1 13:34 .. -rw-r--r--@ 1 adhoc staff 6148 Oct 30 21:49 .DS_Store -rw-r--r-- 1 adhoc staff 0 Oct 30 21:47 .dot -rw-r--r--@ 1 adhoc staff 0 Oct 30 21:48 Icon -rw-r--r-- 1 adhoc staff 0 Oct 30 21:47 one.txt ``` ### What did you expect to see? ``` $ gotip run . ""one.txt"" ``` ### What did you see instead? ``` $ gotip run . "".DS_Store"" "".dot"" ""Icon\r"" ""one.txt"" ``` - - - - There should be a warning in the documentation that dotfiles and hidden files are included.",1.0,"embed: warn about dotfiles in embed.FS documentation - ### What version of Go are you using (`go version`)? Tip. 
$ gotip version
go version devel +48be3ed Sat Oct 31 00:35:33 2020 +0000 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you do? Tried out the new embed.FS feature. example.go: ``` package main import ( ""embed"" ""fmt"" ""io/fs"" ) func main() { //go:embed example/* var files embed.FS des, _ := fs.ReadDir(files, ""example"") for _, de := range des { fmt.Printf(""%q\n"", de.Name()) } } ``` example: ``` total 1504 drwxr-xr-x@ 6 adhoc staff 192 Oct 30 21:49 . drwx------ 8 adhoc staff 256 Nov 1 13:34 .. -rw-r--r--@ 1 adhoc staff 6148 Oct 30 21:49 .DS_Store -rw-r--r-- 1 adhoc staff 0 Oct 30 21:47 .dot -rw-r--r--@ 1 adhoc staff 0 Oct 30 21:48 Icon -rw-r--r-- 1 adhoc staff 0 Oct 30 21:47 one.txt ``` ### What did you expect to see? ``` $ gotip run . ""one.txt"" ``` ### What did you see instead? ``` $ gotip run . "".DS_Store"" "".dot"" ""Icon\r"" ""one.txt"" ``` - - - - There should be a warning in the documentation that dotfiles and hidden files are included.",1,embed warn about dotfiles in embed fs documentation what version of go are you using go version tip gotip version go version devel sat oct darwin does this issue reproduce with the latest release yes what did you do tried out the new embed fs feature example go package main import embed fmt io fs func main go embed example var files embed fs des fs readdir files example for de range des fmt printf q n de name example total drwxr xr x adhoc staff oct drwx adhoc staff nov rw r r adhoc staff oct ds store rw r r adhoc staff oct dot rw r r adhoc staff oct icon rw r r adhoc staff oct one txt what did you expect to see gotip run one txt what did you see instead gotip run ds store dot icon r one txt there should be a warning in the documentation that dotfiles and hidden files are included ,1 8278,2974683394.0,IssuesEvent,2015-07-15 03:12:26,golang/go,https://api.github.com/repos/golang/go,closed,net: windows TestDialTimeout flake,OS-Windows Testing,"Noticed this flake: http://build.golang.org/log/de2ea0b431bc216003fd8762e62bbd46b3511fca ``` ... ok math/rand 5.305s ok mime 1.365s ok mime/multipart 2.470s ok mime/quotedprintable 3.075s --- FAIL: TestDialTimeout (0.00s) timeout_test.go:82: #3: dial tcp 127.0.0.1:0: connectex: The requested address is not valid in its context. FAIL FAIL net 21.902s ok net/http 10.666s ok net/http/cgi 6.718s ok net/http/cookiejar 1.583s ... ``` /cc @alexbrainman @mikioh ",1.0,"net: windows TestDialTimeout flake - Noticed this flake: http://build.golang.org/log/de2ea0b431bc216003fd8762e62bbd46b3511fca ``` ... ok math/rand 5.305s ok mime 1.365s ok mime/multipart 2.470s ok mime/quotedprintable 3.075s --- FAIL: TestDialTimeout (0.00s) timeout_test.go:82: #3: dial tcp 127.0.0.1:0: connectex: The requested address is not valid in its context. FAIL FAIL net 21.902s ok net/http 10.666s ok net/http/cgi 6.718s ok net/http/cookiejar 1.583s ... ``` /cc @alexbrainman @mikioh ",0,net windows testdialtimeout flake noticed this flake ok math rand ok mime ok mime multipart ok mime quotedprintable fail testdialtimeout timeout test go dial tcp connectex the requested address is not valid in its context fail fail net ok net http ok net http cgi ok net http cookiejar cc alexbrainman mikioh ,0 39181,10311932208.0,IssuesEvent,2019-08-29 18:35:07,golang/go,https://api.github.com/repos/golang/go,closed,x/perf/analysis/appengine: failing in release-branch.go1.12 builders,Builders NeedsInvestigation Testing,"As of [CL 191378](https://golang.org/cl/191378), the `x/perf` build now requires module mode in order to build the binaries in `analysis/appengine`. The problem seems to be the dependency on `google.golang.org/appengine`, which used to be notched out by the `+build appengine` constraint but no longer is. That works fine on builders in module mode, because they can fetch the module — but it causes the builds to fail in GOPATH-mode builders. CC @andybons @katiehockman @toothrot @dmitshur ",1.0,"x/perf/analysis/appengine: failing in release-branch.go1.12 builders - As of [CL 191378](https://golang.org/cl/191378), the `x/perf` build now requires module mode in order to build the binaries in `analysis/appengine`. The problem seems to be the dependency on `google.golang.org/appengine`, which used to be notched out by the `+build appengine` constraint but no longer is. That works fine on builders in module mode, because they can fetch the module — but it causes the builds to fail in GOPATH-mode builders. CC @andybons @katiehockman @toothrot @dmitshur ",0,x perf analysis appengine failing in release branch builders as of the x perf build now requires module mode in order to build the binaries in analysis appengine the problem seems to be the dependency on google golang org appengine which used to be notched out by the build appengine constraint but no longer is that works fine on builders in module mode because they can fetch the module — but it causes the builds to fail in gopath mode builders cc andybons katiehockman toothrot dmitshur ,0 7524,6061309710.0,IssuesEvent,2017-06-14 06:05:35,golang/go,https://api.github.com/repos/golang/go,closed,go/token: use fine-grained locking in token.File,Performance,"Because access to the lines and info fields of token.File are protected by the mutex of the parent FileSet, all concurrent calls to AddLine in a typical application contend for the same lock, which becomes a major bottleneck when parsing files in parallel, as done by golang.org/x/tools/go/loader for example. Fine-grained locking, that is, an additional mutex in each token.File that protects these two fields, eliminates the bottleneck. I quickly prototyped and measured it on a realistic application, and execution time fell to 580ms from 700m, an improvement of nearly 20%. The necessary change is straightforward except for two places: (1) In its loop, (*FileSet).Write needs to make a copy of each File's lines and infos while holding the file's mutex. (2) (*File).PositionFor seems to have a pre-existing data race, since it calls File.position without a lock, which calls unpack, which reads the lines and info fields.",True,"go/token: use fine-grained locking in token.File - Because access to the lines and info fields of token.File are protected by the mutex of the parent FileSet, all concurrent calls to AddLine in a typical application contend for the same lock, which becomes a major bottleneck when parsing files in parallel, as done by golang.org/x/tools/go/loader for example. Fine-grained locking, that is, an additional mutex in each token.File that protects these two fields, eliminates the bottleneck. I quickly prototyped and measured it on a realistic application, and execution time fell to 580ms from 700m, an improvement of nearly 20%. The necessary change is straightforward except for two places: (1) In its loop, (*FileSet).Write needs to make a copy of each File's lines and infos while holding the file's mutex. (2) (*File).PositionFor seems to have a pre-existing data race, since it calls File.position without a lock, which calls unpack, which reads the lines and info fields.",0,go token use fine grained locking in token file because access to the lines and info fields of token file are protected by the mutex of the parent fileset all concurrent calls to addline in a typical application contend for the same lock which becomes a major bottleneck when parsing files in parallel as done by golang org x tools go loader for example fine grained locking that is an additional mutex in each token file that protects these two fields eliminates the bottleneck i quickly prototyped and measured it on a realistic application and execution time fell to from an improvement of nearly the necessary change is straightforward except for two places in its loop fileset write needs to make a copy of each file s lines and infos while holding the file s mutex file positionfor seems to have a pre existing data race since it calls file position without a lock which calls unpack which reads the lines and info fields ,0 6197,3005376773.0,IssuesEvent,2015-07-26 21:04:59,golang/go,https://api.github.com/repos/golang/go,closed,doc: clarify usage of CGO_ENABLED,Documentation,"I was trying to repro issue #9510. I'm on a linux/amd64 system, and I used ""GOARCH=386 ./make.bash --no-clean"" to setup a cross-compiler toolchain. However, subsequently running ""GOARCH=386 go build issue"" per iant@'s instructions yielded an unhelpful ""no buildable Go source files in .../issue/a"" error. Poking into the package go/build source code, I discovered mention of ""CGO_ENABLED"" so I tried ""GOARCH=386 CGO_ENABLED=1 go build issue"". This worked to reproduce the issue. However, trying to learn more about this setting, I found this in cmd/cgo/doc.go: To enable cgo during cross compiling builds, set the CGO_ENABLED environment variable to 1 when building the Go tools with make.bash. So I inferred I was misusing it and decided to startover with ""GOARCH=386 CGO_ENABLED=1 ./make.bash --no-clean"" instead, but then running just ""GOARCH=386 go build issue"" again produced the same ""no buildable Go source files"" error. Confusingly, src/make.bash also seems to mention CGO_ENABLED having some significance, but at the moment (even having poked through run.bash and grep'd the source code), I'm still not sure I entirely understand the significance.",1.0,"doc: clarify usage of CGO_ENABLED - I was trying to repro issue #9510. I'm on a linux/amd64 system, and I used ""GOARCH=386 ./make.bash --no-clean"" to setup a cross-compiler toolchain. However, subsequently running ""GOARCH=386 go build issue"" per iant@'s instructions yielded an unhelpful ""no buildable Go source files in .../issue/a"" error. Poking into the package go/build source code, I discovered mention of ""CGO_ENABLED"" so I tried ""GOARCH=386 CGO_ENABLED=1 go build issue"". This worked to reproduce the issue. However, trying to learn more about this setting, I found this in cmd/cgo/doc.go: To enable cgo during cross compiling builds, set the CGO_ENABLED environment variable to 1 when building the Go tools with make.bash. So I inferred I was misusing it and decided to startover with ""GOARCH=386 CGO_ENABLED=1 ./make.bash --no-clean"" instead, but then running just ""GOARCH=386 go build issue"" again produced the same ""no buildable Go source files"" error. Confusingly, src/make.bash also seems to mention CGO_ENABLED having some significance, but at the moment (even having poked through run.bash and grep'd the source code), I'm still not sure I entirely understand the significance.",1,doc clarify usage of cgo enabled i was trying to repro issue i m on a linux system and i used goarch make bash no clean to setup a cross compiler toolchain however subsequently running goarch go build issue per iant s instructions yielded an unhelpful no buildable go source files in issue a error poking into the package go build source code i discovered mention of cgo enabled so i tried goarch cgo enabled go build issue this worked to reproduce the issue however trying to learn more about this setting i found this in cmd cgo doc go to enable cgo during cross compiling builds set the cgo enabled environment variable to when building the go tools with make bash so i inferred i was misusing it and decided to startover with goarch cgo enabled make bash no clean instead but then running just goarch go build issue again produced the same no buildable go source files error confusingly src make bash also seems to mention cgo enabled having some significance but at the moment even having poked through run bash and grep d the source code i m still not sure i entirely understand the significance ,1 71720,18849410500.0,IssuesEvent,2021-11-11 18:45:22,golang/go,https://api.github.com/repos/golang/go,closed,x/review/git-codereview: test timed out on windows-arm-zx2c4 builder,Builders NeedsInvestigation,"[2020-09-11T20:38:40-0edcede/windows-arm-zx2c4](https://build.golang.org/log/58a8dd9300dc4313d7f829aa0b794177a94a948f) Not obvious to me whether the builder is just slow or the test triggered some kind of deadlock. CC @zx2c4 @golang/release ",1.0,"x/review/git-codereview: test timed out on windows-arm-zx2c4 builder - [2020-09-11T20:38:40-0edcede/windows-arm-zx2c4](https://build.golang.org/log/58a8dd9300dc4313d7f829aa0b794177a94a948f) Not obvious to me whether the builder is just slow or the test triggered some kind of deadlock. CC @zx2c4 @golang/release ",0,x review git codereview test timed out on windows arm builder not obvious to me whether the builder is just slow or the test triggered some kind of deadlock cc golang release ,0 6435,3022485562.0,IssuesEvent,2015-07-31 20:39:03,golang/go,https://api.github.com/repos/golang/go,closed,spec: minor changes to examples,Documentation,"Three small suggestions for the examples in the Go Specification: In the ```TimeZone``` type, the line ``` return fmt.Sprintf(""GMT+%dh"", tz) ``` returns something like ```GMT+-5h```. I think it would be better to change ```+%``` to ```%+```: ``` return fmt.Sprintf(""GMT%+dh"", tz) ``` so the result is ```GMT-5h```. In ```findMarker```, if a return statement were added, the loop would only check every other item in the channel, because it uses both a for/range and a channel receive operation. The example would be less confusing with just one of those. For/range hasn't been introduced yet, so that's what I would remove. In the Selectors section, the anonymous field ```T0``` of type ```T2``` is already a pointer. So the line ``` p.M0() // ((&(*p).T0)).M0() M0 expects *T0 receiver, see section on Calls ``` isn't an example of a shorthand reference to an addressable value. I think the comment should be: ``` p.M0() // ((*p).T0).M0() M0 expects *T0 receiver ``` A shorthand example could be added: ``` t.M2() // (&t).M2() M2 expects *T2 receiver, see section on Calls ``` These suggestions are current as of Go 1.5 beta 3.",1.0,"spec: minor changes to examples - Three small suggestions for the examples in the Go Specification: In the ```TimeZone``` type, the line ``` return fmt.Sprintf(""GMT+%dh"", tz) ``` returns something like ```GMT+-5h```. I think it would be better to change ```+%``` to ```%+```: ``` return fmt.Sprintf(""GMT%+dh"", tz) ``` so the result is ```GMT-5h```. In ```findMarker```, if a return statement were added, the loop would only check every other item in the channel, because it uses both a for/range and a channel receive operation. The example would be less confusing with just one of those. For/range hasn't been introduced yet, so that's what I would remove. In the Selectors section, the anonymous field ```T0``` of type ```T2``` is already a pointer. So the line ``` p.M0() // ((&(*p).T0)).M0() M0 expects *T0 receiver, see section on Calls ``` isn't an example of a shorthand reference to an addressable value. I think the comment should be: ``` p.M0() // ((*p).T0).M0() M0 expects *T0 receiver ``` A shorthand example could be added: ``` t.M2() // (&t).M2() M2 expects *T2 receiver, see section on Calls ``` These suggestions are current as of Go 1.5 beta 3.",1,spec minor changes to examples three small suggestions for the examples in the go specification in the timezone type the line return fmt sprintf gmt dh tz returns something like gmt i think it would be better to change to return fmt sprintf gmt dh tz so the result is gmt in findmarker if a return statement were added the loop would only check every other item in the channel because it uses both a for range and a channel receive operation the example would be less confusing with just one of those for range hasn t been introduced yet so that s what i would remove in the selectors section the anonymous field of type is already a pointer so the line p p expects receiver see section on calls isn t an example of a shorthand reference to an addressable value i think the comment should be p p expects receiver a shorthand example could be added t t expects receiver see section on calls these suggestions are current as of go beta ,1 62155,8578619326.0,IssuesEvent,2018-11-13 06:03:14,golang/go,https://api.github.com/repos/golang/go,closed,builtin: documentation should clarify how len() behaves,Documentation,"Currently the `len( )` function returns an `int`. Changing it to `uint` has already been proposed and rejected. Can the documentation clarify what `len( )` returns when the number of items in a slice exceeds the max value of an int?",1.0,"builtin: documentation should clarify how len() behaves - Currently the `len( )` function returns an `int`. Changing it to `uint` has already been proposed and rejected. Can the documentation clarify what `len( )` returns when the number of items in a slice exceeds the max value of an int?",1,builtin documentation should clarify how len behaves currently the len function returns an int changing it to uint has already been proposed and rejected can the documentation clarify what len returns when the number of items in a slice exceeds the max value of an int ,1 28866,5543546478.0,IssuesEvent,2017-03-22 17:09:47,golang/go,https://api.github.com/repos/golang/go,closed,wiki: wrong/outdated instructions on the Ubuntu page,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.8 ### What operating system and processor architecture are you using (`go env`)? Ubuntu Linux 16.10 ### What did you do? Followed the readme If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? Golang 1.8 as a package. ### What did you see instead? Your instructions appear to be installing LXD PPA repo and then installing golang 1.6 from the universe repository. >sudo add-apt-repository ppa:ubuntu-lxc/lxd-stable sudo apt-get update sudo apt-get install golang That's just wrong. The bottom of the page instructions work alright. But if you have a PPA you should update the instructions and if you don't have a PPA (I couldn't find one), then you should remove those instructions. Thanks!",1.0,"wiki: wrong/outdated instructions on the Ubuntu page - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.8 ### What operating system and processor architecture are you using (`go env`)? Ubuntu Linux 16.10 ### What did you do? Followed the readme If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? Golang 1.8 as a package. ### What did you see instead? Your instructions appear to be installing LXD PPA repo and then installing golang 1.6 from the universe repository. >sudo add-apt-repository ppa:ubuntu-lxc/lxd-stable sudo apt-get update sudo apt-get install golang That's just wrong. The bottom of the page instructions work alright. But if you have a PPA you should update the instructions and if you don't have a PPA (I couldn't find one), then you should remove those instructions. Thanks!",1,wiki wrong outdated instructions on the ubuntu page please answer these questions before submitting your issue thanks what version of go are you using go version what operating system and processor architecture are you using go env ubuntu linux what did you do followed the readme if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see golang as a package what did you see instead your instructions appear to be installing lxd ppa repo and then installing golang from the universe repository sudo add apt repository ppa ubuntu lxc lxd stable sudo apt get update sudo apt get install golang that s just wrong the bottom of the page instructions work alright but if you have a ppa you should update the instructions and if you don t have a ppa i couldn t find one then you should remove those instructions thanks ,1 32364,6050103331.0,IssuesEvent,2017-06-12 20:18:22,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: QueryRow should verify that we have only one row,Documentation,"`QueryRow` is documented as follows: ```go // QueryRow executes a query that is expected to return at most one row. // QueryRow always returns a non-nil value. Errors are deferred until // Row's Scan method is called. ``` This suggests that we should get an error if the query returns more than one row. However `Row.Scan()` doesn't check that `r.rows.Next()` returns false after processing one row, so it would ignore any remaining rows. Conversely ""at most one row"" suggests that getting no rows is somehow acceptable, but an error is returned in that case. I think it should say ""exactly one row"".",1.0,"database/sql: QueryRow should verify that we have only one row - `QueryRow` is documented as follows: ```go // QueryRow executes a query that is expected to return at most one row. // QueryRow always returns a non-nil value. Errors are deferred until // Row's Scan method is called. ``` This suggests that we should get an error if the query returns more than one row. However `Row.Scan()` doesn't check that `r.rows.Next()` returns false after processing one row, so it would ignore any remaining rows. Conversely ""at most one row"" suggests that getting no rows is somehow acceptable, but an error is returned in that case. I think it should say ""exactly one row"".",1,database sql queryrow should verify that we have only one row queryrow is documented as follows go queryrow executes a query that is expected to return at most one row queryrow always returns a non nil value errors are deferred until row s scan method is called this suggests that we should get an error if the query returns more than one row however row scan doesn t check that r rows next returns false after processing one row so it would ignore any remaining rows conversely at most one row suggests that getting no rows is somehow acceptable but an error is returned in that case i think it should say exactly one row ,1 75574,7477548311.0,IssuesEvent,2018-04-04 08:41:01,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/ssh: TestMuxReadWrite flake,NeedsFix Testing help wanted,"Flake on trybot run at https://storage.googleapis.com/go-build-log/4468b0ba/windows-386-2008_b5f0b931.log ... ``` panic: Fail in goroutine after TestMuxReadWrite has completed goroutine 1387 [running]: testing.(*common).Fail(0x12841200) C:/workdir/go/src/testing/testing.go:512 +0xf8 testing.(*common).FailNow(0x12841200) C:/workdir/go/src/testing/testing.go:534 +0x21 testing.(*common).Fatalf(0x12841200, 0x6ce724, 0x9, 0x12cf5fbc, 0x1, 0x1) C:/workdir/go/src/testing/testing.go:600 +0x69 golang.org/x/crypto/ssh.TestMuxReadWrite.func1(0x12a7a400, 0x6cf433, 0xb, 0x12841200, 0x6cfa12, 0xc) C:/workdir/gopath/src/golang.org/x/crypto/ssh/mux_test.go:113 +0x1e8 created by golang.org/x/crypto/ssh.TestMuxReadWrite C:/workdir/gopath/src/golang.org/x/crypto/ssh/mux_test.go:102 +0x102 FAIL golang.org/x/crypto/ssh 3.991s ``` /cc @hanwen ",1.0,"x/crypto/ssh: TestMuxReadWrite flake - Flake on trybot run at https://storage.googleapis.com/go-build-log/4468b0ba/windows-386-2008_b5f0b931.log ... ``` panic: Fail in goroutine after TestMuxReadWrite has completed goroutine 1387 [running]: testing.(*common).Fail(0x12841200) C:/workdir/go/src/testing/testing.go:512 +0xf8 testing.(*common).FailNow(0x12841200) C:/workdir/go/src/testing/testing.go:534 +0x21 testing.(*common).Fatalf(0x12841200, 0x6ce724, 0x9, 0x12cf5fbc, 0x1, 0x1) C:/workdir/go/src/testing/testing.go:600 +0x69 golang.org/x/crypto/ssh.TestMuxReadWrite.func1(0x12a7a400, 0x6cf433, 0xb, 0x12841200, 0x6cfa12, 0xc) C:/workdir/gopath/src/golang.org/x/crypto/ssh/mux_test.go:113 +0x1e8 created by golang.org/x/crypto/ssh.TestMuxReadWrite C:/workdir/gopath/src/golang.org/x/crypto/ssh/mux_test.go:102 +0x102 FAIL golang.org/x/crypto/ssh 3.991s ``` /cc @hanwen ",0,x crypto ssh testmuxreadwrite flake flake on trybot run at panic fail in goroutine after testmuxreadwrite has completed goroutine testing common fail c workdir go src testing testing go testing common failnow c workdir go src testing testing go testing common fatalf c workdir go src testing testing go golang org x crypto ssh testmuxreadwrite c workdir gopath src golang org x crypto ssh mux test go created by golang org x crypto ssh testmuxreadwrite c workdir gopath src golang org x crypto ssh mux test go fail golang org x crypto ssh cc hanwen ,0 3242,2752093801.0,IssuesEvent,2015-04-24 13:45:14,golang/go,https://api.github.com/repos/golang/go,closed,hash/crc32: clarify documentation,Documentation,"by **sheetjs**: 
Documentation currently says:

"MakeTable returns the Table constructed from the specified polynomial."

Somewhere in the doc, it should explicitly state that poly (the 32 bit integer) should
be based on the reversed representation.  It's implied by the constant "IEEE =
0xedb88320" (the normal representation for that case is 0x04c11db7), but making it
clear wouldn't hurt
",1.0,"hash/crc32: clarify documentation - by **sheetjs**: 
Documentation currently says:

"MakeTable returns the Table constructed from the specified polynomial."

Somewhere in the doc, it should explicitly state that poly (the 32 bit integer) should
be based on the reversed representation.  It's implied by the constant "IEEE =
0xedb88320" (the normal representation for that case is 0x04c11db7), but making it
clear wouldn't hurt
",1,hash clarify documentation by sheetjs documentation currently says quot maketable returns the table constructed from the specified polynomial quot somewhere in the doc it should explicitly state that poly the bit integer should be based on the reversed representation it s implied by the constant quot ieee quot the normal representation for that case is but making it clear wouldn t hurt ,1 31979,6022657744.0,IssuesEvent,2017-06-07 21:35:57,golang/go,https://api.github.com/repos/golang/go,closed,"sync: clarify Cond ""created as part of other structures"" documentation",Documentation,"### What version of Go are you using (`go version`)? go version go1.8.1 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/joneskoo"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.1/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p9/8mb6mhcx7p3br8f18crtczzw0000gn/T/go-build980179018=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? I'm creating a sync.Cond as part of a struct. [Documentation explicitly says this is ok](https://tip.golang.org/pkg/sync/#Cond). https://play.golang.org/p/k0EkYJPC4A ### What did you expect to see? Wait for Cond until Broadcast is called one second later. ### What did you see instead? ``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0xffffffff addr=0x0 pc=0x82ffb] goroutine 1 [running]: sync.(*Cond).Wait(0x104401a0, 0x0) /usr/local/go/src/sync/cond.go:56 +0x7b main.main() /tmp/sandbox578695461/main.go:17 +0x120 ``` There isn't an example for sync.Cond in the documentation and it's hardly used in the standard library. Should the documentation explain that the locker must be set if the Cond is created as part of a structure? If yes, then what does this really mean: > A Cond can be created as part of other structures. A Cond must not be copied after first use. Please update title if this turns out to be a documentation issue. A simple example and where the Cond might be useful would be nice.",1.0,"sync: clarify Cond ""created as part of other structures"" documentation - ### What version of Go are you using (`go version`)? go version go1.8.1 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/joneskoo"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.1/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p9/8mb6mhcx7p3br8f18crtczzw0000gn/T/go-build980179018=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? I'm creating a sync.Cond as part of a struct. [Documentation explicitly says this is ok](https://tip.golang.org/pkg/sync/#Cond). https://play.golang.org/p/k0EkYJPC4A ### What did you expect to see? Wait for Cond until Broadcast is called one second later. ### What did you see instead? ``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0xffffffff addr=0x0 pc=0x82ffb] goroutine 1 [running]: sync.(*Cond).Wait(0x104401a0, 0x0) /usr/local/go/src/sync/cond.go:56 +0x7b main.main() /tmp/sandbox578695461/main.go:17 +0x120 ``` There isn't an example for sync.Cond in the documentation and it's hardly used in the standard library. Should the documentation explain that the locker must be set if the Cond is created as part of a structure? If yes, then what does this really mean: > A Cond can be created as part of other structures. A Cond must not be copied after first use. Please update title if this turns out to be a documentation issue. A simple example and where the Cond might be useful would be nice.",1,sync clarify cond created as part of other structures documentation what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users joneskoo gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do i m creating a sync cond as part of a struct what did you expect to see wait for cond until broadcast is called one second later what did you see instead panic runtime error invalid memory address or nil pointer dereference goroutine sync cond wait usr local go src sync cond go main main tmp main go there isn t an example for sync cond in the documentation and it s hardly used in the standard library should the documentation explain that the locker must be set if the cond is created as part of a structure if yes then what does this really mean a cond can be created as part of other structures a cond must not be copied after first use please update title if this turns out to be a documentation issue a simple example and where the cond might be useful would be nice ,1 69603,9310121042.0,IssuesEvent,2019-03-25 18:00:16,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: building Go distribution from source fails with ""missing $GOPATH""",Documentation NeedsFix release-blocker,"On an amd64 GNU/Linux system with no `GOPATH` set in the environment, and with the Go source code at `$HOME/go` so that the default `GOPATH` setting does not work, running make.bash fails with ``` Building Go cmd/dist using /usr/local/google/home/iant/go1.4. Building Go toolchain1 using /usr/local/google/home/iant/go1.4. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1. missing $GOPATH go tool dist: FAILED: /usr/local/google/home/iant/go/pkg/tool/linux_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 1 ```",1.0,"cmd/go: building Go distribution from source fails with ""missing $GOPATH"" - On an amd64 GNU/Linux system with no `GOPATH` set in the environment, and with the Go source code at `$HOME/go` so that the default `GOPATH` setting does not work, running make.bash fails with ``` Building Go cmd/dist using /usr/local/google/home/iant/go1.4. Building Go toolchain1 using /usr/local/google/home/iant/go1.4. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1. missing $GOPATH go tool dist: FAILED: /usr/local/google/home/iant/go/pkg/tool/linux_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 1 ```",1,cmd go building go distribution from source fails with missing gopath on an gnu linux system with no gopath set in the environment and with the go source code at home go so that the default gopath setting does not work running make bash fails with building go cmd dist using usr local google home iant building go using usr local google home iant building go bootstrap cmd go go bootstrap using go building go using go bootstrap and go missing gopath go tool dist failed usr local google home iant go pkg tool linux go bootstrap install gcflags all ldflags all i cmd asm cmd cgo cmd compile cmd link exit status ,1 16699,6262338808.0,IssuesEvent,2017-07-15 09:32:33,golang/go,https://api.github.com/repos/golang/go,opened,"cmd/dist: ""moved GOROOT"" test failing on plan9/386 builder",Builders OS-Plan9,"CL [48550](https://golang.org/cl/48550) added ""moved GOROOT"" test, which is failing on the plan9/386 builder. The plan9/386 builder is running as a buildlet on GCE, while the other builders are old-style builders. ``` ##### moved GOROOT go: cannot find GOROOT directory: /tmp/workdir/go ``` See https://build.golang.org/log/6fc6155f74eeff35e8a05ce78ab0531a4f9018bf ",1.0,"cmd/dist: ""moved GOROOT"" test failing on plan9/386 builder - CL [48550](https://golang.org/cl/48550) added ""moved GOROOT"" test, which is failing on the plan9/386 builder. The plan9/386 builder is running as a buildlet on GCE, while the other builders are old-style builders. ``` ##### moved GOROOT go: cannot find GOROOT directory: /tmp/workdir/go ``` See https://build.golang.org/log/6fc6155f74eeff35e8a05ce78ab0531a4f9018bf ",0,cmd dist moved goroot test failing on builder cl added moved goroot test which is failing on the builder the builder is running as a buildlet on gce while the other builders are old style builders moved goroot go cannot find goroot directory tmp workdir go see ,0 68394,9172201049.0,IssuesEvent,2019-03-04 06:01:37,golang/go,https://api.github.com/repos/golang/go,closed,doc: Release History doesn't mention 1.11.5,Documentation,"The release history page doesn't list the go1.11.5 minor release: https://golang.org/doc/devel/release.html#go1.11.minor However, tip.golang.org has it: https://tip.golang.org/doc/devel/release.html#go1.11.minor Does the main website need a redeploy or something? cc @dmitshur",1.0,"doc: Release History doesn't mention 1.11.5 - The release history page doesn't list the go1.11.5 minor release: https://golang.org/doc/devel/release.html#go1.11.minor However, tip.golang.org has it: https://tip.golang.org/doc/devel/release.html#go1.11.minor Does the main website need a redeploy or something? cc @dmitshur",1,doc release history doesn t mention the release history page doesn t list the minor release however tip golang org has it does the main website need a redeploy or something cc dmitshur,1 42465,6980426260.0,IssuesEvent,2017-12-13 01:38:48,golang/go,https://api.github.com/repos/golang/go,closed,doc: mention plugins working on Mac,Documentation NeedsFix release-blocker,"According to the unsubmitted https://go-review.googlesource.com/c/go/+/65670 , the plugin package now works on macOS. If that's true, it should be documented in the Go 1.10 release notes, and that CL should be submitted. /cc @rsc @ianlancetaylor @crawshaw ",1.0,"doc: mention plugins working on Mac - According to the unsubmitted https://go-review.googlesource.com/c/go/+/65670 , the plugin package now works on macOS. If that's true, it should be documented in the Go 1.10 release notes, and that CL should be submitted. /cc @rsc @ianlancetaylor @crawshaw ",1,doc mention plugins working on mac according to the unsubmitted the plugin package now works on macos if that s true it should be documented in the go release notes and that cl should be submitted cc rsc ianlancetaylor crawshaw ,1 33121,6157501553.0,IssuesEvent,2017-06-28 19:05:26,golang/go,https://api.github.com/repos/golang/go,opened,http: Document change in cookie sanitization in the release notes?,Documentation,"[This](https://github.com/golang/go/commit/8f6d68ebaa660c6db8a87d418e95f8c0d3a221e4) change to sanitizeCookieValue (to fix #18627) broke the quic-go unit tests going from 1.8 to 1.9b2. I don't know about the policy for mentioning bugfixes there, but maybe this should be mentioned in the release notes for net/http? I'd be happy to write a CL if you feel like it's worth it.",1.0,"http: Document change in cookie sanitization in the release notes? - [This](https://github.com/golang/go/commit/8f6d68ebaa660c6db8a87d418e95f8c0d3a221e4) change to sanitizeCookieValue (to fix #18627) broke the quic-go unit tests going from 1.8 to 1.9b2. I don't know about the policy for mentioning bugfixes there, but maybe this should be mentioned in the release notes for net/http? I'd be happy to write a CL if you feel like it's worth it.",1,http document change in cookie sanitization in the release notes change to sanitizecookievalue to fix broke the quic go unit tests going from to i don t know about the policy for mentioning bugfixes there but maybe this should be mentioned in the release notes for net http i d be happy to write a cl if you feel like it s worth it ,1 22061,4770831254.0,IssuesEvent,2016-10-26 16:14:27,golang/go,https://api.github.com/repos/golang/go,closed,doc: rephrase sentence about comments in Effective Go,Documentation,"In Effective Go, [Commentary](https://golang.org/doc/effective_go.html#commentary) section: > If the name always begins the comment, the output of godoc can usefully be run through grep. is better phrased as: > If comments always begin with a name, the output of godoc can usefully be run through grep. ",1.0,"doc: rephrase sentence about comments in Effective Go - In Effective Go, [Commentary](https://golang.org/doc/effective_go.html#commentary) section: > If the name always begins the comment, the output of godoc can usefully be run through grep. is better phrased as: > If comments always begin with a name, the output of godoc can usefully be run through grep. ",1,doc rephrase sentence about comments in effective go in effective go section if the name always begins the comment the output of godoc can usefully be run through grep is better phrased as if comments always begin with a name the output of godoc can usefully be run through grep ,1 318605,27317213327.0,IssuesEvent,2023-02-24 16:36:53,golang/go,https://api.github.com/repos/golang/go,reopened,runtime/pprof: TestLabelSystemstack due to sample with no location,Testing NeedsInvestigation,"``` #!watchflakes post <- pkg == ""runtime/pprof"" && test == ""TestLabelSystemstack"" ``` This one is a doozy. The failure message comes from here: https://cs.opensource.google/go/go/+/master:src/runtime/pprof/pprof_test.go;l=1535;drc=18c2033ba587ce63fc9f2d6f52b8bb2e395c561f That seems to imply that the sample was labeled but its stack was empty(!!), which does seem to be the case in the dump of collected profiles: ``` 1: labels: map[key:[value]] ``` (attn @prattmic, CC @golang/runtime) ``` --- FAIL: TestLabelSystemstack (0.32s) pprof_test.go:524: total 85 CPU profile samples collected: 1: 0x866eef (_ZN6__tsanL14MemoryRangeSetEPNS_11ThreadStateEyyyy.isra.39.part.40:0) 0x8e1ec0 (runtime._System:4432) labels: map[] 2: 0x86a6bc (_ZN6__tsan7MetaMap9FreeRangeEPNS_9ProcessorEyy:0) 0x8e1ec0 (runtime._System:4432) labels: map[key:[value]] 1: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a96ad (runtime.notewakeup:161) 0x8dce48 (runtime.startm:2324) 0x8ded1e (runtime.injectglist.func1:3076 runtime.injectglist:3100) 0x8bf5b6 (runtime.wakeScavenger:222) 0x8bf6d6 (runtime.bgscavenge.func1:268) 0x8f6d21 (runtime.runOneTimer:867) 0x8f6ad2 (runtime.runtimer:775) 0x8df2cf (runtime.checkTimers:3286) 0x8de484 (runtime.stealWork:2868) 0x8dda35 (runtime.findrunnable:2599) 0x8defd8 (runtime.schedule:3187) 0x8df52c (runtime.park_m:3336) 0x905f89 (runtime.mcall:425) labels: map[] 13: 0x907ee6 (runtime.procyield:733) 0x8a9475 (runtime.lock2:69) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x866ef7 (_ZN6__tsanL14MemoryRangeSetEPNS_11ThreadStateEyyyy.isra.39.part.40:0) 0x8e1ec0 (runtime._System:4432) labels: map[] 1: 0x8bf0d0 (runtime.(*gcControllerState).commit:1089) 0x8bf195 (runtime.(*gcControllerState).setGCPercent:1246) 0x8bf204 (runtime.setGCPercent.func1:1256) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 5: 0x8a9402 (runtime.lock2:61) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 27: 0x8d2f84 (runtime.stdcall2:1099) 0x8d204e (runtime.semasleep:819) 0x8a94f7 (runtime.lock2:89) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) labels: map[key:[value]] 4: 0x8a9419 (runtime.lock2:63) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 11: 0x8e1f00 (runtime._ExternalCode:4433) 0x8e1ec0 (runtime._System:4432) labels: map[key:[value]] 10: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a95f5 (runtime.unlock2:117) 0x8bf238 (runtime.unlockWithRank:31 runtime.unlock:97 runtime.setGCPercent.func1:1259) 0x90600d (runtime.systemstack:469) labels: map[key:[value]] 1: 0x8d3004 (runtime.stdcall3:1108) 0x8b5ba4 (runtime.sysUnused:33) 0x8c098a (runtime.(*pageAlloc).scavengeRangeLocked:775) 0x8c07cd (runtime.(*pageAlloc).scavengeOneFast:726) 0x8c0324 (runtime.(*pageAlloc).scavengeOne:637) 0x8bfcfc (runtime.(*pageAlloc).scavenge.func1:454) 0x90600d (runtime.systemstack:469) labels: map[] 3: 0x907ee4 (runtime.procyield:732) 0x8a9475 (runtime.lock2:69) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x8d2037 (runtime.semasleep:819) 0x8a94f7 (runtime.lock2:89) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0xa8de9a (runtime/pprof.labelHog:1549) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a95f5 (runtime.unlock2:117) 0x8c07e7 (runtime.unlockWithRank:31 runtime.unlock:97 runtime.(*pageAlloc).scavengeOneFast:727) 0x8c0324 (runtime.(*pageAlloc).scavengeOne:637) 0x8bfcfc (runtime.(*pageAlloc).scavenge.func1:454) 0x90600d (runtime.systemstack:469) labels: map[] 1: labels: map[key:[value]] 1: 0x89a3a8 (.text$_ZN6__tsan14DenseSlabAllocINS_10ClockBlockELy65536ELy1024EE6RefillEPNS_19DenseSlabAllocCacheE:0) 0x8e1ec0 (runtime._System:4432) labels: map[] pprof_test.go:595: runtime.systemstack;key=value: 64 pprof_test.go:1535: Sample labeled got true want false: FAIL FAIL runtime/pprof 19.664s ``` `greplogs --dashboard -md -l -e '(?ms)FAIL: TestLabelSystemstack.*Sample labeled got true want false:\s*$'` [2022-03-05T08:36:13-55a60ca/windows-amd64-race](https://build.golang.org/log/daf96d123ec840e876eb2865886e67013f1161da)",1.0,"runtime/pprof: TestLabelSystemstack due to sample with no location - ``` #!watchflakes post <- pkg == ""runtime/pprof"" && test == ""TestLabelSystemstack"" ``` This one is a doozy. The failure message comes from here: https://cs.opensource.google/go/go/+/master:src/runtime/pprof/pprof_test.go;l=1535;drc=18c2033ba587ce63fc9f2d6f52b8bb2e395c561f That seems to imply that the sample was labeled but its stack was empty(!!), which does seem to be the case in the dump of collected profiles: ``` 1: labels: map[key:[value]] ``` (attn @prattmic, CC @golang/runtime) ``` --- FAIL: TestLabelSystemstack (0.32s) pprof_test.go:524: total 85 CPU profile samples collected: 1: 0x866eef (_ZN6__tsanL14MemoryRangeSetEPNS_11ThreadStateEyyyy.isra.39.part.40:0) 0x8e1ec0 (runtime._System:4432) labels: map[] 2: 0x86a6bc (_ZN6__tsan7MetaMap9FreeRangeEPNS_9ProcessorEyy:0) 0x8e1ec0 (runtime._System:4432) labels: map[key:[value]] 1: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a96ad (runtime.notewakeup:161) 0x8dce48 (runtime.startm:2324) 0x8ded1e (runtime.injectglist.func1:3076 runtime.injectglist:3100) 0x8bf5b6 (runtime.wakeScavenger:222) 0x8bf6d6 (runtime.bgscavenge.func1:268) 0x8f6d21 (runtime.runOneTimer:867) 0x8f6ad2 (runtime.runtimer:775) 0x8df2cf (runtime.checkTimers:3286) 0x8de484 (runtime.stealWork:2868) 0x8dda35 (runtime.findrunnable:2599) 0x8defd8 (runtime.schedule:3187) 0x8df52c (runtime.park_m:3336) 0x905f89 (runtime.mcall:425) labels: map[] 13: 0x907ee6 (runtime.procyield:733) 0x8a9475 (runtime.lock2:69) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x866ef7 (_ZN6__tsanL14MemoryRangeSetEPNS_11ThreadStateEyyyy.isra.39.part.40:0) 0x8e1ec0 (runtime._System:4432) labels: map[] 1: 0x8bf0d0 (runtime.(*gcControllerState).commit:1089) 0x8bf195 (runtime.(*gcControllerState).setGCPercent:1246) 0x8bf204 (runtime.setGCPercent.func1:1256) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 5: 0x8a9402 (runtime.lock2:61) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 27: 0x8d2f84 (runtime.stdcall2:1099) 0x8d204e (runtime.semasleep:819) 0x8a94f7 (runtime.lock2:89) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) labels: map[key:[value]] 4: 0x8a9419 (runtime.lock2:63) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 11: 0x8e1f00 (runtime._ExternalCode:4433) 0x8e1ec0 (runtime._System:4432) labels: map[key:[value]] 10: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a95f5 (runtime.unlock2:117) 0x8bf238 (runtime.unlockWithRank:31 runtime.unlock:97 runtime.setGCPercent.func1:1259) 0x90600d (runtime.systemstack:469) labels: map[key:[value]] 1: 0x8d3004 (runtime.stdcall3:1108) 0x8b5ba4 (runtime.sysUnused:33) 0x8c098a (runtime.(*pageAlloc).scavengeRangeLocked:775) 0x8c07cd (runtime.(*pageAlloc).scavengeOneFast:726) 0x8c0324 (runtime.(*pageAlloc).scavengeOne:637) 0x8bfcfc (runtime.(*pageAlloc).scavenge.func1:454) 0x90600d (runtime.systemstack:469) labels: map[] 3: 0x907ee4 (runtime.procyield:732) 0x8a9475 (runtime.lock2:69) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x8d2037 (runtime.semasleep:819) 0x8a94f7 (runtime.lock2:89) 0x8bf1f1 (runtime.lockWithRank:22 runtime.lock:36 runtime.setGCPercent.func1:1255) 0x90600d (runtime.systemstack:469) 0x9020a5 (runtime/debug.setGCPercent:1254) 0xa8de99 (runtime/debug.SetGCPercent:92 runtime/pprof.labelHog:1552) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0xa8de9a (runtime/pprof.labelHog:1549) 0xa8e152 (runtime/pprof.parallelLabelHog.func1:1565) labels: map[key:[value]] 1: 0x8d2f04 (runtime.stdcall1:1090) 0x8d23a9 (runtime.semawakeup:871) 0x8a95f5 (runtime.unlock2:117) 0x8c07e7 (runtime.unlockWithRank:31 runtime.unlock:97 runtime.(*pageAlloc).scavengeOneFast:727) 0x8c0324 (runtime.(*pageAlloc).scavengeOne:637) 0x8bfcfc (runtime.(*pageAlloc).scavenge.func1:454) 0x90600d (runtime.systemstack:469) labels: map[] 1: labels: map[key:[value]] 1: 0x89a3a8 (.text$_ZN6__tsan14DenseSlabAllocINS_10ClockBlockELy65536ELy1024EE6RefillEPNS_19DenseSlabAllocCacheE:0) 0x8e1ec0 (runtime._System:4432) labels: map[] pprof_test.go:595: runtime.systemstack;key=value: 64 pprof_test.go:1535: Sample labeled got true want false: FAIL FAIL runtime/pprof 19.664s ``` `greplogs --dashboard -md -l -e '(?ms)FAIL: TestLabelSystemstack.*Sample labeled got true want false:\s*$'` [2022-03-05T08:36:13-55a60ca/windows-amd64-race](https://build.golang.org/log/daf96d123ec840e876eb2865886e67013f1161da)",0,runtime pprof testlabelsystemstack due to sample with no location watchflakes post pkg runtime pprof test testlabelsystemstack this one is a doozy the failure message comes from here that seems to imply that the sample was labeled but its stack was empty which does seem to be the case in the dump of collected profiles labels map attn prattmic cc golang runtime fail testlabelsystemstack pprof test go total cpu profile samples collected isra part runtime system labels map runtime system labels map runtime runtime semawakeup runtime notewakeup runtime startm runtime injectglist runtime injectglist runtime wakescavenger runtime bgscavenge runtime runonetimer runtime runtimer runtime checktimers runtime stealwork runtime findrunnable runtime schedule runtime park m runtime mcall labels map runtime procyield runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map isra part runtime system labels map runtime gccontrollerstate commit runtime gccontrollerstate setgcpercent runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map runtime runtime semasleep runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack labels map runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map runtime externalcode runtime system labels map runtime runtime semawakeup runtime runtime unlockwithrank runtime unlock runtime setgcpercent runtime systemstack labels map runtime runtime sysunused runtime pagealloc scavengerangelocked runtime pagealloc scavengeonefast runtime pagealloc scavengeone runtime pagealloc scavenge runtime systemstack labels map runtime procyield runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map runtime semasleep runtime runtime lockwithrank runtime lock runtime setgcpercent runtime systemstack runtime debug setgcpercent runtime debug setgcpercent runtime pprof labelhog runtime pprof parallellabelhog labels map runtime pprof labelhog runtime pprof parallellabelhog labels map runtime runtime semawakeup runtime runtime unlockwithrank runtime unlock runtime pagealloc scavengeonefast runtime pagealloc scavengeone runtime pagealloc scavenge runtime systemstack labels map labels map text runtime system labels map pprof test go runtime systemstack key value pprof test go sample labeled got true want false fail fail runtime pprof greplogs dashboard md l e ms fail testlabelsystemstack sample labeled got true want false s ,0 30224,8499160626.0,IssuesEvent,2018-10-29 16:29:21,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env/openbsd: set sysctl hw.smt=1,Builders NeedsFix OS-OpenBSD Performance,"The OpenBSD images should disable Spectre/Meltdown protections and set `sysctl hw.smt=1` per https://go-review.googlesource.com/c/build/+/144777#message-b10c10646c34b670194db8c9d72ac8a551d3ab80",1.0,"x/build/env/openbsd: set sysctl hw.smt=1 - The OpenBSD images should disable Spectre/Meltdown protections and set `sysctl hw.smt=1` per https://go-review.googlesource.com/c/build/+/144777#message-b10c10646c34b670194db8c9d72ac8a551d3ab80",0,x build env openbsd set sysctl hw smt the openbsd images should disable spectre meltdown protections and set sysctl hw smt per ,0 312849,23445610329.0,IssuesEvent,2022-08-15 19:17:30,golang/go,https://api.github.com/repos/golang/go,closed,runtime: cpu suboption for GODEBUG is not documented with the others for GODEBUG,Documentation help wanted NeedsFix compiler/runtime,"I've seen mention of using GODEBUG=cpu to disable certain cpu capabilities in various issues. I expected to find it described in runtime/extern.go where the other GODEBUG suboptions are documented, but it is not.",1.0,"runtime: cpu suboption for GODEBUG is not documented with the others for GODEBUG - I've seen mention of using GODEBUG=cpu to disable certain cpu capabilities in various issues. I expected to find it described in runtime/extern.go where the other GODEBUG suboptions are documented, but it is not.",1,runtime cpu suboption for godebug is not documented with the others for godebug i ve seen mention of using godebug cpu to disable certain cpu capabilities in various issues i expected to find it described in runtime extern go where the other godebug suboptions are documented but it is not ,1 2541,2695314347.0,IssuesEvent,2015-04-02 03:54:14,golang/go,https://api.github.com/repos/golang/go,closed,go/ast: incorrect docs for Inspect,documentation repo-main,"I am not good in Engilsh. The documents of ast.Inspect says: ``` If f returns true, Inspect invokes f for all the non-nil children of node, recursively. ``` see the play http://play.golang.org/p/HID53LSwv_ ",1.0,"go/ast: incorrect docs for Inspect - I am not good in Engilsh. The documents of ast.Inspect says: ``` If f returns true, Inspect invokes f for all the non-nil children of node, recursively. ``` see the play http://play.golang.org/p/HID53LSwv_ ",1,go ast incorrect docs for inspect i am not good in engilsh the documents of ast inspect says if f returns true inspect invokes f for all the non nil children of node recursively see the play ,1 178435,14669556632.0,IssuesEvent,2020-12-30 01:13:13,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: add autogenerated documentation for analyzers,Documentation Tools gopls,`gopls/analyzers.md` could be populated from the analyzer.Doc fields of all of the analyzers in internal/lsp/source/options.go.,1.0,x/tools/gopls: add autogenerated documentation for analyzers - `gopls/analyzers.md` could be populated from the analyzer.Doc fields of all of the analyzers in internal/lsp/source/options.go.,1,x tools gopls add autogenerated documentation for analyzers gopls analyzers md could be populated from the analyzer doc fields of all of the analyzers in internal lsp source options go ,1 304901,23089769467.0,IssuesEvent,2022-07-26 14:21:20,golang/go,https://api.github.com/repos/golang/go,closed,bytes: Reader.Size method documentation is inaccurate,Documentation NeedsFix," ### What version of Go are you using (`go version`)? Documentation issue; currently visible default version is 1.18.4 ### Does this issue reproduce with the latest release? Yes, 1.18.4 is the latest release. This doesn't seem to have been fixed as of 1.19rc2 either. ### What operating system and processor architecture are you using (`go env`)? N/A (platform-agnostic documentation issue) ### What did you do? Viewed the docs for [`Reader.Size`](https://pkg.go.dev/bytes#Reader.Size) method in `bytes` standard library package ### What did you expect to see? The [`Reader.Reset`](https://pkg.go.dev/bytes#Reader.Reset) method can change the underlying byte slice. The docs for `Size` method should say something like (changes italicized): > Size returns the original length of the underlying byte slice. Size is the number of bytes available for reading via ReadAt. The returned value _will not change between calls unless the byte slice is changed by Reset_. ### What did you see instead? The docs currently say: > Size returns the original length of the underlying byte slice. Size is the number of bytes available for reading via ReadAt. The returned value is always the same and is not affected by calls to any other method. The `Reset` method is the only violation of this wording, and it was added in Go 1.7, but the `Size` method dates back to 1.5. This minor documentation issue seems to have arisen because an assumption (immutability of the byte slice) changed between versions of the language/library.",1.0,"bytes: Reader.Size method documentation is inaccurate - ### What version of Go are you using (`go version`)? Documentation issue; currently visible default version is 1.18.4 ### Does this issue reproduce with the latest release? Yes, 1.18.4 is the latest release. This doesn't seem to have been fixed as of 1.19rc2 either. ### What operating system and processor architecture are you using (`go env`)? N/A (platform-agnostic documentation issue) ### What did you do? Viewed the docs for [`Reader.Size`](https://pkg.go.dev/bytes#Reader.Size) method in `bytes` standard library package ### What did you expect to see? The [`Reader.Reset`](https://pkg.go.dev/bytes#Reader.Reset) method can change the underlying byte slice. The docs for `Size` method should say something like (changes italicized): > Size returns the original length of the underlying byte slice. Size is the number of bytes available for reading via ReadAt. The returned value _will not change between calls unless the byte slice is changed by Reset_. ### What did you see instead? The docs currently say: > Size returns the original length of the underlying byte slice. Size is the number of bytes available for reading via ReadAt. The returned value is always the same and is not affected by calls to any other method. The `Reset` method is the only violation of this wording, and it was added in Go 1.7, but the `Size` method dates back to 1.5. This minor documentation issue seems to have arisen because an assumption (immutability of the byte slice) changed between versions of the language/library.",1,bytes reader size method documentation is inaccurate please answer these questions before submitting your issue thanks what version of go are you using go version documentation issue currently visible default version is does this issue reproduce with the latest release yes is the latest release this doesn t seem to have been fixed as of either what operating system and processor architecture are you using go env n a platform agnostic documentation issue what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best viewed the docs for method in bytes standard library package what did you expect to see the method can change the underlying byte slice the docs for size method should say something like changes italicized size returns the original length of the underlying byte slice size is the number of bytes available for reading via readat the returned value will not change between calls unless the byte slice is changed by reset what did you see instead the docs currently say size returns the original length of the underlying byte slice size is the number of bytes available for reading via readat the returned value is always the same and is not affected by calls to any other method the reset method is the only violation of this wording and it was added in go but the size method dates back to this minor documentation issue seems to have arisen because an assumption immutability of the byte slice changed between versions of the language library ,1 41030,6888053494.0,IssuesEvent,2017-11-22 03:11:26,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: Unmarshal replaces interface{} types instead of acting on the underlying type,Documentation NeedsDecision,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8.3 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ### What did you do? Unmarshal to existing `map[string]interface{}` that is hidden behind an `interface{}`: https://play.golang.org/p/kgaRznDOwb ```golang var test interface{} if err := json.Unmarshal([]byte(`{""A"": ""B""}`), &test); err != nil { panic(err) } fmt.Printf(""First:\n %+v\n"", test) if err := json.Unmarshal([]byte(`{""C"": ""D""}`), &test); err != nil { panic(err) } fmt.Printf(""Second:\n %+v\n"", test) ``` ### What did you expect to see? First: map[A:B] Second: map[A:B C:D] According to docs: > To unmarshal JSON into an interface value, Unmarshal stores one of these in the interface value: > ... > map[string]interface{}, for JSON objects > To unmarshal a JSON object into a map, Unmarshal first establishes a map to use. If the map is nil, Unmarshal allocates a new map. Otherwise Unmarshal reuses the existing map, keeping existing entries. I expect unmarshal to reuse the existing map, instead of replacing it. ### What did you see instead? First: map[A:B] Second: map[C:D] ",1.0,"encoding/json: Unmarshal replaces interface{} types instead of acting on the underlying type - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.8.3 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ### What did you do? Unmarshal to existing `map[string]interface{}` that is hidden behind an `interface{}`: https://play.golang.org/p/kgaRznDOwb ```golang var test interface{} if err := json.Unmarshal([]byte(`{""A"": ""B""}`), &test); err != nil { panic(err) } fmt.Printf(""First:\n %+v\n"", test) if err := json.Unmarshal([]byte(`{""C"": ""D""}`), &test); err != nil { panic(err) } fmt.Printf(""Second:\n %+v\n"", test) ``` ### What did you expect to see? First: map[A:B] Second: map[A:B C:D] According to docs: > To unmarshal JSON into an interface value, Unmarshal stores one of these in the interface value: > ... > map[string]interface{}, for JSON objects > To unmarshal a JSON object into a map, Unmarshal first establishes a map to use. If the map is nil, Unmarshal allocates a new map. Otherwise Unmarshal reuses the existing map, keeping existing entries. I expect unmarshal to reuse the existing map, instead of replacing it. ### What did you see instead? First: map[A:B] Second: map[C:D] ",1,encoding json unmarshal replaces interface types instead of acting on the underlying type please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin what did you do unmarshal to existing map interface that is hidden behind an interface golang var test interface if err json unmarshal byte a b test err nil panic err fmt printf first n v n test if err json unmarshal byte c d test err nil panic err fmt printf second n v n test what did you expect to see first map second map according to docs to unmarshal json into an interface value unmarshal stores one of these in the interface value map interface for json objects to unmarshal a json object into a map unmarshal first establishes a map to use if the map is nil unmarshal allocates a new map otherwise unmarshal reuses the existing map keeping existing entries i expect unmarshal to reuse the existing map instead of replacing it what did you see instead first map second map ,1 62996,8650730769.0,IssuesEvent,2018-11-26 23:43:33,golang/go,https://api.github.com/repos/golang/go,closed,doc: memclrNoHeapPointers documentation looks strange,Documentation,"https://golang.org/pkg/runtime/?m=all#memclrNoHeapPointers This comment looks strange in Chrome(70.0.3538.102) also check in safari. Seems text recognized as part of code sample.",1.0,"doc: memclrNoHeapPointers documentation looks strange - https://golang.org/pkg/runtime/?m=all#memclrNoHeapPointers This comment looks strange in Chrome(70.0.3538.102) also check in safari. Seems text recognized as part of code sample.",1,doc memclrnoheappointers documentation looks strange img width alt src this comment looks strange in chrome also check in safari seems text recognized as part of code sample ,1 173134,14403476115.0,IssuesEvent,2020-12-03 16:06:10,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document net/http changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/http

[...]

TODO: https://golang.org/cl/250039: set Content-Length:0 for empty PATCH requests as with POST, PATCH

TODO: https://golang.org/cl/249440: match http scheme when selecting http_proxy

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document net/http changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/http

[...]

TODO: https://golang.org/cl/250039: set Content-Length:0 for empty PATCH requests as with POST, PATCH

TODO: https://golang.org/cl/249440: match http scheme when selecting http_proxy

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document net http changes for go as of filing this issue the contained the following html net http todo a href set content length for empty patch requests as with post patch todo a href match http scheme when selecting http proxy per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 40840,6850459313.0,IssuesEvent,2017-11-14 03:23:08,golang/go,https://api.github.com/repos/golang/go,closed,net/http: add examples/comments for Server.Shutdown,Documentation NeedsFix release-blocker,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Go 1.8 ### What operating system and processor architecture are you using (`go env`)? amd64(windows 7 & Ubuntu 16.04) ### What did you do? https://play.golang.org/p/Akv3se9kkZ ### What did you expect to see? Go file server shutdown after download the file or timeout is reached ### What did you see instead? File server shutdown immediately This issue is related to https://github.com/golang/go/issues/19541. The Shutdown function may need some comments or examples to warn gophers to keep ListenAndServe running until it finished. Or if possible, make Shutdown communicate with ListenAndServe internally to make https://play.golang.org/p/Akv3se9kkZ works. Thanks, Andrew ",1.0,"net/http: add examples/comments for Server.Shutdown - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Go 1.8 ### What operating system and processor architecture are you using (`go env`)? amd64(windows 7 & Ubuntu 16.04) ### What did you do? https://play.golang.org/p/Akv3se9kkZ ### What did you expect to see? Go file server shutdown after download the file or timeout is reached ### What did you see instead? File server shutdown immediately This issue is related to https://github.com/golang/go/issues/19541. The Shutdown function may need some comments or examples to warn gophers to keep ListenAndServe running until it finished. Or if possible, make Shutdown communicate with ListenAndServe internally to make https://play.golang.org/p/Akv3se9kkZ works. Thanks, Andrew ",1,net http add examples comments for server shutdown please answer these questions before submitting your issue thanks what version of go are you using go version go what operating system and processor architecture are you using go env windows ubuntu what did you do what did you expect to see go file server shutdown after download the file or timeout is reached what did you see instead file server shutdown immediately this issue is related to the shutdown function may need some comments or examples to warn gophers to keep listenandserve running until it finished or if possible make shutdown communicate with listenandserve internally to make works thanks andrew ,1 39404,10336674115.0,IssuesEvent,2019-09-03 13:27:16,golang/go,https://api.github.com/repos/golang/go,opened,x/build: unclear whether we have builders for netbsd/arm64,Builders NeedsInvestigation OS-NetBSD Soon Testing new-builder,"The [Go 1.13 release notes](https://github.com/golang/go/blob/b36a7a502a590bd9fbf7f73b9678ba58028acfde/doc/go1.13.html#L154-L158) currently claim that “Go now supports OpenBSD on arm64.” We have a [`host-netbsd-arm-bsiegert` builder](https://github.com/golang/build/blob/e21f1db94c01dcb5319146b4872dd11f0ce04a1a/dashboard/builders.go#L253-L258), but it isn't clear to me whether that is regular ARM or ARM64. By last report (https://github.com/golang/go/issues/30824#issuecomment-502479334), the `netbsd/arm64` build may be broken. We should either get a `netbsd/arm64` builder up and running and verify that it is passing, or remove the claim of support from the release notes. CC @bsiegert @bradfitz @ianlancetaylor @andybons @toothrot @dmitshur ",2.0,"x/build: unclear whether we have builders for netbsd/arm64 - The [Go 1.13 release notes](https://github.com/golang/go/blob/b36a7a502a590bd9fbf7f73b9678ba58028acfde/doc/go1.13.html#L154-L158) currently claim that “Go now supports OpenBSD on arm64.” We have a [`host-netbsd-arm-bsiegert` builder](https://github.com/golang/build/blob/e21f1db94c01dcb5319146b4872dd11f0ce04a1a/dashboard/builders.go#L253-L258), but it isn't clear to me whether that is regular ARM or ARM64. By last report (https://github.com/golang/go/issues/30824#issuecomment-502479334), the `netbsd/arm64` build may be broken. We should either get a `netbsd/arm64` builder up and running and verify that it is passing, or remove the claim of support from the release notes. CC @bsiegert @bradfitz @ianlancetaylor @andybons @toothrot @dmitshur ",0,x build unclear whether we have builders for netbsd the currently claim that “go now supports openbsd on ” we have a but it isn t clear to me whether that is regular arm or by last report the netbsd build may be broken we should either get a netbsd builder up and running and verify that it is passing or remove the claim of support from the release notes cc bsiegert bradfitz ianlancetaylor andybons toothrot dmitshur ,0 53181,7809936650.0,IssuesEvent,2018-06-12 03:43:24,golang/go,https://api.github.com/repos/golang/go,closed,doc: setting GOROOT is not necessary when installing to custom location ,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? go version go1.10.1 darwin/amd64 ### Does this issue reproduce with the latest release? Yes. ### What did you do? 1. Visit https://golang.org/dl/ and download a go1.10.1 tarball 2. Install to a custom location: ``` $ cd /tmp $ tar -xzf ~/Downloads/go1.10.1.darwin-amd64.tar.gz $ go/bin/go env GOROOT /tmp/go ``` 3. Visit https://golang.org/doc/install#tarball_non_standard and see the installation instructions ### What did you expect to see? No need to set GOROOT, as it is indeed [not necessary in Go 1.10](https://golang.org/doc/go1.10#goroot). ### What did you see instead? > For example, if you installed Go to your home directory you should add commands like the following to $HOME/.profile: > > ``` > export GOROOT=$HOME/go1.X > export PATH=$PATH:$GOROOT/bin > ``` > > Note: GOROOT must be set only when installing to a custom location. --- In https://github.com/golang/go/issues/18678#issue-201154131, @minux proposed to derive GOROOT from `os.Executable`... > And then we can eliminate all mentions of GOROOT in user facing documents (in fact, we should actively discourage setting GOROOT in user facing documents.) The change was implemented in [CL 42533](https://go-review.googlesource.com/42533), but the documentation was not updated to remove suggestions to set GOROOT.",1.0,"doc: setting GOROOT is not necessary when installing to custom location - ### What version of Go are you using (`go version`)? go version go1.10.1 darwin/amd64 ### Does this issue reproduce with the latest release? Yes. ### What did you do? 1. Visit https://golang.org/dl/ and download a go1.10.1 tarball 2. Install to a custom location: ``` $ cd /tmp $ tar -xzf ~/Downloads/go1.10.1.darwin-amd64.tar.gz $ go/bin/go env GOROOT /tmp/go ``` 3. Visit https://golang.org/doc/install#tarball_non_standard and see the installation instructions ### What did you expect to see? No need to set GOROOT, as it is indeed [not necessary in Go 1.10](https://golang.org/doc/go1.10#goroot). ### What did you see instead? > For example, if you installed Go to your home directory you should add commands like the following to $HOME/.profile: > > ``` > export GOROOT=$HOME/go1.X > export PATH=$PATH:$GOROOT/bin > ``` > > Note: GOROOT must be set only when installing to a custom location. --- In https://github.com/golang/go/issues/18678#issue-201154131, @minux proposed to derive GOROOT from `os.Executable`... > And then we can eliminate all mentions of GOROOT in user facing documents (in fact, we should actively discourage setting GOROOT in user facing documents.) The change was implemented in [CL 42533](https://go-review.googlesource.com/42533), but the documentation was not updated to remove suggestions to set GOROOT.",1,doc setting goroot is not necessary when installing to custom location what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what did you do visit and download a tarball install to a custom location cd tmp tar xzf downloads darwin tar gz go bin go env goroot tmp go visit and see the installation instructions what did you expect to see no need to set goroot as it is indeed what did you see instead for example if you installed go to your home directory you should add commands like the following to home profile export goroot home x export path path goroot bin note goroot must be set only when installing to a custom location in minux proposed to derive goroot from os executable and then we can eliminate all mentions of goroot in user facing documents in fact we should actively discourage setting goroot in user facing documents the change was implemented in but the documentation was not updated to remove suggestions to set goroot ,1 41296,10696854119.0,IssuesEvent,2019-10-23 15:25:41,golang/go,https://api.github.com/repos/golang/go,closed,x/build: mac builders down,Builders NeedsFix,"All Mac builders are currently down, as reported at https://farmer.golang.org/#health: ![image](https://user-images.githubusercontent.com/1924134/67395969-d3352e00-f574-11e9-8b97-b005e9781236.png) This is due to an issue at our Mac provider. They've notified us about the issue and that it should be resolved on their side by now, but it's been many hours and the Mac builders haven't returned yet. /cc @bradfitz @toothrot @cagedmantis",1.0,"x/build: mac builders down - All Mac builders are currently down, as reported at https://farmer.golang.org/#health: ![image](https://user-images.githubusercontent.com/1924134/67395969-d3352e00-f574-11e9-8b97-b005e9781236.png) This is due to an issue at our Mac provider. They've notified us about the issue and that it should be resolved on their side by now, but it's been many hours and the Mac builders haven't returned yet. /cc @bradfitz @toothrot @cagedmantis",0,x build mac builders down all mac builders are currently down as reported at this is due to an issue at our mac provider they ve notified us about the issue and that it should be resolved on their side by now but it s been many hours and the mac builders haven t returned yet cc bradfitz toothrot cagedmantis,0 23517,4954485616.0,IssuesEvent,2016-12-01 17:42:42,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document Request.Context's lifetime again,Documentation,"It was originally documented as closing when the peer closed for Go 1.7, but then we removed that part of the docs when the implementation wasn't complete. The implementation is complete in Go 1.8, so we need to add the docs back. ",1.0,"net/http: document Request.Context's lifetime again - It was originally documented as closing when the peer closed for Go 1.7, but then we removed that part of the docs when the implementation wasn't complete. The implementation is complete in Go 1.8, so we need to add the docs back. ",1,net http document request context s lifetime again it was originally documented as closing when the peer closed for go but then we removed that part of the docs when the implementation wasn t complete the implementation is complete in go so we need to add the docs back ,1 81029,10220995730.0,IssuesEvent,2019-08-15 23:26:13,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: propagate hoverKind to completion,Documentation gopls,"As per #32561 atm, there is a configuration to provide full docs on hover: ``` ""gopls"": { ""hoverKind"": ""FullDocumentation"", } ``` However it's not the case when we want docs on completion: ``` ""gopls"": { ""wantCompletionDocumentation"": true, } ``` Please make completion return full docs when `FullDocumentation` option is set or add another config for completion. ",1.0,"x/tools/gopls: propagate hoverKind to completion - As per #32561 atm, there is a configuration to provide full docs on hover: ``` ""gopls"": { ""hoverKind"": ""FullDocumentation"", } ``` However it's not the case when we want docs on completion: ``` ""gopls"": { ""wantCompletionDocumentation"": true, } ``` Please make completion return full docs when `FullDocumentation` option is set or add another config for completion. ",1,x tools gopls propagate hoverkind to completion as per atm there is a configuration to provide full docs on hover gopls hoverkind fulldocumentation however it s not the case when we want docs on completion gopls wantcompletiondocumentation true please make completion return full docs when fulldocumentation option is set or add another config for completion ,1 91854,10730196170.0,IssuesEvent,2019-10-28 16:57:15,golang/go,https://api.github.com/repos/golang/go,closed,proposal: doc: document that Go 1.14 is last to support darwin/arm (32bit version)?,Documentation Proposal mobile,"iOS 13 (and iPadOS 13) does not support running 32-bit apps. iOS 10 was the last version that supported 32-bit apps (with very visible warnings), and it's 3 years old. Is it time to remove `darwin/arm` (leaving just `darwin/arm64`)? If so, the first step would be to document that Go 1.14 will be the final release with `darwin/arm` support. Related to #34749. /cc @bradfitz @hyangah @eliasnaur",1.0,"proposal: doc: document that Go 1.14 is last to support darwin/arm (32bit version)? - iOS 13 (and iPadOS 13) does not support running 32-bit apps. iOS 10 was the last version that supported 32-bit apps (with very visible warnings), and it's 3 years old. Is it time to remove `darwin/arm` (leaving just `darwin/arm64`)? If so, the first step would be to document that Go 1.14 will be the final release with `darwin/arm` support. Related to #34749. /cc @bradfitz @hyangah @eliasnaur",1,proposal doc document that go is last to support darwin arm version ios and ipados does not support running bit apps ios was the last version that supported bit apps with very visible warnings and it s years old is it time to remove darwin arm leaving just darwin if so the first step would be to document that go will be the final release with darwin arm support related to cc bradfitz hyangah eliasnaur,1 56043,8047514722.0,IssuesEvent,2018-08-01 01:10:31,golang/go,https://api.github.com/repos/golang/go,closed,strconv: FormatFloat handles prec differently from the doc with fmt='g',Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? go version go1.10.1 linux/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" ### What did you do? `fmt.Println(strconv.FormatFloat(1.5, 'g', 6, 64))` https://play.golang.org/p/WRHc89mjuSG ### What did you expect to see? `1.50000` https://golang.org/pkg/strconv/#FormatFloat says: > The precision prec controls the number of digits […]. For 'g' and 'G' it is the total number of digits. I gave `prec=6`, so the total number of digits should be 6. ### What did you see instead? `1.5` The total number of digits is 2.",1.0,"strconv: FormatFloat handles prec differently from the doc with fmt='g' - ### What version of Go are you using (`go version`)? go version go1.10.1 linux/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" ### What did you do? `fmt.Println(strconv.FormatFloat(1.5, 'g', 6, 64))` https://play.golang.org/p/WRHc89mjuSG ### What did you expect to see? `1.50000` https://golang.org/pkg/strconv/#FormatFloat says: > The precision prec controls the number of digits […]. For 'g' and 'G' it is the total number of digits. I gave `prec=6`, so the total number of digits should be 6. ### What did you see instead? `1.5` The total number of digits is 2.",1,strconv formatfloat handles prec differently from the doc with fmt g what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gohostarch gohostos linux goos linux what did you do fmt println strconv formatfloat g what did you expect to see says the precision prec controls the number of digits for g and g it is the total number of digits i gave prec so the total number of digits should be what did you see instead the total number of digits is ,1 20311,4536254747.0,IssuesEvent,2016-09-08 19:51:20,golang/go,https://api.github.com/repos/golang/go,closed,encoding/hex: Suggestions for doc improvements,Documentation,"Quoting from https://groups.google.com/d/msg/golang-nuts/eV3uNlEFPrc/KeHIjyN2oVEJ (not all of this is appropriate in my opinion, but it is useful information from a Go newbie): Now, let's look at a specific package, e.g. https://golang.org/pkg/encoding/hex/ Already, we can see there are no examples here, making it tough for a newcomer to follow along with. For example, it's not clear that the functions that are listed here need to be prefixed with the ""hex."" prefix. Yes, that's a simple language thing, but if it's not re-enforced in the documentation with a few examples, it takes that much longer to learn. Consider this (BAD/CONFUSING): var ErrLength = errors.New(""encoding/hex: odd length hex string"") What is that? My first assumption is that this is some type of package variable because it's under the ""Variables"" heading. It's only by comparing this to other packages that I can guess that this is a reference to a particular error message. But without an example to see how it might arise, I have no idea what to do with this info or what exactly it pertains to. BETTER: include an example of working with the returned variables to see how/why they might be relevant or omit this entirely and just list the message strings. BAD: func Dumper This ""crosses the beams"" by referencing another package: ""io"". Without an example to work off of, it's not clear how one might instantiate an io.Writer or what might be done with an io.WriteCloser. We end up banging our heads on a different wall over at the ""io"" docs. BETTER: include an example here so we aren't on a wild goose chase to figure out how to instantiate io.Writer objects. BAD: func DecodeString Again, no example, so immediately I have to pay the toll of fiddling with this to see how it works. Perhaps an example like this: bytes, _ := hex.DecodeString(""AE"") fmt.Println(hex.EncodeToString(bytes)) // ae (lowercase) It might be worth mentioning that the output is always lowercase, and it would be good to explain the behavior that pops up if your input is out of range, e.g. ""XX"". This is why it would be useful to describe the parameters and output in their own dedicated sections. BAD: func Decode The explanation includes ""Decode decodes src into DecodedLen(len(src)) bytes"" -- nesting like that is more concise, but it's harder to follow. I'm not entirely sure I understand what this function does. Again, an example would help clarify this more than paragraphs of text. BETTER: ???",1.0,"encoding/hex: Suggestions for doc improvements - Quoting from https://groups.google.com/d/msg/golang-nuts/eV3uNlEFPrc/KeHIjyN2oVEJ (not all of this is appropriate in my opinion, but it is useful information from a Go newbie): Now, let's look at a specific package, e.g. https://golang.org/pkg/encoding/hex/ Already, we can see there are no examples here, making it tough for a newcomer to follow along with. For example, it's not clear that the functions that are listed here need to be prefixed with the ""hex."" prefix. Yes, that's a simple language thing, but if it's not re-enforced in the documentation with a few examples, it takes that much longer to learn. Consider this (BAD/CONFUSING): var ErrLength = errors.New(""encoding/hex: odd length hex string"") What is that? My first assumption is that this is some type of package variable because it's under the ""Variables"" heading. It's only by comparing this to other packages that I can guess that this is a reference to a particular error message. But without an example to see how it might arise, I have no idea what to do with this info or what exactly it pertains to. BETTER: include an example of working with the returned variables to see how/why they might be relevant or omit this entirely and just list the message strings. BAD: func Dumper This ""crosses the beams"" by referencing another package: ""io"". Without an example to work off of, it's not clear how one might instantiate an io.Writer or what might be done with an io.WriteCloser. We end up banging our heads on a different wall over at the ""io"" docs. BETTER: include an example here so we aren't on a wild goose chase to figure out how to instantiate io.Writer objects. BAD: func DecodeString Again, no example, so immediately I have to pay the toll of fiddling with this to see how it works. Perhaps an example like this: bytes, _ := hex.DecodeString(""AE"") fmt.Println(hex.EncodeToString(bytes)) // ae (lowercase) It might be worth mentioning that the output is always lowercase, and it would be good to explain the behavior that pops up if your input is out of range, e.g. ""XX"". This is why it would be useful to describe the parameters and output in their own dedicated sections. BAD: func Decode The explanation includes ""Decode decodes src into DecodedLen(len(src)) bytes"" -- nesting like that is more concise, but it's harder to follow. I'm not entirely sure I understand what this function does. Again, an example would help clarify this more than paragraphs of text. BETTER: ???",1,encoding hex suggestions for doc improvements quoting from not all of this is appropriate in my opinion but it is useful information from a go newbie now let s look at a specific package e g already we can see there are no examples here making it tough for a newcomer to follow along with for example it s not clear that the functions that are listed here need to be prefixed with the hex prefix yes that s a simple language thing but if it s not re enforced in the documentation with a few examples it takes that much longer to learn consider this bad confusing var errlength errors new encoding hex odd length hex string what is that my first assumption is that this is some type of package variable because it s under the variables heading it s only by comparing this to other packages that i can guess that this is a reference to a particular error message but without an example to see how it might arise i have no idea what to do with this info or what exactly it pertains to better include an example of working with the returned variables to see how why they might be relevant or omit this entirely and just list the message strings bad func dumper this crosses the beams by referencing another package io without an example to work off of it s not clear how one might instantiate an io writer or what might be done with an io writecloser we end up banging our heads on a different wall over at the io docs better include an example here so we aren t on a wild goose chase to figure out how to instantiate io writer objects bad func decodestring again no example so immediately i have to pay the toll of fiddling with this to see how it works perhaps an example like this bytes hex decodestring ae fmt println hex encodetostring bytes ae lowercase it might be worth mentioning that the output is always lowercase and it would be good to explain the behavior that pops up if your input is out of range e g xx this is why it would be useful to describe the parameters and output in their own dedicated sections bad func decode the explanation includes decode decodes src into decodedlen len src bytes nesting like that is more concise but it s harder to follow i m not entirely sure i understand what this function does again an example would help clarify this more than paragraphs of text better ,1 11065,3455708026.0,IssuesEvent,2015-12-17 21:22:05,golang/go,https://api.github.com/repos/golang/go,closed,"net/http: data race reading a ""Expect: 100-Continue"" request while writing response",Documentation,"The goroutine reading the request body will be updating ""ecr.sawEOF"", while the goroutine writing the response will be reading that boolean with no synchronization. Using `go1.5.1 windows/amd64`. ``` WARNING: DATA RACE Read by goroutine 438: net/http.(*chunkWriter).writeHeader() C:/workdir/go/src/net/http/server.go:866 +0xe38 net/http.(*chunkWriter).Write() C:/workdir/go/src/net/http/server.go:261 +0xbf bufio.(*Writer).Write() C:/workdir/go/src/bufio/bufio.go:594 +0x17b net/http.(*response).write() C:/workdir/go/src/net/http/server.go:1140 +0x316 net/http.(*response).Write() C:/workdir/go/src/net/http/server.go:1112 +0x7f (...app...) Previous write by goroutine 870: net/http.(*expectContinueReader).Read() C:/workdir/go/src/net/http/server.go:571 +0x351 (...app...) ```",1.0,"net/http: data race reading a ""Expect: 100-Continue"" request while writing response - The goroutine reading the request body will be updating ""ecr.sawEOF"", while the goroutine writing the response will be reading that boolean with no synchronization. Using `go1.5.1 windows/amd64`. ``` WARNING: DATA RACE Read by goroutine 438: net/http.(*chunkWriter).writeHeader() C:/workdir/go/src/net/http/server.go:866 +0xe38 net/http.(*chunkWriter).Write() C:/workdir/go/src/net/http/server.go:261 +0xbf bufio.(*Writer).Write() C:/workdir/go/src/bufio/bufio.go:594 +0x17b net/http.(*response).write() C:/workdir/go/src/net/http/server.go:1140 +0x316 net/http.(*response).Write() C:/workdir/go/src/net/http/server.go:1112 +0x7f (...app...) Previous write by goroutine 870: net/http.(*expectContinueReader).Read() C:/workdir/go/src/net/http/server.go:571 +0x351 (...app...) ```",1,net http data race reading a expect continue request while writing response the goroutine reading the request body will be updating ecr saweof while the goroutine writing the response will be reading that boolean with no synchronization using windows warning data race read by goroutine net http chunkwriter writeheader c workdir go src net http server go net http chunkwriter write c workdir go src net http server go bufio writer write c workdir go src bufio bufio go net http response write c workdir go src net http server go net http response write c workdir go src net http server go app previous write by goroutine net http expectcontinuereader read c workdir go src net http server go app ,1 51111,6147754305.0,IssuesEvent,2017-06-27 16:19:50,golang/go,https://api.github.com/repos/golang/go,reopened,cmd/go: TestExecutableGOROOT fails if GOROOT_FINAL is set,NeedsFix Testing,"### What version of Go are you using (`go version`)? $ ../bin/go version go version devel +88672de Mon May 8 19:52:30 2017 +0000 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? linux/amd64 but it doesn't really matter here. ### What did you do? $ GOROOT_FINAL=/foobar ./all.bash ### What did you expect to see? Tests passing. ### What did you see instead? --- FAIL: TestExecutableGOROOT (0.05s) go_test.go:3974: copied go tool failed exit status 2: go: cannot find GOROOT directory: /foobar FAIL FAIL cmd/go 51.515s I think this is the {{{ // Missing GOROOT/pkg/tool, the go tool should fall back to // its default path. }}} case from the test. The nature of the failure makes me wonder if it is really testing what it thinks it's failing though. cc @crawshaw ",1.0,"cmd/go: TestExecutableGOROOT fails if GOROOT_FINAL is set - ### What version of Go are you using (`go version`)? $ ../bin/go version go version devel +88672de Mon May 8 19:52:30 2017 +0000 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? linux/amd64 but it doesn't really matter here. ### What did you do? $ GOROOT_FINAL=/foobar ./all.bash ### What did you expect to see? Tests passing. ### What did you see instead? --- FAIL: TestExecutableGOROOT (0.05s) go_test.go:3974: copied go tool failed exit status 2: go: cannot find GOROOT directory: /foobar FAIL FAIL cmd/go 51.515s I think this is the {{{ // Missing GOROOT/pkg/tool, the go tool should fall back to // its default path. }}} case from the test. The nature of the failure makes me wonder if it is really testing what it thinks it's failing though. cc @crawshaw ",0,cmd go testexecutablegoroot fails if goroot final is set what version of go are you using go version bin go version go version devel mon may linux what operating system and processor architecture are you using go env linux but it doesn t really matter here what did you do goroot final foobar all bash what did you expect to see tests passing what did you see instead fail testexecutablegoroot go test go copied go tool failed exit status go cannot find goroot directory foobar fail fail cmd go i think this is the missing goroot pkg tool the go tool should fall back to its default path case from the test the nature of the failure makes me wonder if it is really testing what it thinks it s failing though cc crawshaw ,0 370178,25892540986.0,IssuesEvent,2022-12-14 19:14:24,golang/go,https://api.github.com/repos/golang/go,closed,spec: document new behavior for `comparable`,Documentation,Reminder issue to document the spec change for #56548.,1.0,spec: document new behavior for `comparable` - Reminder issue to document the spec change for #56548.,1,spec document new behavior for comparable reminder issue to document the spec change for ,1 108611,11596596900.0,IssuesEvent,2020-02-24 19:15:53,golang/go,https://api.github.com/repos/golang/go,closed,doc: write Go 1.14 release notes,Documentation NeedsFix help wanted release-blocker,"Tracking bug for writing the Go 1.14 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.14. Previously #17929, #15810, #5929, etc.",1.0,"doc: write Go 1.14 release notes - Tracking bug for writing the Go 1.14 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.14. Previously #17929, #15810, #5929, etc.",1,doc write go release notes tracking bug for writing the go release notes the latest state on tip can be viewed at previously etc ,1 50425,7603623484.0,IssuesEvent,2018-04-29 16:24:49,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: improve the help message of go tool compile -d ssa/help,Documentation NeedsFix,"I noticed it was somewhat difficult to read the ssa/help output: ``` $ go tool compile -d ssa/help compile: GcFlag -d=ssa//[=]|[:] is one of: check, all, build, intrinsics, early_phielim, early_copyelim early_deadcode, short_circuit, decompose_user, opt, zero_arg_cse opt_deadcode, generic_cse, phiopt, nilcheckelim, prove, loopbce decompose_builtin, dec, late_opt, generic_deadcode, check_bce writebarrier, fuse, dse, insert_resched_checks, tighten, lower lowered_cse, lowered_deadcode, checkLower, late_phielim, late_copyelim phi_tighten, late_deadcode, critical, likelyadjust, layout, schedule late_nilcheck, flagalloc, regalloc, stackframe, trim is one of on, off, debug, mem, time, test, stats, dump defaults to 1 is required for ""dump"", specifies name of function to dump after Except for dump, output is directed to standard out; dump appears in a file. Phase ""all"" supports flags ""time"", ""mem"", and ""dump"". Phases ""intrinsics"" supports flags ""on"", ""off"", and ""debug"". Interpretation of the ""debug"" value depends on the phase. Dump files are named ___.dump. ``` With a few tweaks here and there it looks more pleasing to the eye: ``` $ go tool compile -d ssa/help compile: usage: -d=ssa//[=|] is one of: check, all, build, intrinsics, early_phielim, early_copyelim, early_deadcode short_circuit, decompose_user, opt, zero_arg_cse, opt_deadcode, generic_cse phiopt, nilcheckelim, prove, loopbce, decompose_builtin, dec, late_opt generic_deadcode, check_bce, writebarrier, fuse, dse, insert_resched_checks tighten, lower, lowered_cse, lowered_deadcode, checkLower, late_phielim late_copyelim, phi_tighten, late_deadcode, critical, likelyadjust, layout schedule, late_nilcheck, flagalloc, regalloc, stackframe, trim is one of on, off, debug, mem, time, test, stats, dump. Phase all supports flags time, mem, and dump. Phase intrinsics supports flags on, off, and debug. defaults to 1. is required for dump, specifies name of function to dump after . Except for dump, output is directed to standard out; dump appears in a file. Dump files are named ___.dump. ```",1.0,"cmd/compile: improve the help message of go tool compile -d ssa/help - I noticed it was somewhat difficult to read the ssa/help output: ``` $ go tool compile -d ssa/help compile: GcFlag -d=ssa//[=]|[:] is one of: check, all, build, intrinsics, early_phielim, early_copyelim early_deadcode, short_circuit, decompose_user, opt, zero_arg_cse opt_deadcode, generic_cse, phiopt, nilcheckelim, prove, loopbce decompose_builtin, dec, late_opt, generic_deadcode, check_bce writebarrier, fuse, dse, insert_resched_checks, tighten, lower lowered_cse, lowered_deadcode, checkLower, late_phielim, late_copyelim phi_tighten, late_deadcode, critical, likelyadjust, layout, schedule late_nilcheck, flagalloc, regalloc, stackframe, trim is one of on, off, debug, mem, time, test, stats, dump defaults to 1 is required for ""dump"", specifies name of function to dump after Except for dump, output is directed to standard out; dump appears in a file. Phase ""all"" supports flags ""time"", ""mem"", and ""dump"". Phases ""intrinsics"" supports flags ""on"", ""off"", and ""debug"". Interpretation of the ""debug"" value depends on the phase. Dump files are named ___.dump. ``` With a few tweaks here and there it looks more pleasing to the eye: ``` $ go tool compile -d ssa/help compile: usage: -d=ssa//[=|] is one of: check, all, build, intrinsics, early_phielim, early_copyelim, early_deadcode short_circuit, decompose_user, opt, zero_arg_cse, opt_deadcode, generic_cse phiopt, nilcheckelim, prove, loopbce, decompose_builtin, dec, late_opt generic_deadcode, check_bce, writebarrier, fuse, dse, insert_resched_checks tighten, lower, lowered_cse, lowered_deadcode, checkLower, late_phielim late_copyelim, phi_tighten, late_deadcode, critical, likelyadjust, layout schedule, late_nilcheck, flagalloc, regalloc, stackframe, trim is one of on, off, debug, mem, time, test, stats, dump. Phase all supports flags time, mem, and dump. Phase intrinsics supports flags on, off, and debug. defaults to 1. is required for dump, specifies name of function to dump after . Except for dump, output is directed to standard out; dump appears in a file. Dump files are named ___.dump. ```",1,cmd compile improve the help message of go tool compile d ssa help i noticed it was somewhat difficult to read the ssa help output go tool compile d ssa help compile gcflag d ssa is one of check all build intrinsics early phielim early copyelim early deadcode short circuit decompose user opt zero arg cse opt deadcode generic cse phiopt nilcheckelim prove loopbce decompose builtin dec late opt generic deadcode check bce writebarrier fuse dse insert resched checks tighten lower lowered cse lowered deadcode checklower late phielim late copyelim phi tighten late deadcode critical likelyadjust layout schedule late nilcheck flagalloc regalloc stackframe trim is one of on off debug mem time test stats dump defaults to is required for dump specifies name of function to dump after except for dump output is directed to standard out dump appears in a file phase all supports flags time mem and dump phases intrinsics supports flags on off and debug interpretation of the debug value depends on the phase dump files are named dump with a few tweaks here and there it looks more pleasing to the eye go tool compile d ssa help compile usage d ssa is one of check all build intrinsics early phielim early copyelim early deadcode short circuit decompose user opt zero arg cse opt deadcode generic cse phiopt nilcheckelim prove loopbce decompose builtin dec late opt generic deadcode check bce writebarrier fuse dse insert resched checks tighten lower lowered cse lowered deadcode checklower late phielim late copyelim phi tighten late deadcode critical likelyadjust layout schedule late nilcheck flagalloc regalloc stackframe trim is one of on off debug mem time test stats dump phase all supports flags time mem and dump phase intrinsics supports flags on off and debug defaults to is required for dump specifies name of function to dump after except for dump output is directed to standard out dump appears in a file dump files are named dump ,1 7072,3077653295.0,IssuesEvent,2015-08-21 02:42:23,golang/go,https://api.github.com/repos/golang/go,closed,encoding/base64: documentation typo,Documentation,"In the docs for the base64 package in the [variables](http://golang.org/pkg/encoding/base64/#URLEncoding) section there is a typo. The description under `var RawURLEncoding = URLEncoding.WithPadding(NoPadding)` uses `URLEncoding` to describe the above variable when it should be using `RawURLEncoding`.",1.0,"encoding/base64: documentation typo - In the docs for the base64 package in the [variables](http://golang.org/pkg/encoding/base64/#URLEncoding) section there is a typo. The description under `var RawURLEncoding = URLEncoding.WithPadding(NoPadding)` uses `URLEncoding` to describe the above variable when it should be using `RawURLEncoding`.",1,encoding documentation typo in the docs for the package in the section there is a typo the description under var rawurlencoding urlencoding withpadding nopadding uses urlencoding to describe the above variable when it should be using rawurlencoding ,1 34302,9331423524.0,IssuesEvent,2019-03-28 09:43:36,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env/android: gomote debugging with Android builders is painful,Builders Documentation,"@griesemer discovered that using gomote to debug things on Android is painful. We should have a wiki page with some example sessions, including how to build the exec wrapper, and how to run go tests. ",1.0,"x/build/env/android: gomote debugging with Android builders is painful - @griesemer discovered that using gomote to debug things on Android is painful. We should have a wiki page with some example sessions, including how to build the exec wrapper, and how to run go tests. ",0,x build env android gomote debugging with android builders is painful griesemer discovered that using gomote to debug things on android is painful we should have a wiki page with some example sessions including how to build the exec wrapper and how to run go tests ,0 154672,13563689433.0,IssuesEvent,2020-09-18 08:55:44,golang/go,https://api.github.com/repos/golang/go,closed,"""func (*Resolver) LookupIP"" seems not exists, but it is in the documentation",Documentation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.6 darwin/amd64
### Does this issue reproduce with the latest release? 
package main
import ""context""
import ""net""
func GoogleDNSDialer(ctx context.Context, network, address string) (net.Conn, error) {
   d := net.Dialer{}
   return d.DialContext(ctx, ""udp"", ""8.8.8.8:53"")
}
var local_resolver net.Resolver = net.Resolver{
   Dial: GoogleDNSDialer,
}
func LocalLookupIP(name string) ([]net.IP, error) {
   return local_resolver.LookupIP(context.Background(), ""ip"", name)
}

go build
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/thierryfournier/Library/Caches/go-build""
GOENV=""/Users/thierryfournier/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/thierryfournier/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=""""
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/_d/zs7l5ldx1r94fn_qh1zvn1rw0000gn/T/go-build235743352=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Compilation error is: ./a.go:12:25: local_resolver.LookupIP undefined (type net.Resolver has no field or method LookupIP) But the documentation says that the function ""func (*Resolver) LookupIP"" exists: https://godoc.org/net#Resolver.LookupIP I check the file ""/usr/local/go/src/net/lookup.go"" and the function doesn't exists ### What did you expect to see? My build works (or fix the documentation). ### What did you see instead? ",1.0,"""func (*Resolver) LookupIP"" seems not exists, but it is in the documentation - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.6 darwin/amd64
### Does this issue reproduce with the latest release? 
package main
import ""context""
import ""net""
func GoogleDNSDialer(ctx context.Context, network, address string) (net.Conn, error) {
   d := net.Dialer{}
   return d.DialContext(ctx, ""udp"", ""8.8.8.8:53"")
}
var local_resolver net.Resolver = net.Resolver{
   Dial: GoogleDNSDialer,
}
func LocalLookupIP(name string) ([]net.IP, error) {
   return local_resolver.LookupIP(context.Background(), ""ip"", name)
}

go build
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/thierryfournier/Library/Caches/go-build""
GOENV=""/Users/thierryfournier/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/thierryfournier/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=""""
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/_d/zs7l5ldx1r94fn_qh1zvn1rw0000gn/T/go-build235743352=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Compilation error is: ./a.go:12:25: local_resolver.LookupIP undefined (type net.Resolver has no field or method LookupIP) But the documentation says that the function ""func (*Resolver) LookupIP"" exists: https://godoc.org/net#Resolver.LookupIP I check the file ""/usr/local/go/src/net/lookup.go"" and the function doesn't exists ### What did you expect to see? My build works (or fix the documentation). ### What did you see instead? ",1, func resolver lookupip seems not exists but it is in the documentation what version of go are you using go version go version go version darwin does this issue reproduce with the latest release package main import context import net func googlednsdialer ctx context context network address string net conn error d net dialer return d dialcontext ctx udp var local resolver net resolver net resolver dial googlednsdialer func locallookupip name string net ip error return local resolver lookupip context background ip name go build what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users thierryfournier library caches go build goenv users thierryfournier library application support go env goexe goflags gohostarch gohostos darwin goinsecure gonoproxy gonosumdb goos darwin gopath users thierryfournier go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders d t go tmp go build gno record gcc switches fno common what did you do compilation error is a go local resolver lookupip undefined type net resolver has no field or method lookupip but the documentation says that the function func resolver lookupip exists i check the file usr local go src net lookup go and the function doesn t exists what did you expect to see my build works or fix the documentation what did you see instead ,1 20582,10820571886.0,IssuesEvent,2019-11-08 16:39:52,golang/go,https://api.github.com/repos/golang/go,closed,cmd/internal/obj/x86: add fma,FeatureRequest NeedsFix Performance Thinking help wanted,"by **odysseus9672**: 
What does 'go version' print?
go version devel +5b9ac653acf6 Mon May 19 22:57:59 2014 -0400 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Go to $GOROOT/src/cmd/6l/6.out.h
2. According to http://golang.org/doc/asm#architectures , this file contains a list of
all the assembler instructions Go recognizes.
3. No fused-multiply-add instructions are in the list.

Please provide any additional information below.

Using FMA allows for several faster and more accurate versions of several algorithms. My
current main use case is polynomial evaluation (Horner's scheme and Estrin's scheme are
both built on FMA), but another very important one is matrix multiplication. Adding at
least a subset of the FMA instructions available on newer AMD and Intel CPUs (available
on PowerPC since at least the 600 series) would improve the ability of performance
minded coders and compiler optimization writers to make faster running code. 

For instance, a more accurate version of the update in the Mandelbrot set is:
if the starting point is Cr + i*Ci (and halfCi = 0.5 * Ci)
Zr, Zi = fma( Zr - Zi, Zr + Zi, Cr ), 2 * fma( Zr, Zi, halfCi )

The update to Zr is likely slower than what is presently done for the The Computer
Language Benchmarks Game, but an fma based update to Zi would definitely speed things up.

Granted, the speedup would only materialize when issue #4978 (
https://golang.org/issue/4978 ) is resolved, but having code in
useful libraries in place to take advantage of that optimization would be nice instead
of having to recode everything afterwords.

To that end, I would request exposing at least the following (would do it myself if I
could find an understandable listing of the opcodes and documentation on how to add them
to the compiler): 

For greatest compatibility with AMD chips, 4 operand forms ( from
http://en.wikipedia.org/wiki/X86_instruction_listings#FMA_instructions ): 
VFMADDPD, VFMADDPS, VFMADDSD, VFMADDSS.

And for Intel chips, the 3 operand forms ( from Vol. 1 14-21 of Intel's developer's
manual:
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html?iid=tech_vt_tech+64-32_manuals
):
VFMADD231PD, VFMADD231PS, VFMADD231SD, VFMADD231SS

All of the other operations are permutations of minus signs applied to these (and which
register gets clobbered for the 3 op version - the one I'm requesting is the one that
works best with polynomial evaluation, naturally). 

Solving this issue would also make issue #681 more straightforward (
https://golang.org/issue/681 ), although even having the opcodes
would be enough for that one.
",True,"cmd/internal/obj/x86: add fma - by **odysseus9672**: 
What does 'go version' print?
go version devel +5b9ac653acf6 Mon May 19 22:57:59 2014 -0400 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Go to $GOROOT/src/cmd/6l/6.out.h
2. According to http://golang.org/doc/asm#architectures , this file contains a list of
all the assembler instructions Go recognizes.
3. No fused-multiply-add instructions are in the list.

Please provide any additional information below.

Using FMA allows for several faster and more accurate versions of several algorithms. My
current main use case is polynomial evaluation (Horner's scheme and Estrin's scheme are
both built on FMA), but another very important one is matrix multiplication. Adding at
least a subset of the FMA instructions available on newer AMD and Intel CPUs (available
on PowerPC since at least the 600 series) would improve the ability of performance
minded coders and compiler optimization writers to make faster running code. 

For instance, a more accurate version of the update in the Mandelbrot set is:
if the starting point is Cr + i*Ci (and halfCi = 0.5 * Ci)
Zr, Zi = fma( Zr - Zi, Zr + Zi, Cr ), 2 * fma( Zr, Zi, halfCi )

The update to Zr is likely slower than what is presently done for the The Computer
Language Benchmarks Game, but an fma based update to Zi would definitely speed things up.

Granted, the speedup would only materialize when issue #4978 (
https://golang.org/issue/4978 ) is resolved, but having code in
useful libraries in place to take advantage of that optimization would be nice instead
of having to recode everything afterwords.

To that end, I would request exposing at least the following (would do it myself if I
could find an understandable listing of the opcodes and documentation on how to add them
to the compiler): 

For greatest compatibility with AMD chips, 4 operand forms ( from
http://en.wikipedia.org/wiki/X86_instruction_listings#FMA_instructions ): 
VFMADDPD, VFMADDPS, VFMADDSD, VFMADDSS.

And for Intel chips, the 3 operand forms ( from Vol. 1 14-21 of Intel's developer's
manual:
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html?iid=tech_vt_tech+64-32_manuals
):
VFMADD231PD, VFMADD231PS, VFMADD231SD, VFMADD231SS

All of the other operations are permutations of minus signs applied to these (and which
register gets clobbered for the 3 op version - the one I'm requesting is the one that
works best with polynomial evaluation, naturally). 

Solving this issue would also make issue #681 more straightforward (
https://golang.org/issue/681 ), although even having the opcodes
would be enough for that one.
",0,cmd internal obj add fma by what does go version print go version devel mon may darwin what steps reproduce the problem if possible include a link to a program on play golang org go to goroot src cmd out h according to a href this file contains a list of all the assembler instructions go recognizes no fused multiply add instructions are in the list please provide any additional information below using fma allows for several faster and more accurate versions of several algorithms my current main use case is polynomial evaluation horner s scheme and estrin s scheme are both built on fma but another very important one is matrix multiplication adding at least a subset of the fma instructions available on newer amd and intel cpus available on powerpc since at least the series would improve the ability of performance minded coders and compiler optimization writers to make faster running code for instance a more accurate version of the update in the mandelbrot set is if the starting point is cr i ci and halfci ci zr zi fma zr zi zr zi cr fma zr zi halfci the update to zr is likely slower than what is presently done for the the computer language benchmarks game but an fma based update to zi would definitely speed things up granted the speedup would only materialize when a href is resolved but having code in useful libraries in place to take advantage of that optimization would be nice instead of having to recode everything afterwords to that end i would request exposing at least the following would do it myself if i could find an understandable listing of the opcodes and documentation on how to add them to the compiler for greatest compatibility with amd chips operand forms from a href vfmaddpd vfmaddps vfmaddsd vfmaddss and for intel chips the operand forms from vol of intel s developer s manual a href all of the other operations are permutations of minus signs applied to these and which register gets clobbered for the op version the one i m requesting is the one that works best with polynomial evaluation naturally solving this issue would also make more straightforward a href although even having the opcodes would be enough for that one ,0 5864,2981785951.0,IssuesEvent,2015-07-17 05:31:30,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go,cmd/trace: document the trace command",Documentation,"go help testflag does not mention the -trace flag The output of go tool trace -help is unhelpful: Usage of 'go tool trace': Given a trace file produced by 'go test': go test -trace=trace.out pkg Open a web browser displaying trace: go tool trace [flags] pkg.test trace.out Flags: -http=addr: HTTP service address (e.g., ':6060') Also, shortly after the 1.5 release, there should be a blog post about the feature. ",1.0,"cmd/go,cmd/trace: document the trace command - go help testflag does not mention the -trace flag The output of go tool trace -help is unhelpful: Usage of 'go tool trace': Given a trace file produced by 'go test': go test -trace=trace.out pkg Open a web browser displaying trace: go tool trace [flags] pkg.test trace.out Flags: -http=addr: HTTP service address (e.g., ':6060') Also, shortly after the 1.5 release, there should be a blog post about the feature. ",1,cmd go cmd trace document the trace command go help testflag does not mention the trace flag the output of go tool trace help is unhelpful usage of go tool trace given a trace file produced by go test go test trace trace out pkg open a web browser displaying trace go tool trace pkg test trace out flags http addr http service address e g also shortly after the release there should be a blog post about the feature ,1 59422,8362833451.0,IssuesEvent,2018-10-03 17:59:23,golang/go,https://api.github.com/repos/golang/go,closed,proposal: go/doc: package-level functions should also be listed at the beginning of package doc page,Documentation Proposal,"It looks some package-level functions are listed with the methods of the return types of these functions instead of at the beginning of the package doc page from some version. However I find doing this is often very inconvenient for package users to find the desired package-level functions. For example, the `http.Get`, `http.Post`, etc functions are all listed under the `http.Response` type now. It is really hard to a new user to find out what global functions a package provides. I can't say doing this is always bad, so I propose that such package-level functions should be listed both at the beginning of the package doc page and under the return types. ",1.0,"proposal: go/doc: package-level functions should also be listed at the beginning of package doc page - It looks some package-level functions are listed with the methods of the return types of these functions instead of at the beginning of the package doc page from some version. However I find doing this is often very inconvenient for package users to find the desired package-level functions. For example, the `http.Get`, `http.Post`, etc functions are all listed under the `http.Response` type now. It is really hard to a new user to find out what global functions a package provides. I can't say doing this is always bad, so I propose that such package-level functions should be listed both at the beginning of the package doc page and under the return types. ",1,proposal go doc package level functions should also be listed at the beginning of package doc page it looks some package level functions are listed with the methods of the return types of these functions instead of at the beginning of the package doc page from some version however i find doing this is often very inconvenient for package users to find the desired package level functions for example the http get http post etc functions are all listed under the http response type now it is really hard to a new user to find out what global functions a package provides i can t say doing this is always bad so i propose that such package level functions should be listed both at the beginning of the package doc page and under the return types ,1 263791,19975830588.0,IssuesEvent,2022-01-29 03:54:07,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: update -trimpath documentation,Documentation help wanted NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go1.18beta1
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/hakim/Library/Caches/go-build""
GOENV=""/Users/hakim/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/hakim/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/hakim/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/hakim/sdk/go1.18beta1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/hakim/sdk/go1.18beta1/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.18beta1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/hakim/ww/go.mod""
GOWORK=""""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build1609535835=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Built the following program with `-trimpath` ( `% go build -trimpath -o out` ) ``` --- go.mod --- module work go 1.17 require golang.org/x/mod v0.5.1 --- main.go --- package main import ( ""golang.org/x/mod/semver"" ) func main() { if semver.IsValid(""1.0.0"") { println(""valid"") } } ``` ### What did you expect to see? As described in `go1.18beta1 help build`, expected to see files from standard packages start with ""go"" > -trimpath > remove all file system paths from the resulting executable. > Instead of absolute file system paths, the recorded file names > will begin with either ""go"" (for the standard library), > or a module path@version (when using modules), > or a plain import path (when using GOPATH). ### What did you see instead? Files from standard libraries without ""go"" (plain import path + file base name) ``` % strings out | grep map.go runtime/mbitmap.go runtime/map.go ``` Description for packages from dependency modules seems correct. ``` % strings out | grep semver.go golang.org/x/mod@v0.5.1/semver/semver.go ``` Maybe need to mention behavior for main module files explicitly. ``` % strings out | grep main.go work/main.go ```",1.0,"cmd/go: update -trimpath documentation - ### What version of Go are you using (`go version`)? 
$ go version
go1.18beta1
### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/hakim/Library/Caches/go-build""
GOENV=""/Users/hakim/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/hakim/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/hakim/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/Users/hakim/sdk/go1.18beta1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/Users/hakim/sdk/go1.18beta1/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.18beta1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/hakim/ww/go.mod""
GOWORK=""""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build1609535835=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Built the following program with `-trimpath` ( `% go build -trimpath -o out` ) ``` --- go.mod --- module work go 1.17 require golang.org/x/mod v0.5.1 --- main.go --- package main import ( ""golang.org/x/mod/semver"" ) func main() { if semver.IsValid(""1.0.0"") { println(""valid"") } } ``` ### What did you expect to see? As described in `go1.18beta1 help build`, expected to see files from standard packages start with ""go"" > -trimpath > remove all file system paths from the resulting executable. > Instead of absolute file system paths, the recorded file names > will begin with either ""go"" (for the standard library), > or a module path@version (when using modules), > or a plain import path (when using GOPATH). ### What did you see instead? Files from standard libraries without ""go"" (plain import path + file base name) ``` % strings out | grep map.go runtime/mbitmap.go runtime/map.go ``` Description for packages from dependency modules seems correct. ``` % strings out | grep semver.go golang.org/x/mod@v0.5.1/semver/semver.go ``` Maybe need to mention behavior for main module files explicitly. ``` % strings out | grep main.go work/main.go ```",1,cmd go update trimpath documentation please answer these questions before submitting your issue thanks what version of go are you using go version go version what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users hakim library caches go build goenv users hakim library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users hakim go pkg mod gonoproxy gonosumdb goos darwin gopath users hakim go goprivate goproxy goroot users hakim sdk gosumdb sum golang org gotmpdir gotooldir users hakim sdk pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users hakim ww go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders bw vvzk t go tmp go build gno record gcc switches fno common what did you do built the following program with trimpath go build trimpath o out go mod module work go require golang org x mod main go package main import golang org x mod semver func main if semver isvalid println valid what did you expect to see as described in help build expected to see files from standard packages start with go trimpath remove all file system paths from the resulting executable instead of absolute file system paths the recorded file names will begin with either go for the standard library or a module path version when using modules or a plain import path when using gopath what did you see instead files from standard libraries without go plain import path file base name strings out grep map go runtime mbitmap go runtime map go description for packages from dependency modules seems correct strings out grep semver go golang org x mod semver semver go maybe need to mention behavior for main module files explicitly strings out grep main go work main go ,1 20754,6926002513.0,IssuesEvent,2017-11-30 17:38:03,golang/go,https://api.github.com/repos/golang/go,closed,x/build: automate GOROOT_BOOTSTRAP tarball creation,Builders,"Most of the builder images store their GOROOT_BOOTSTRAP contents in a tarball on GCS. That tarball is built by hand, starting with bootstrap.bash and then trimmed down (e.g. https://github.com/golang/go/issues/9797#issuecomment-204592820) Let's automate this. It's getting painful. ",1.0,"x/build: automate GOROOT_BOOTSTRAP tarball creation - Most of the builder images store their GOROOT_BOOTSTRAP contents in a tarball on GCS. That tarball is built by hand, starting with bootstrap.bash and then trimmed down (e.g. https://github.com/golang/go/issues/9797#issuecomment-204592820) Let's automate this. It's getting painful. ",0,x build automate goroot bootstrap tarball creation most of the builder images store their goroot bootstrap contents in a tarball on gcs that tarball is built by hand starting with bootstrap bash and then trimmed down e g let s automate this it s getting painful ,0 55959,31301539744.0,IssuesEvent,2023-08-23 00:16:54,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: Swapping elements of a `[2]any` uses 2 separate writebarriers,Performance help wanted NeedsInvestigation compiler/runtime," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.1 darwin/amd64
### Does this issue reproduce with the latest release? Uncertain ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOOS=""darwin""
### What did you do? I was profiling some code and found that swapping 2 elements of a slice was slower than expected. I found that swapping elements if they were pointer types instead of interfaces reached the performance I expected. This link shows the naive method of swapping elements, and the unsafe method which produces the asm and performance I expected: https://go.dev/play/p/NQZn03hsQU4 Here are the benchmarks: 
BenchmarkSwapIntPtrs-8          842213125                1.422 ns/op
BenchmarkSwapAny-8              749056459                1.575 ns/op
BenchmarkSwapAnyAsUintptrs-8    812162583                1.471 ns/op
My assumption is that the compiler should get the performance of the 3rd benchmark in which I use unsafe to force my expected asm to be generated, but is represented here as the 2nd benchmark. ### What did you expect to see? For the code 
arr[0], arr[1] = arr[1], arr[0]
where arr is an array of the empty interface, I expected to see just one write barrier check, just as I do for the (paraphrased) asm for swapping a normal pointer type. 
MOVQ the interfaces into registers
MOVQ both interface *type* parts into their new positions in the array
CMPL runtime.writeBarrier
MOVQ both interface *value* parts into their new positions in the array
### What did you see instead? I unexpectedly found *two* writebarrier checks, where the asm was writing the values of each interface with separate writebarrier checks, like this (paraphrased) asm. 
MOVQ the interfaces into registers
MOVQ both interface *type* parts into their new positions in the slice
CMPL runtime.writeBarrier
MOVQ one interface *value* into its new position in the slice
CMPL runtime.writeBarrier
MOVQ the other interface *value* into its new position in the slice
By using unsafe to treat the [2]any as a [4]uintptr and doing 2 sets of swaps, I was able to observe the asm doing just 1 writebarrier check. I currently believe that one check has the same semantics as two checks (in regards to concurrent gc sweep correctness), and this might be incorrect. I'm almost certain however it has the same semantics in regards to concurrent observability promises.",True,"cmd/compile: Swapping elements of a `[2]any` uses 2 separate writebarriers - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.1 darwin/amd64
### Does this issue reproduce with the latest release? Uncertain ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOOS=""darwin""
### What did you do? I was profiling some code and found that swapping 2 elements of a slice was slower than expected. I found that swapping elements if they were pointer types instead of interfaces reached the performance I expected. This link shows the naive method of swapping elements, and the unsafe method which produces the asm and performance I expected: https://go.dev/play/p/NQZn03hsQU4 Here are the benchmarks: 
BenchmarkSwapIntPtrs-8          842213125                1.422 ns/op
BenchmarkSwapAny-8              749056459                1.575 ns/op
BenchmarkSwapAnyAsUintptrs-8    812162583                1.471 ns/op
My assumption is that the compiler should get the performance of the 3rd benchmark in which I use unsafe to force my expected asm to be generated, but is represented here as the 2nd benchmark. ### What did you expect to see? For the code 
arr[0], arr[1] = arr[1], arr[0]
where arr is an array of the empty interface, I expected to see just one write barrier check, just as I do for the (paraphrased) asm for swapping a normal pointer type. 
MOVQ the interfaces into registers
MOVQ both interface *type* parts into their new positions in the array
CMPL runtime.writeBarrier
MOVQ both interface *value* parts into their new positions in the array
### What did you see instead? I unexpectedly found *two* writebarrier checks, where the asm was writing the values of each interface with separate writebarrier checks, like this (paraphrased) asm. 
MOVQ the interfaces into registers
MOVQ both interface *type* parts into their new positions in the slice
CMPL runtime.writeBarrier
MOVQ one interface *value* into its new position in the slice
CMPL runtime.writeBarrier
MOVQ the other interface *value* into its new position in the slice
By using unsafe to treat the [2]any as a [4]uintptr and doing 2 sets of swaps, I was able to observe the asm doing just 1 writebarrier check. I currently believe that one check has the same semantics as two checks (in regards to concurrent gc sweep correctness), and this might be incorrect. I'm almost certain however it has the same semantics in regards to concurrent observability promises.",0,cmd compile swapping elements of a any uses separate writebarriers please answer these questions before submitting your issue thanks what version of go are you using go version go version go version darwin does this issue reproduce with the latest release uncertain what operating system and processor architecture are you using go env go env output go env goarch goos darwin what did you do i was profiling some code and found that swapping elements of a slice was slower than expected i found that swapping elements if they were pointer types instead of interfaces reached the performance i expected this link shows the naive method of swapping elements and the unsafe method which produces the asm and performance i expected here are the benchmarks benchmarkswapintptrs ns op benchmarkswapany ns op benchmarkswapanyasuintptrs ns op my assumption is that the compiler should get the performance of the benchmark in which i use unsafe to force my expected asm to be generated but is represented here as the benchmark what did you expect to see for the code arr arr arr arr where arr is an array of the empty interface i expected to see just one write barrier check just as i do for the paraphrased asm for swapping a normal pointer type movq the interfaces into registers movq both interface type parts into their new positions in the array cmpl runtime writebarrier movq both interface value parts into their new positions in the array what did you see instead i unexpectedly found two writebarrier checks where the asm was writing the values of each interface with separate writebarrier checks like this paraphrased asm movq the interfaces into registers movq both interface type parts into their new positions in the slice cmpl runtime writebarrier movq one interface value into its new position in the slice cmpl runtime writebarrier movq the other interface value into its new position in the slice by using unsafe to treat the any as a uintptr and doing sets of swaps i was able to observe the asm doing just writebarrier check i currently believe that one check has the same semantics as two checks in regards to concurrent gc sweep correctness and this might be incorrect i m almost certain however it has the same semantics in regards to concurrent observability promises ,0 35945,6515005389.0,IssuesEvent,2017-08-26 09:21:11,golang/go,https://api.github.com/repos/golang/go,closed,website: Command Documentation,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? konstantin@debian:~$ go version go version go1.8.3 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? debian ### What did you do? Read documentation on web site https://golang.org/doc/cmd ### What did you expect to see? Not clear organization of ""command"": * some ... * full command reference ### What did you see instead? Merge 2 list of commands to one solid list, like we see in page https://golang.org/pkg/ for packages and . Preliminary : * go | Descriptions for go * go commands | Descriptions for go commands * go build | Descriptions for go build * go clean | Descriptions for go clean ... But I want to clarify some points: 1. If we open link **go** on page https://golang.org/doc/cmd, then we will see big good information about **go doc**. But, If we open on link **full command reference** https://golang.org/doc/cmd, after that link **doc** - then we see short information. 2. On page https://golang.org/doc/cmd link **cover** ---> result documentation from X tools. But on page https://golang.org/cmd/ link **cover** ---> result looks nice. Please separate page https://golang.org/cmd/go/ to single small parts. ### The reason Simple organization of documents is clear and easy to translate. ",1.0,"website: Command Documentation - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? konstantin@debian:~$ go version go version go1.8.3 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? debian ### What did you do? Read documentation on web site https://golang.org/doc/cmd ### What did you expect to see? Not clear organization of ""command"": * some ... * full command reference ### What did you see instead? Merge 2 list of commands to one solid list, like we see in page https://golang.org/pkg/ for packages and . Preliminary : * go | Descriptions for go * go commands | Descriptions for go commands * go build | Descriptions for go build * go clean | Descriptions for go clean ... But I want to clarify some points: 1. If we open link **go** on page https://golang.org/doc/cmd, then we will see big good information about **go doc**. But, If we open on link **full command reference** https://golang.org/doc/cmd, after that link **doc** - then we see short information. 2. On page https://golang.org/doc/cmd link **cover** ---> result documentation from X tools. But on page https://golang.org/cmd/ link **cover** ---> result looks nice. Please separate page https://golang.org/cmd/go/ to single small parts. ### The reason Simple organization of documents is clear and easy to translate. ",1,website command documentation please answer these questions before submitting your issue thanks what version of go are you using go version konstantin debian go version go version linux what operating system and processor architecture are you using go env debian what did you do read documentation on web site what did you expect to see not clear organization of command some full command reference what did you see instead merge list of commands to one solid list like we see in page for packages and preliminary go descriptions for go go commands descriptions for go commands go build descriptions for go build go clean descriptions for go clean but i want to clarify some points if we open link go on page then we will see big good information about go doc but if we open on link full command reference after that link doc then we see short information on page link cover result documentation from x tools but on page link cover result looks nice please separate page to single small parts the reason simple organization of documents is clear and easy to translate ,1 30085,5725524164.0,IssuesEvent,2017-04-20 16:45:41,golang/go,https://api.github.com/repos/golang/go,closed,cmd/trace: traceviewer tool doesn't work in non-chrome browsers,Documentation NeedsFix,"### What version of Go are you using (`go version`)? go version go1.8 ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? Call `go tool trace trace.file` as described in https://godoc.org/cmd/trace and open the ""View trace"" link using Safari (or other non-Chrome) web browser. ### What did you expect to see? Expected to see the Trace viewer. ### What did you see instead? There is a JavaScript error, saying ""ReferenceError: Can't find variable: tr"" in the console of the browser. I know that the trace-viewer itself comes from [the catapult project](https://github.com/catapult-project/catapult), as well as that the project was built specifically for Chrome and/or Android, but I think it would be worth to add a notice to `cmd/trace` documentation about this fact. ",1.0,"cmd/trace: traceviewer tool doesn't work in non-chrome browsers - ### What version of Go are you using (`go version`)? go version go1.8 ### What operating system and processor architecture are you using (`go env`)? darwin/amd64 ### What did you do? Call `go tool trace trace.file` as described in https://godoc.org/cmd/trace and open the ""View trace"" link using Safari (or other non-Chrome) web browser. ### What did you expect to see? Expected to see the Trace viewer. ### What did you see instead? There is a JavaScript error, saying ""ReferenceError: Can't find variable: tr"" in the console of the browser. I know that the trace-viewer itself comes from [the catapult project](https://github.com/catapult-project/catapult), as well as that the project was built specifically for Chrome and/or Android, but I think it would be worth to add a notice to `cmd/trace` documentation about this fact. ",1,cmd trace traceviewer tool doesn t work in non chrome browsers what version of go are you using go version go version what operating system and processor architecture are you using go env darwin what did you do call go tool trace trace file as described in and open the view trace link using safari or other non chrome web browser what did you expect to see expected to see the trace viewer what did you see instead there is a javascript error saying referenceerror can t find variable tr in the console of the browser i know that the trace viewer itself comes from as well as that the project was built specifically for chrome and or android but i think it would be worth to add a notice to cmd trace documentation about this fact ,1 95097,10865926874.0,IssuesEvent,2019-11-14 20:04:06,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: only use import text as range for textDocument/documentLink responses ,Documentation Tools gopls,"Please answer these questions before submitting your issue. Thanks! #### What did you do? Have import statements, a mix of normal imports, aliased imports, `_` imports. #### What did you expect to see? Links which span the package path. #### What did you see instead? The links span the entire import statement, and not just the link. See: ![image](https://user-images.githubusercontent.com/48577114/68792039-71aa3180-05ff-11ea-8ed3-9743923ad345.png) Note how the package aliases are also underlined, and even the `_` imported package. Including the quotes also feels wrong. I would personally prefer them to look like: ![image](https://user-images.githubusercontent.com/48577114/68792361-0ca30b80-0600-11ea-8481-cc2b9dac95b7.png) Which is just a change to: ```go toProtocolLink(view, m, target, n.Path.Pos()+1, n.End()-1) ``` (But I'm not sure if this is the correct way to get the span of a literal, just a PoC.) #### Build info ``` golang.org/x/tools/gopls master golang.org/x/tools/gopls@v0.1.8-0.20191113163402-bc1376d635b8 h1:xSNm5FMZDYQjehCHcVzpGm4D9oNz/+AD+C/pRROxjMk= github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ= github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ= golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU= golang.org/x/tools@v0.0.0-20191113163402-bc1376d635b8 h1:3xDEBhGRwlUGJue2GW3jVaqWs/HrAm+Lz4HAoQVWuJs= golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc= honnef.co/go/tools@v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM= ``` #### Go info ``` go version go1.13.4 linux/amd64 GO111MODULE="""" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/jake/.cache/go-build"" GOENV=""/home/jake/.config/go/env"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GONOPROXY="""" GONOSUMDB="""" GOOS=""linux"" GOPATH=""/home/jake/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/usr/lib/go"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" AR=""ar"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" GOMOD=""/home/jake/zikaeroh/hortbot/hortbot/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-build705508798=/tmp/go-build -gno-record-gcc-switches"" ``` ",1.0,"x/tools/gopls: only use import text as range for textDocument/documentLink responses - Please answer these questions before submitting your issue. Thanks! #### What did you do? Have import statements, a mix of normal imports, aliased imports, `_` imports. #### What did you expect to see? Links which span the package path. #### What did you see instead? The links span the entire import statement, and not just the link. See: ![image](https://user-images.githubusercontent.com/48577114/68792039-71aa3180-05ff-11ea-8ed3-9743923ad345.png) Note how the package aliases are also underlined, and even the `_` imported package. Including the quotes also feels wrong. I would personally prefer them to look like: ![image](https://user-images.githubusercontent.com/48577114/68792361-0ca30b80-0600-11ea-8481-cc2b9dac95b7.png) Which is just a change to: ```go toProtocolLink(view, m, target, n.Path.Pos()+1, n.End()-1) ``` (But I'm not sure if this is the correct way to get the span of a literal, just a PoC.) #### Build info ``` golang.org/x/tools/gopls master golang.org/x/tools/gopls@v0.1.8-0.20191113163402-bc1376d635b8 h1:xSNm5FMZDYQjehCHcVzpGm4D9oNz/+AD+C/pRROxjMk= github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ= github.com/sergi/go-diff@v1.0.0 h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ= golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU= golang.org/x/tools@v0.0.0-20191113163402-bc1376d635b8 h1:3xDEBhGRwlUGJue2GW3jVaqWs/HrAm+Lz4HAoQVWuJs= golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc= honnef.co/go/tools@v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM= ``` #### Go info ``` go version go1.13.4 linux/amd64 GO111MODULE="""" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/jake/.cache/go-build"" GOENV=""/home/jake/.config/go/env"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GONOPROXY="""" GONOSUMDB="""" GOOS=""linux"" GOPATH=""/home/jake/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/usr/lib/go"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" AR=""ar"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" GOMOD=""/home/jake/zikaeroh/hortbot/hortbot/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-build705508798=/tmp/go-build -gno-record-gcc-switches"" ``` ",1,x tools gopls only use import text as range for textdocument documentlink responses please answer these questions before submitting your issue thanks what did you do have import statements a mix of normal imports aliased imports imports what did you expect to see links which span the package path what did you see instead the links span the entire import statement and not just the link see note how the package aliases are also underlined and even the imported package including the quotes also feels wrong i would personally prefer them to look like which is just a change to go toprotocollink view m target n path pos n end but i m not sure if this is the correct way to get the span of a literal just a poc build info golang org x tools gopls master golang org x tools gopls ad c prroxjmk github com burntsushi toml github com sergi go diff golang org x sync golang org x tools hram golang org x xerrors dxappncc honnef co go tools go info go version linux goarch gobin gocache home jake cache go build goenv home jake config go env goexe goflags gohostarch gohostos linux gonoproxy gonosumdb goos linux gopath home jake go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home jake zikaeroh hortbot hortbot go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches ,1 96631,27964070311.0,IssuesEvent,2023-03-24 17:53:43,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/task/releaselet: change the minimum Windows version in the installer,OS-Windows Builders NeedsFix release-blocker,"As proposed in #57003 and #57004, the minimum supported version of Windows will be changing for the go1.21 release. The packager configuration should reflect that change before the release. There are also various other updates that can happen to the packager script. Such as: - Change all references of `golang.org` to `go.dev` in the packager configuration. - Updating `DialogLeft.jpg` image as described in #57413 cc @golang/release ",1.0,"x/build/internal/task/releaselet: change the minimum Windows version in the installer - As proposed in #57003 and #57004, the minimum supported version of Windows will be changing for the go1.21 release. The packager configuration should reflect that change before the release. There are also various other updates that can happen to the packager script. Such as: - Change all references of `golang.org` to `go.dev` in the packager configuration. - Updating `DialogLeft.jpg` image as described in #57413 cc @golang/release ",0,x build internal task releaselet change the minimum windows version in the installer as proposed in and the minimum supported version of windows will be changing for the release the packager configuration should reflect that change before the release there are also various other updates that can happen to the packager script such as change all references of golang org to go dev in the packager configuration updating dialogleft jpg image as described in cc golang release ,0 368846,25811084581.0,IssuesEvent,2022-12-11 21:23:31,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: better fuzzing documentation,Documentation,"The documentation was pretty sparse on fuzzing. First I had a tough time finding where my corpus was because no testdata dir was being generated- so I though ""aha, must be an environment variable, something like `GOFUZZCORPUS`, but. nothing. Then I started looking in `go help test`, took me a while to skim though and find that I needed to check out `go help testfunc` for more details only to find there was barely anything on fuzzing. Relevant `go help test` output: ``` These additional files can contain test functions, benchmark functions, fuzz tests and example functions. See 'go help testfunc' for more. ``` Relevant `go help testfunc` output: ``` A fuzz test is one named FuzzXxx and should have the signature, func FuzzXxx(f *testing.F) { ... } // ... The entire test file is presented as the example when it contains a single example function, at least one other function, type, variable, or constant declaration, and no tests, benchmarks, or fuzz tests. ``` There is no way to make out how the fuzzing command works from this. Please add better documentation of: * Where the non-crashign fuzz corpus is located (GOCACHE) * Where the crashing corpus is located * What the differences are between both * Fuzzing by default goes on forever * How to add non crashing fuzz corpus to unit tests ",1.0,"cmd/go: better fuzzing documentation - The documentation was pretty sparse on fuzzing. First I had a tough time finding where my corpus was because no testdata dir was being generated- so I though ""aha, must be an environment variable, something like `GOFUZZCORPUS`, but. nothing. Then I started looking in `go help test`, took me a while to skim though and find that I needed to check out `go help testfunc` for more details only to find there was barely anything on fuzzing. Relevant `go help test` output: ``` These additional files can contain test functions, benchmark functions, fuzz tests and example functions. See 'go help testfunc' for more. ``` Relevant `go help testfunc` output: ``` A fuzz test is one named FuzzXxx and should have the signature, func FuzzXxx(f *testing.F) { ... } // ... The entire test file is presented as the example when it contains a single example function, at least one other function, type, variable, or constant declaration, and no tests, benchmarks, or fuzz tests. ``` There is no way to make out how the fuzzing command works from this. Please add better documentation of: * Where the non-crashign fuzz corpus is located (GOCACHE) * Where the crashing corpus is located * What the differences are between both * Fuzzing by default goes on forever * How to add non crashing fuzz corpus to unit tests ",1,cmd go better fuzzing documentation the documentation was pretty sparse on fuzzing first i had a tough time finding where my corpus was because no testdata dir was being generated so i though aha must be an environment variable something like gofuzzcorpus but nothing then i started looking in go help test took me a while to skim though and find that i needed to check out go help testfunc for more details only to find there was barely anything on fuzzing relevant go help test output these additional files can contain test functions benchmark functions fuzz tests and example functions see go help testfunc for more relevant go help testfunc output a fuzz test is one named fuzzxxx and should have the signature func fuzzxxx f testing f the entire test file is presented as the example when it contains a single example function at least one other function type variable or constant declaration and no tests benchmarks or fuzz tests there is no way to make out how the fuzzing command works from this please add better documentation of where the non crashign fuzz corpus is located gocache where the crashing corpus is located what the differences are between both fuzzing by default goes on forever how to add non crashing fuzz corpus to unit tests ,1 57637,14175959436.0,IssuesEvent,2020-11-12 22:32:50,golang/go,https://api.github.com/repos/golang/go,closed,math/big: panic during recursive division of very large numbers,Security,"A number of math/big.Int methods (Div, Exp, DivMod, Quo, Rem, QuoRem, Mod, ModInverse, ModSqrt, Jacobi, and GCD) can panic when provided crafted large inputs. For the panic to happen, the divisor or modulo argument must be larger than 3168 bits (on 32-bit architectures) or 6336 bits (on 64-bit architectures). Multiple math/big.Rat methods are similarly affected. crypto/rsa.VerifyPSS, crypto/rsa.VerifyPKCS1v15, and crypto/dsa.Verify may panic when provided crafted public keys and signatures. crypto/ecdsa and crypto/elliptic operations may only be affected if custom CurveParams with unusually large field sizes (several times larger than the largest supported curve, P-521) are in use. Using crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic, even if the certificates don’t chain to a trusted root. The chain can be delivered via a crypto/tls connection to a client, or to a server that accepts and verifies client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected. Moreover, an application might crash invoking crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate request or during a golang.org/x/crypto/otr conversation. Parsing a golang.org/x/crypto/openpgp Entity or verifying a signature may crash. Finally, a golang.org/x/crypto/ssh client can panic due to a malformed host key, while a server could panic if either PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts a certificate with a malformed public key. Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting this. Thanks to Rémy Oudompheng and Robert Griesemer for their help developing and validating the fix. This issue is CVE-2020-28362.",True,"math/big: panic during recursive division of very large numbers - A number of math/big.Int methods (Div, Exp, DivMod, Quo, Rem, QuoRem, Mod, ModInverse, ModSqrt, Jacobi, and GCD) can panic when provided crafted large inputs. For the panic to happen, the divisor or modulo argument must be larger than 3168 bits (on 32-bit architectures) or 6336 bits (on 64-bit architectures). Multiple math/big.Rat methods are similarly affected. crypto/rsa.VerifyPSS, crypto/rsa.VerifyPKCS1v15, and crypto/dsa.Verify may panic when provided crafted public keys and signatures. crypto/ecdsa and crypto/elliptic operations may only be affected if custom CurveParams with unusually large field sizes (several times larger than the largest supported curve, P-521) are in use. Using crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic, even if the certificates don’t chain to a trusted root. The chain can be delivered via a crypto/tls connection to a client, or to a server that accepts and verifies client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected. Moreover, an application might crash invoking crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate request or during a golang.org/x/crypto/otr conversation. Parsing a golang.org/x/crypto/openpgp Entity or verifying a signature may crash. Finally, a golang.org/x/crypto/ssh client can panic due to a malformed host key, while a server could panic if either PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts a certificate with a malformed public key. Thanks to the Go Ethereum team and the OSS-Fuzz project for reporting this. Thanks to Rémy Oudompheng and Robert Griesemer for their help developing and validating the fix. This issue is CVE-2020-28362.",0,math big panic during recursive division of very large numbers a number of math big int methods div exp divmod quo rem quorem mod modinverse modsqrt jacobi and gcd can panic when provided crafted large inputs for the panic to happen the divisor or modulo argument must be larger than bits on bit architectures or bits on bit architectures multiple math big rat methods are similarly affected crypto rsa verifypss crypto rsa and crypto dsa verify may panic when provided crafted public keys and signatures crypto ecdsa and crypto elliptic operations may only be affected if custom curveparams with unusually large field sizes several times larger than the largest supported curve p are in use using crypto verify on a crafted x certificate chain can lead to a panic even if the certificates don’t chain to a trusted root the chain can be delivered via a crypto tls connection to a client or to a server that accepts and verifies client certificates net http clients can be made to crash by an https server while net http servers that accept client certificates will recover the panic and are unaffected moreover an application might crash invoking crypto certificaterequest checksignature on an x certificate request or during a golang org x crypto otr conversation parsing a golang org x crypto openpgp entity or verifying a signature may crash finally a golang org x crypto ssh client can panic due to a malformed host key while a server could panic if either publickeycallback accepts a malformed public key or if isuserauthority accepts a certificate with a malformed public key thanks to the go ethereum team and the oss fuzz project for reporting this thanks to rémy oudompheng and robert griesemer for their help developing and validating the fix this issue is cve ,0 55356,7977941741.0,IssuesEvent,2018-07-17 16:44:55,golang/go,https://api.github.com/repos/golang/go,closed,doc: vet check included in gc needs to be documented,Documentation NeedsFix,"vet check seems to be included in gc by default but not documented in go1.11 release note yet (sorry, I didn't search enough to find related issue/proposal/change to link yet). This behavior change resulted in build-failures for codes that don't pass vet currently and could be misunderstood as a regression in go1.11. For example, with go1.11 (or tip), go test on github.com/spf13/cobra will fail due to failure to pass vet check. 
$ go version
go version devel +257d6c48e0 Thu Jun 28 03:12:01 2018 +0000 linux/amd64

$  go test github.com/spf13/cobra
# github.com/spf13/cobra
../github.com/spf13/cobra/command_test.go:1105:3: parentPersPreArgs declared but not used
../github.com/spf13/cobra/command_test.go:1109:3: parentPersPostArgs declared but not used
vet: typecheck failures
FAIL	github.com/spf13/cobra [build failed]
BTW, the vet error message is confusing because the parentPersPreArgs and parentPersPostArgs in the test are 'used' (literally). But for the purpose of vet check, the vars are 'not used' because they are never read. ",1.0,"doc: vet check included in gc needs to be documented - vet check seems to be included in gc by default but not documented in go1.11 release note yet (sorry, I didn't search enough to find related issue/proposal/change to link yet). This behavior change resulted in build-failures for codes that don't pass vet currently and could be misunderstood as a regression in go1.11. For example, with go1.11 (or tip), go test on github.com/spf13/cobra will fail due to failure to pass vet check. 
$ go version
go version devel +257d6c48e0 Thu Jun 28 03:12:01 2018 +0000 linux/amd64

$  go test github.com/spf13/cobra
# github.com/spf13/cobra
../github.com/spf13/cobra/command_test.go:1105:3: parentPersPreArgs declared but not used
../github.com/spf13/cobra/command_test.go:1109:3: parentPersPostArgs declared but not used
vet: typecheck failures
FAIL	github.com/spf13/cobra [build failed]
BTW, the vet error message is confusing because the parentPersPreArgs and parentPersPostArgs in the test are 'used' (literally). But for the purpose of vet check, the vars are 'not used' because they are never read. ",1,doc vet check included in gc needs to be documented vet check seems to be included in gc by default but not documented in release note yet sorry i didn t search enough to find related issue proposal change to link yet this behavior change resulted in build failures for codes that don t pass vet currently and could be misunderstood as a regression in for example with or tip go test on github com cobra will fail due to failure to pass vet check go version go version devel thu jun linux go test github com cobra github com cobra github com cobra command test go parentperspreargs declared but not used github com cobra command test go parentperspostargs declared but not used vet typecheck failures fail github com cobra btw the vet error message is confusing because the parentperspreargs and parentperspostargs in the test are used literally but for the purpose of vet check the vars are not used because they are never read ,1 125083,10336369033.0,IssuesEvent,2019-09-03 12:50:07,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/internal/imports: test frequently times out on `dragonfly-amd64` builder,Testing,"The test for `golang.org/x/tools/internal/imports` seems to be timing out on around 25% of runs on the `dragonfly-amd64` builder. Example logs: * https://build.golang.org/log/e697ac9c8ea86c4aa83321b80d9c1371c7c630fb * https://build.golang.org/log/7a7c78010de15f81e9b3411c020e1048006e39e2 * https://build.golang.org/log/606423ffa1cb92cf42e35073469762d25b9e282c * https://build.golang.org/log/ed9923ceaf868e900d12bf6e7c296d916c7f6a2c The `dragonfly-amd64` builder seems to be a bit underpowered in general (see also #29583 and #25796). Perhaps we should set `GO_TEST_TIMEOUT_SCALE=2` in its environment and see if that improves the situation for `x/tools`? CC @matloob @ianthehat @tdfbsd",1.0,"x/tools/internal/imports: test frequently times out on `dragonfly-amd64` builder - The test for `golang.org/x/tools/internal/imports` seems to be timing out on around 25% of runs on the `dragonfly-amd64` builder. Example logs: * https://build.golang.org/log/e697ac9c8ea86c4aa83321b80d9c1371c7c630fb * https://build.golang.org/log/7a7c78010de15f81e9b3411c020e1048006e39e2 * https://build.golang.org/log/606423ffa1cb92cf42e35073469762d25b9e282c * https://build.golang.org/log/ed9923ceaf868e900d12bf6e7c296d916c7f6a2c The `dragonfly-amd64` builder seems to be a bit underpowered in general (see also #29583 and #25796). Perhaps we should set `GO_TEST_TIMEOUT_SCALE=2` in its environment and see if that improves the situation for `x/tools`? CC @matloob @ianthehat @tdfbsd",0,x tools internal imports test frequently times out on dragonfly builder the test for golang org x tools internal imports seems to be timing out on around of runs on the dragonfly builder example logs the dragonfly builder seems to be a bit underpowered in general see also and perhaps we should set go test timeout scale in its environment and see if that improves the situation for x tools cc matloob ianthehat tdfbsd,0 40196,6803271050.0,IssuesEvent,2017-11-02 23:51:53,golang/go,https://api.github.com/repos/golang/go,closed,net/http: clarify whether Requests can be reused,Documentation,"Re-using requests is currently unreliable. If that's intended, then I think it should be documented. If not intended, then I can provide steps to reproduce.",1.0,"net/http: clarify whether Requests can be reused - Re-using requests is currently unreliable. If that's intended, then I think it should be documented. If not intended, then I can provide steps to reproduce.",1,net http clarify whether requests can be reused re using requests is currently unreliable if that s intended then i think it should be documented if not intended then i can provide steps to reproduce ,1 69716,17795844677.0,IssuesEvent,2021-08-31 22:05:28,golang/go,https://api.github.com/repos/golang/go,closed,x/build: upgrade the IOS version on host-ios-arm64-corellium-ios,Builders NeedsFix,"We've recently discovered that the builder used to test IOS development is running an older version of IOS. Would it be possible to update the IOS version we test against in `host-ios-arm64-corellium-ios` to IOS 14? @znly @golang/release /cc @aclements ",1.0,"x/build: upgrade the IOS version on host-ios-arm64-corellium-ios - We've recently discovered that the builder used to test IOS development is running an older version of IOS. Would it be possible to update the IOS version we test against in `host-ios-arm64-corellium-ios` to IOS 14? @znly @golang/release /cc @aclements ",0,x build upgrade the ios version on host ios corellium ios we ve recently discovered that the builder used to test ios development is running an older version of ios would it be possible to update the ios version we test against in host ios corellium ios to ios znly golang release cc aclements ,0 190540,15242613860.0,IssuesEvent,2021-02-19 10:06:33,golang/go,https://api.github.com/repos/golang/go,closed,x/website: merge module doc changes as part of Go 1.16 release,Documentation NeedsFix,"1.16 introduces a `retract` directive. The new directive is not mentioned in the [Go Modules Reference](https://tip.golang.org/ref/mod#go-mod-file-grammar). The [CL adding the doc](https://go-review.googlesource.com/c/website/+/286952) will need to be merged before the 1.16 release (currently has a merge conflict). In 1.16, go install will accepts arguments with version suffixes (`go install pkg@version`). The [CL adding the relevant doc](https://go-review.googlesource.com/c/website/+/285452) will need to be merged before the 1.16 release (currently has a merge conflict, and unresolved comments). Filing an issue just to be sure this is on someone's radar. cc @dmitshur @bcmills ",1.0,"x/website: merge module doc changes as part of Go 1.16 release - 1.16 introduces a `retract` directive. The new directive is not mentioned in the [Go Modules Reference](https://tip.golang.org/ref/mod#go-mod-file-grammar). The [CL adding the doc](https://go-review.googlesource.com/c/website/+/286952) will need to be merged before the 1.16 release (currently has a merge conflict). In 1.16, go install will accepts arguments with version suffixes (`go install pkg@version`). The [CL adding the relevant doc](https://go-review.googlesource.com/c/website/+/285452) will need to be merged before the 1.16 release (currently has a merge conflict, and unresolved comments). Filing an issue just to be sure this is on someone's radar. cc @dmitshur @bcmills ",1,x website merge module doc changes as part of go release introduces a retract directive the new directive is not mentioned in the the will need to be merged before the release currently has a merge conflict in go install will accepts arguments with version suffixes go install pkg version the will need to be merged before the release currently has a merge conflict and unresolved comments filing an issue just to be sure this is on someone s radar cc dmitshur bcmills ,1 16695,9488575748.0,IssuesEvent,2019-04-22 19:57:33,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: apparent extraneous inlmarks,NeedsInvestigation Performance,"```go package p import ""encoding/binary"" func f(key [4]byte, b []byte) { k := binary.LittleEndian.Uint32(key[:]) v := binary.LittleEndian.Uint32(b) binary.LittleEndian.PutUint32(b, v^k) } ``` generates: ``` """".f STEXT nosplit size=62 args=0x20 locals=0x18 0x0000 00000 (x.go:5) TEXT """".f(SB), NOSPLIT|ABIInternal, $24-32 0x0000 00000 (x.go:5) SUBQ $24, SP 0x0004 00004 (x.go:5) MOVQ BP, 16(SP) 0x0009 00009 (x.go:5) LEAQ 16(SP), BP 0x000e 00014 (x.go:5) FUNCDATA $0, gclocals·09cf9819fc716118c209c2d2155a3632(SB) 0x000e 00014 (x.go:5) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x000e 00014 (x.go:5) FUNCDATA $2, gclocals·9fb7f0986f647f17cb53dda1484e0f7a(SB) 0x000e 00014 (x.go:6) PCDATA $0, $0 0x000e 00014 (x.go:6) PCDATA $1, $0 0x000e 00014 (x.go:6) XCHGL AX, AX 0x000f 00015 (x.go:7) XCHGL AX, AX 0x0010 00016 (x.go:6) MOVL """".key+32(SP), DX 0x0014 00020 ($GOROOT/src/encoding/binary/binary.go:63) MOVQ """".b+48(SP), CX 0x0019 00025 ($GOROOT/src/encoding/binary/binary.go:63) CMPQ CX, $3 0x001d 00029 ($GOROOT/src/encoding/binary/binary.go:63) JLS 51 0x001f 00031 (x.go:8) XCHGL AX, AX 0x0020 00032 (x.go:8) PCDATA $0, $1 0x0020 00032 (x.go:8) PCDATA $1, $1 0x0020 00032 (x.go:8) MOVQ """".b+40(SP), AX 0x0025 00037 (x.go:8) XORL (AX), DX 0x0027 00039 ($GOROOT/src/encoding/binary/binary.go:72) PCDATA $0, $0 0x0027 00039 ($GOROOT/src/encoding/binary/binary.go:72) MOVL DX, (AX) 0x0029 00041 () MOVQ 16(SP), BP 0x002e 00046 () ADDQ $24, SP 0x0032 00050 () RET 0x0033 00051 ($GOROOT/src/encoding/binary/binary.go:63) MOVL $3, AX 0x0038 00056 ($GOROOT/src/encoding/binary/binary.go:63) CALL runtime.panicIndex(SB) 0x003d 00061 ($GOROOT/src/encoding/binary/binary.go:63) XCHGL AX, AX ``` Note the side-by-side NOPs at 0x000e and 0x000f. (They do have different line numbers.) They are also at the beginning of the routine, before any other work has been done. This makes me wonder whether we could eliminate either or both. @randall77 anything we can do here? ",True,"cmd/compile: apparent extraneous inlmarks - ```go package p import ""encoding/binary"" func f(key [4]byte, b []byte) { k := binary.LittleEndian.Uint32(key[:]) v := binary.LittleEndian.Uint32(b) binary.LittleEndian.PutUint32(b, v^k) } ``` generates: ``` """".f STEXT nosplit size=62 args=0x20 locals=0x18 0x0000 00000 (x.go:5) TEXT """".f(SB), NOSPLIT|ABIInternal, $24-32 0x0000 00000 (x.go:5) SUBQ $24, SP 0x0004 00004 (x.go:5) MOVQ BP, 16(SP) 0x0009 00009 (x.go:5) LEAQ 16(SP), BP 0x000e 00014 (x.go:5) FUNCDATA $0, gclocals·09cf9819fc716118c209c2d2155a3632(SB) 0x000e 00014 (x.go:5) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB) 0x000e 00014 (x.go:5) FUNCDATA $2, gclocals·9fb7f0986f647f17cb53dda1484e0f7a(SB) 0x000e 00014 (x.go:6) PCDATA $0, $0 0x000e 00014 (x.go:6) PCDATA $1, $0 0x000e 00014 (x.go:6) XCHGL AX, AX 0x000f 00015 (x.go:7) XCHGL AX, AX 0x0010 00016 (x.go:6) MOVL """".key+32(SP), DX 0x0014 00020 ($GOROOT/src/encoding/binary/binary.go:63) MOVQ """".b+48(SP), CX 0x0019 00025 ($GOROOT/src/encoding/binary/binary.go:63) CMPQ CX, $3 0x001d 00029 ($GOROOT/src/encoding/binary/binary.go:63) JLS 51 0x001f 00031 (x.go:8) XCHGL AX, AX 0x0020 00032 (x.go:8) PCDATA $0, $1 0x0020 00032 (x.go:8) PCDATA $1, $1 0x0020 00032 (x.go:8) MOVQ """".b+40(SP), AX 0x0025 00037 (x.go:8) XORL (AX), DX 0x0027 00039 ($GOROOT/src/encoding/binary/binary.go:72) PCDATA $0, $0 0x0027 00039 ($GOROOT/src/encoding/binary/binary.go:72) MOVL DX, (AX) 0x0029 00041 () MOVQ 16(SP), BP 0x002e 00046 () ADDQ $24, SP 0x0032 00050 () RET 0x0033 00051 ($GOROOT/src/encoding/binary/binary.go:63) MOVL $3, AX 0x0038 00056 ($GOROOT/src/encoding/binary/binary.go:63) CALL runtime.panicIndex(SB) 0x003d 00061 ($GOROOT/src/encoding/binary/binary.go:63) XCHGL AX, AX ``` Note the side-by-side NOPs at 0x000e and 0x000f. (They do have different line numbers.) They are also at the beginning of the routine, before any other work has been done. This makes me wonder whether we could eliminate either or both. @randall77 anything we can do here? ",0,cmd compile apparent extraneous inlmarks go package p import encoding binary func f key byte b byte k binary littleendian key v binary littleendian b binary littleendian b v k generates f stext nosplit size args locals x go text f sb nosplit abiinternal x go subq sp x go movq bp sp x go leaq sp bp x go funcdata gclocals· sb x go funcdata gclocals· sb x go funcdata gclocals· sb x go pcdata x go pcdata x go xchgl ax ax x go xchgl ax ax x go movl key sp dx goroot src encoding binary binary go movq b sp cx goroot src encoding binary binary go cmpq cx goroot src encoding binary binary go jls x go xchgl ax ax x go pcdata x go pcdata x go movq b sp ax x go xorl ax dx goroot src encoding binary binary go pcdata goroot src encoding binary binary go movl dx ax movq sp bp addq sp ret goroot src encoding binary binary go movl ax goroot src encoding binary binary go call runtime panicindex sb goroot src encoding binary binary go xchgl ax ax note the side by side nops at and they do have different line numbers they are also at the beginning of the routine before any other work has been done this makes me wonder whether we could eliminate either or both anything we can do here ,0 40244,6808951078.0,IssuesEvent,2017-11-04 11:00:45,golang/go,https://api.github.com/repos/golang/go,closed,doc: reflect documentation doesn't show examples,Documentation,"Possibly a continuation of #21601. https://golang.org/pkg/reflect/ doesn't show examples, while https://godoc.org/reflect does.",1.0,"doc: reflect documentation doesn't show examples - Possibly a continuation of #21601. https://golang.org/pkg/reflect/ doesn't show examples, while https://godoc.org/reflect does.",1,doc reflect documentation doesn t show examples possibly a continuation of doesn t show examples while does ,1 106232,11473393682.0,IssuesEvent,2020-02-09 22:53:00,golang/go,https://api.github.com/repos/golang/go,closed,wiki: rename FileTreeDocumentation,Documentation NeedsDecision,"I'd like to rename the FileTreeDocumentation page to GoTree. In alternative the name might simply be shortened to FileTree. ",1.0,"wiki: rename FileTreeDocumentation - I'd like to rename the FileTreeDocumentation page to GoTree. In alternative the name might simply be shortened to FileTree. ",1,wiki rename filetreedocumentation i d like to rename the filetreedocumentation page to gotree in alternative the name might simply be shortened to filetree ,1 42188,6969549022.0,IssuesEvent,2017-12-11 06:13:21,golang/go,https://api.github.com/repos/golang/go,closed,doc: go1.10.html states that i386/amd64 executables fail on NetBSD amd64,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? N/A ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? N/A ### What did you expect to see? Removed note that 32-bit applications are broken on 64-bit NetBSD kernel. ### What did you see instead? The reverse. The breakage was a regression on HEAD. Fix: ``` Module Name: src Committed By: christos Date: Thu Dec 7 16:22:22 UTC 2017 Modified Files: src/sys/arch/amd64/amd64: netbsd32_machdep.c Log Message: Keep fs/gs the same for the signal context; otherwise calling things like __lwp_getprivate_fast() from a signal handler (that uses %gs) die. Merge context building code. To generate a diff of this commit: cvs rdiff -u -r1.113 -r1.114 src/sys/arch/amd64/amd64/netbsd32_machdep.c ``` http://mail-index.netbsd.org/source-changes/2017/12/07/msg090270.html",1.0,"doc: go1.10.html states that i386/amd64 executables fail on NetBSD amd64 - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? N/A ### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? N/A ### What did you expect to see? Removed note that 32-bit applications are broken on 64-bit NetBSD kernel. ### What did you see instead? The reverse. The breakage was a regression on HEAD. Fix: ``` Module Name: src Committed By: christos Date: Thu Dec 7 16:22:22 UTC 2017 Modified Files: src/sys/arch/amd64/amd64: netbsd32_machdep.c Log Message: Keep fs/gs the same for the signal context; otherwise calling things like __lwp_getprivate_fast() from a signal handler (that uses %gs) die. Merge context building code. To generate a diff of this commit: cvs rdiff -u -r1.113 -r1.114 src/sys/arch/amd64/amd64/netbsd32_machdep.c ``` http://mail-index.netbsd.org/source-changes/2017/12/07/msg090270.html",1,doc html states that executables fail on netbsd please answer these questions before submitting your issue thanks what version of go are you using go version n a does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env n a what did you do n a what did you expect to see removed note that bit applications are broken on bit netbsd kernel what did you see instead the reverse the breakage was a regression on head fix module name src committed by christos date thu dec utc modified files src sys arch machdep c log message keep fs gs the same for the signal context otherwise calling things like lwp getprivate fast from a signal handler that uses gs die merge context building code to generate a diff of this commit cvs rdiff u src sys arch machdep c ,1 404271,27456528702.0,IssuesEvent,2023-03-02 21:53:12,golang/go,https://api.github.com/repos/golang/go,closed,net: macOS link of Go c-archive now requires -lresolv in 1.20,Documentation OS-Darwin WaitingForInfo NeedsInvestigation,"Go 1.20rc3. I tried to convert our application (@Tailscale) over to Go 1.20 but hit macOS compilation errors in Xcode for our target (a network extension) that links in Go code: ``` /Applications/Xcode-13.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-macos10.13 -isysroot /Applications/Xcode-13.4.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -L/Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/BuildProductsPath/Release -F/Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/BuildProductsPath/Release -filelist /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension.LinkFileList -exported_symbols_list IPNExtension/exported-symbols.exp -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @executable_path/../../../../Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension_lto.o -fapplication-extension -fobjc-link-runtime -L/Applications/Xcode-13.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension.swiftmodule -e _NSExtensionMain -lipn-go-arm64\ x86_64 -framework NetworkExtension -Xlinker -dependency_info -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension_dependency_info.dat -o /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/Binary/IPNExtension Undefined symbols for architecture arm64: ""_res_9_nsearch"", referenced from: _internal/syscall/unix.libresolv_res_9_nsearch_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ""_res_9_nclose"", referenced from: _internal/syscall/unix.libresolv_res_9_nclose_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ""_res_9_ninit"", referenced from: _internal/syscall/unix.libresolv_res_9_ninit_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ... The following build commands failed: Ld /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/Binary/IPNExtension normal arm64 (in target 'IPNExtension-macOS' from project 'IPN') ``` I assume this is fallout from https://tip.golang.org/doc/go1.20#cgo ... > On macOS, the net and os/user packages have been rewritten not to use cgo: the same code is now used for cgo and non-cgo builds as well as cross-compiled builds. Unfortunately I don't have a small easy repro. (Nothing is small or easy with Xcode) /cc @rsc @ianlancetaylor ",1.0,"net: macOS link of Go c-archive now requires -lresolv in 1.20 - Go 1.20rc3. I tried to convert our application (@Tailscale) over to Go 1.20 but hit macOS compilation errors in Xcode for our target (a network extension) that links in Go code: ``` /Applications/Xcode-13.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target arm64-apple-macos10.13 -isysroot /Applications/Xcode-13.4.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -L/Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/BuildProductsPath/Release -F/Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/BuildProductsPath/Release -filelist /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension.LinkFileList -exported_symbols_list IPNExtension/exported-symbols.exp -Xlinker -rpath -Xlinker /usr/lib/swift -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @executable_path/../../../../Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension_lto.o -fapplication-extension -fobjc-link-runtime -L/Applications/Xcode-13.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension.swiftmodule -e _NSExtensionMain -lipn-go-arm64\ x86_64 -framework NetworkExtension -Xlinker -dependency_info -Xlinker /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/IPNExtension_dependency_info.dat -o /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/Binary/IPNExtension Undefined symbols for architecture arm64: ""_res_9_nsearch"", referenced from: _internal/syscall/unix.libresolv_res_9_nsearch_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ""_res_9_nclose"", referenced from: _internal/syscall/unix.libresolv_res_9_nclose_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ""_res_9_ninit"", referenced from: _internal/syscall/unix.libresolv_res_9_ninit_trampoline.abi0 in libipn-go-arm64 x86_64.a(go.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ... The following build commands failed: Ld /Users/github-ci/Library/Developer/Xcode/DerivedData/IPN-dcmqhkiofztpxzcjkertpymoivvw/Build/Intermediates.noindex/ArchiveIntermediates/IPN-macOS/IntermediateBuildFilesPath/IPN.build/Release/IPNExtension-macOS.build/Objects-normal/arm64/Binary/IPNExtension normal arm64 (in target 'IPNExtension-macOS' from project 'IPN') ``` I assume this is fallout from https://tip.golang.org/doc/go1.20#cgo ... > On macOS, the net and os/user packages have been rewritten not to use cgo: the same code is now used for cgo and non-cgo builds as well as cross-compiled builds. Unfortunately I don't have a small easy repro. (Nothing is small or easy with Xcode) /cc @rsc @ianlancetaylor ",1,net macos link of go c archive now requires lresolv in go i tried to convert our application tailscale over to go but hit macos compilation errors in xcode for our target a network extension that links in go code applications xcode app contents developer toolchains xcodedefault xctoolchain usr bin clang target apple isysroot applications xcode app contents developer platforms macosx platform developer sdks sdk l users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos buildproductspath release f users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos buildproductspath release filelist users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal ipnextension linkfilelist exported symbols list ipnextension exported symbols exp xlinker rpath xlinker usr lib swift xlinker rpath xlinker executable path frameworks xlinker rpath xlinker executable path frameworks dead strip xlinker object path lto xlinker users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal ipnextension lto o fapplication extension fobjc link runtime l applications xcode app contents developer toolchains xcodedefault xctoolchain usr lib swift macosx l usr lib swift xlinker add ast path xlinker users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal ipnextension swiftmodule e nsextensionmain lipn go framework networkextension xlinker dependency info xlinker users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal ipnextension dependency info dat o users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal binary ipnextension undefined symbols for architecture res nsearch referenced from internal syscall unix libresolv res nsearch trampoline in libipn go a go o res nclose referenced from internal syscall unix libresolv res nclose trampoline in libipn go a go o res ninit referenced from internal syscall unix libresolv res ninit trampoline in libipn go a go o ld symbol s not found for architecture clang error linker command failed with exit code use v to see invocation the following build commands failed ld users github ci library developer xcode deriveddata ipn dcmqhkiofztpxzcjkertpymoivvw build intermediates noindex archiveintermediates ipn macos intermediatebuildfilespath ipn build release ipnextension macos build objects normal binary ipnextension normal in target ipnextension macos from project ipn i assume this is fallout from on macos the net and os user packages have been rewritten not to use cgo the same code is now used for cgo and non cgo builds as well as cross compiled builds unfortunately i don t have a small easy repro nothing is small or easy with xcode cc rsc ianlancetaylor ,1 55135,7962801155.0,IssuesEvent,2018-07-13 15:22:15,golang/go,https://api.github.com/repos/golang/go,opened,doc: add release notes for change in vet printf detection,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version devel +8a330454dc Fri Jul 13 03:53:00 2018 +0000 linux/amd64 ``` ### Does this issue reproduce with the latest release? No, working with Go tip. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/myitcv/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/tmp/tmp.sI0jAUcdXy"" GOPROXY="""" GORACE="""" GOROOT=""/home/myitcv/gos"" GOTMPDIR="""" GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" GOMOD="""" 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-build282886001=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? Not a bug, but a suggestion for a release note. Discovered whilst trying out the new `go` tool module support, upgrading https://github.com/gobuffalo/buffalo to be a Go module. ``` cd `mktemp -d` export GOPATH=$PWD mkdir -p src/example.com/hello cd src/example.com/hello cat < main.go package main import ""fmt"" type T struct{} func (t *T) String(s string, args ...interface{}) string { v := s if len(args) > 0 { v = fmt.Sprintf(s, args...) } return v } func main() { var t *T t.String(""<%="") } EOD go test ``` ### What did you expect to see? A release note at https://tip.golang.org/doc/go1.11 giving details about the new `*printf` detection that now reports the above as an error: ``` # example.com/hello ./main.go:17: T.String format %= has unknown verb = ``` ### What did you see instead? No release notes 😄 Not critical, but I suspect this will catch out a few people. Buffalo had a number of instances because of the templating language, Plush, it uses. **/cc** @rsc ",1.0,"doc: add release notes for change in vet printf detection - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version devel +8a330454dc Fri Jul 13 03:53:00 2018 +0000 linux/amd64 ``` ### Does this issue reproduce with the latest release? No, working with Go tip. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/myitcv/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/tmp/tmp.sI0jAUcdXy"" GOPROXY="""" GORACE="""" GOROOT=""/home/myitcv/gos"" GOTMPDIR="""" GOTOOLDIR=""/home/myitcv/gos/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" GOMOD="""" 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-build282886001=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? Not a bug, but a suggestion for a release note. Discovered whilst trying out the new `go` tool module support, upgrading https://github.com/gobuffalo/buffalo to be a Go module. ``` cd `mktemp -d` export GOPATH=$PWD mkdir -p src/example.com/hello cd src/example.com/hello cat < main.go package main import ""fmt"" type T struct{} func (t *T) String(s string, args ...interface{}) string { v := s if len(args) > 0 { v = fmt.Sprintf(s, args...) } return v } func main() { var t *T t.String(""<%="") } EOD go test ``` ### What did you expect to see? A release note at https://tip.golang.org/doc/go1.11 giving details about the new `*printf` detection that now reports the above as an error: ``` # example.com/hello ./main.go:17: T.String format %= has unknown verb = ``` ### What did you see instead? No release notes 😄 Not critical, but I suspect this will catch out a few people. Buffalo had a number of instances because of the templating language, Plush, it uses. **/cc** @rsc ",1,doc add release notes for change in vet printf detection please answer these questions before submitting your issue thanks what version of go are you using go version go version devel fri jul linux does this issue reproduce with the latest release no working with go tip what operating system and processor architecture are you using go env goarch gobin gocache home myitcv cache go build goexe gohostarch gohostos linux goos linux gopath tmp tmp goproxy gorace goroot home myitcv gos gotmpdir gotooldir home myitcv gos pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do not a bug but a suggestion for a release note discovered whilst trying out the new go tool module support upgrading to be a go module cd mktemp d export gopath pwd mkdir p src example com hello cd src example com hello cat main go package main import fmt type t struct func t t string s string args interface string v s if len args v fmt sprintf s args return v func main var t t t string eod go test what did you expect to see a release note at giving details about the new printf detection that now reports the above as an error example com hello main go t string format has unknown verb what did you see instead no release notes 😄 not critical but i suspect this will catch out a few people buffalo had a number of instances because of the templating language plush it uses cc rsc ,1 20338,4537991455.0,IssuesEvent,2016-09-09 03:47:18,golang/go,https://api.github.com/repos/golang/go,closed,net/http/cookiejar: adding example,Documentation,"I've prepared two versions of examples for `net/http/cookiejar`, [Version 1](https://play.golang.org/p/xz74yExiHG) makes actual HTTP requests to www.google.com and https://golang.org/doc/tos.html and prints out cookies. *Pro:* It keeps example code small *Con:* One needs internet access for this test to pass, it takes `0.59s` on my MacBook Pro. Time that adds up over many test runs. [Version 2](https://play.golang.org/p/DTxy75fZKR) uses a dummy transport that writes `COOKIE!` cookie to response. *Pro:* Tests run very quickly, about `0.00s` on same machine. *Con:* Example adds additional code, which looks rather out of place in context of an example. I've not see any other example creating a separate transport. Any suggestions on how to proceed? ",1.0,"net/http/cookiejar: adding example - I've prepared two versions of examples for `net/http/cookiejar`, [Version 1](https://play.golang.org/p/xz74yExiHG) makes actual HTTP requests to www.google.com and https://golang.org/doc/tos.html and prints out cookies. *Pro:* It keeps example code small *Con:* One needs internet access for this test to pass, it takes `0.59s` on my MacBook Pro. Time that adds up over many test runs. [Version 2](https://play.golang.org/p/DTxy75fZKR) uses a dummy transport that writes `COOKIE!` cookie to response. *Pro:* Tests run very quickly, about `0.00s` on same machine. *Con:* Example adds additional code, which looks rather out of place in context of an example. I've not see any other example creating a separate transport. Any suggestions on how to proceed? ",1,net http cookiejar adding example i ve prepared two versions of examples for net http cookiejar makes actual http requests to and and prints out cookies pro it keeps example code small con one needs internet access for this test to pass it takes on my macbook pro time that adds up over many test runs uses a dummy transport that writes cookie cookie to response pro tests run very quickly about on same machine con example adds additional code which looks rather out of place in context of an example i ve not see any other example creating a separate transport any suggestions on how to proceed ,1 59289,8356255540.0,IssuesEvent,2018-10-02 17:57:17,golang/go,https://api.github.com/repos/golang/go,closed,regexp: document that FindReaderIndex reads past the match in some cases,Documentation NeedsFix help wanted,"### What did you do? https://play.golang.org/p/aKIosxo6aP ``` func main() { br := bytes.NewReader([]byte(""abaab"")) re := regexp.MustCompile(""a"") for i:=0;;i++{ q := re.FindReaderIndex(br) fmt.Printf(""step %d q=%v\n"",i,q) if q==nil{ break } } } ``` ### What did you expect to see? ``` step 0 q=[0 1] step 1 q=[1 2] step 2 q=[0 1] ``` ### What did you see instead? ``` step 0 q=[0 1] step 1 q=[] ``` I remember reading somewhere in the godoc that the readers can eat the underlying runes to an arbitrarily degree, but it's not clear from the documentation for FindReaderIndex that this is possible. ``` func (re *Regexp) FindReaderIndex(r io.RuneReader) (loc []int) FindReaderIndex returns a two-element slice of integers defining the location of the leftmost match of the regular expression in text read from the RuneReader. The match text was found in the input stream at byte offset loc[0] through loc[1]-1. A return value of nil indicates no match. ``` ### Workaround I had to manually rewind the reader. This solution was not obvious at first, maybe a short addendum to the package function will clarify that it the function may skip matches. https://play.golang.org/p/J9ubm_43wW ",1.0,"regexp: document that FindReaderIndex reads past the match in some cases - ### What did you do? https://play.golang.org/p/aKIosxo6aP ``` func main() { br := bytes.NewReader([]byte(""abaab"")) re := regexp.MustCompile(""a"") for i:=0;;i++{ q := re.FindReaderIndex(br) fmt.Printf(""step %d q=%v\n"",i,q) if q==nil{ break } } } ``` ### What did you expect to see? ``` step 0 q=[0 1] step 1 q=[1 2] step 2 q=[0 1] ``` ### What did you see instead? ``` step 0 q=[0 1] step 1 q=[] ``` I remember reading somewhere in the godoc that the readers can eat the underlying runes to an arbitrarily degree, but it's not clear from the documentation for FindReaderIndex that this is possible. ``` func (re *Regexp) FindReaderIndex(r io.RuneReader) (loc []int) FindReaderIndex returns a two-element slice of integers defining the location of the leftmost match of the regular expression in text read from the RuneReader. The match text was found in the input stream at byte offset loc[0] through loc[1]-1. A return value of nil indicates no match. ``` ### Workaround I had to manually rewind the reader. This solution was not obvious at first, maybe a short addendum to the package function will clarify that it the function may skip matches. https://play.golang.org/p/J9ubm_43wW ",1,regexp document that findreaderindex reads past the match in some cases what did you do func main br bytes newreader byte abaab re regexp mustcompile a for i i q re findreaderindex br fmt printf step d q v n i q if q nil break what did you expect to see step q step q step q what did you see instead step q step q i remember reading somewhere in the godoc that the readers can eat the underlying runes to an arbitrarily degree but it s not clear from the documentation for findreaderindex that this is possible func re regexp findreaderindex r io runereader loc int findreaderindex returns a two element slice of integers defining the location of the leftmost match of the regular expression in text read from the runereader the match text was found in the input stream at byte offset loc through loc a return value of nil indicates no match workaround i had to manually rewind the reader this solution was not obvious at first maybe a short addendum to the package function will clarify that it the function may skip matches ,1 431060,30215611768.0,IssuesEvent,2023-07-05 15:22:48,golang/go,https://api.github.com/repos/golang/go,closed,runtime/metrics: update documentation w.r.t. stack_sys,Documentation NeedsFix compiler/runtime,"### What version of Go are you using (`go version`)? ``` $ go version go1.20 ``` ### Issue The documentation related to stack memory in `MemStats` says: ``` // StackInuse is bytes in stack spans. // // In-use stack spans have at least one stack in them. These // spans can only be used for other stacks of the same size. // // There is no StackIdle because unused stack spans are // returned to the heap (and hence counted toward HeapIdle). StackInuse [uint64](https://pkg.go.dev/builtin#uint64) // StackSys is bytes of stack memory obtained from the OS. // // StackSys is StackInuse, plus any memory obtained directly // from the OS for OS thread stacks (which should be minimal). StackSys [uint64](https://pkg.go.dev/builtin#uint64) ``` And, in runtime/metrics, there is also: ``` /memory/classes/heap/stacks:bytes Memory allocated from the heap that is reserved for stack space, whether or not it is currently in-use. /memory/classes/os-stacks:bytes Stack memory allocated by the underlying operating system. ``` But this is at best confusing and at worst incorrect. Quoting @mknyszek from a recent conversation: > if a program is pure Go, we use newosproc0 to allocate the first stack. this accounts to stacks_sys, which funnels into StackSys. all other system stacks are allocated from the same pool as goroutine stacks (basically, StackInuse). 8192 bytes. if a program is cgo, then we use _cgo_sys_thread_create for the first thread which is the platform C library thread creation. we use this for every new stack, too. we don't control the size of those stacks at all, and we also don't account for them AFAICT. this is how we ensure that calls into C are fine: all system stacks are basically provided by pthreads. This means: 1. The behaviour is different between pure Go and cgo programs, which should be mentioned. 2. Even for pure Go programs, stacks for syscalls are generally allocated from `stack_inuse` (in cgo programs this is not tracked at all). This different behaviour should be called out in the docs. ",1.0,"runtime/metrics: update documentation w.r.t. stack_sys - ### What version of Go are you using (`go version`)? ``` $ go version go1.20 ``` ### Issue The documentation related to stack memory in `MemStats` says: ``` // StackInuse is bytes in stack spans. // // In-use stack spans have at least one stack in them. These // spans can only be used for other stacks of the same size. // // There is no StackIdle because unused stack spans are // returned to the heap (and hence counted toward HeapIdle). StackInuse [uint64](https://pkg.go.dev/builtin#uint64) // StackSys is bytes of stack memory obtained from the OS. // // StackSys is StackInuse, plus any memory obtained directly // from the OS for OS thread stacks (which should be minimal). StackSys [uint64](https://pkg.go.dev/builtin#uint64) ``` And, in runtime/metrics, there is also: ``` /memory/classes/heap/stacks:bytes Memory allocated from the heap that is reserved for stack space, whether or not it is currently in-use. /memory/classes/os-stacks:bytes Stack memory allocated by the underlying operating system. ``` But this is at best confusing and at worst incorrect. Quoting @mknyszek from a recent conversation: > if a program is pure Go, we use newosproc0 to allocate the first stack. this accounts to stacks_sys, which funnels into StackSys. all other system stacks are allocated from the same pool as goroutine stacks (basically, StackInuse). 8192 bytes. if a program is cgo, then we use _cgo_sys_thread_create for the first thread which is the platform C library thread creation. we use this for every new stack, too. we don't control the size of those stacks at all, and we also don't account for them AFAICT. this is how we ensure that calls into C are fine: all system stacks are basically provided by pthreads. This means: 1. The behaviour is different between pure Go and cgo programs, which should be mentioned. 2. Even for pure Go programs, stacks for syscalls are generally allocated from `stack_inuse` (in cgo programs this is not tracked at all). This different behaviour should be called out in the docs. ",1,runtime metrics update documentation w r t stack sys what version of go are you using go version go version issue the documentation related to stack memory in memstats says stackinuse is bytes in stack spans in use stack spans have at least one stack in them these spans can only be used for other stacks of the same size there is no stackidle because unused stack spans are returned to the heap and hence counted toward heapidle stackinuse stacksys is bytes of stack memory obtained from the os stacksys is stackinuse plus any memory obtained directly from the os for os thread stacks which should be minimal stacksys and in runtime metrics there is also memory classes heap stacks bytes memory allocated from the heap that is reserved for stack space whether or not it is currently in use memory classes os stacks bytes stack memory allocated by the underlying operating system but this is at best confusing and at worst incorrect quoting mknyszek from a recent conversation if a program is pure go we use to allocate the first stack this accounts to stacks sys which funnels into stacksys all other system stacks are allocated from the same pool as goroutine stacks basically stackinuse bytes if a program is cgo then we use cgo sys thread create for the first thread which is the platform c library thread creation we use this for every new stack too we don t control the size of those stacks at all and we also don t account for them afaict this is how we ensure that calls into c are fine all system stacks are basically provided by pthreads this means the behaviour is different between pure go and cgo programs which should be mentioned even for pure go programs stacks for syscalls are generally allocated from stack inuse in cgo programs this is not tracked at all this different behaviour should be called out in the docs ,1 173131,14403475725.0,IssuesEvent,2020-12-03 16:06:09,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document log changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
log

TODO: https://golang.org/cl/264460: expose std via new Default function

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document log changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
log

TODO: https://golang.org/cl/264460: expose std via new Default function

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document log changes for go as of filing this issue the contained the following html log todo a href expose std via new default function per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 20172,4511828037.0,IssuesEvent,2016-09-03 08:20:39,golang/go,https://api.github.com/repos/golang/go,opened,time: document when UnixNano overflows,Documentation,"When I use the UnixNano method, I have to do some math to discover that the value will overflow in the year 2262 (I never seem to remember this). While 2262 is very far out for most applications, perhaps we should document that is the maximum representable date as an int64 since Unix epoch? I dont feel a need to do a similar statement in the Unix method since the overflow date for that is beyond anything reasonable.",1.0,"time: document when UnixNano overflows - When I use the UnixNano method, I have to do some math to discover that the value will overflow in the year 2262 (I never seem to remember this). While 2262 is very far out for most applications, perhaps we should document that is the maximum representable date as an int64 since Unix epoch? I dont feel a need to do a similar statement in the Unix method since the overflow date for that is beyond anything reasonable.",1,time document when unixnano overflows when i use the unixnano method i have to do some math to discover that the value will overflow in the year i never seem to remember this while is very far out for most applications perhaps we should document that is the maximum representable date as an since unix epoch i dont feel a need to do a similar statement in the unix method since the overflow date for that is beyond anything reasonable ,1 294608,22157971082.0,IssuesEvent,2022-06-04 03:57:40,golang/go,https://api.github.com/repos/golang/go,closed,documentation: Go internal abi specification document alignment confusion,Documentation NeedsInvestigation,"Hello everyone! I hope that this is the right place to raise this issue: I have read through the ""Go internal ABI specification"" (src/cmd/compile/internal-abi.md) and have studied the excellent, thorough discussion of the definition of the alignment of sequences (of which a `struct` is a special case) and the alignment of built-in types. I am curious, however, how that squares with the following statement > On ARM, 386, and 32-bit MIPS, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned. from https://pkg.go.dev/sync/atomic#pkg-note-BUG. Nothing in the ""Go internal ABI specification"" seems to indicate that there is a special case for these architectures. I was just wondering if this is is because the representation made by https://pkg.go.dev/sync/atomic#pkg-note-BUG concerns the ""public"" ABI and would supersede the definitions/algorithms in the internal ABI in this case? Or, is it simply something that is just out of date with a (admittedly internal) piece of documentation. If it is, I would be glad to submit a patch for the ""Go internal ABI specification"" document to bring it up to date. That document is such a helpful, interesting read for so many reasons and one of the main reasons why I really enjoy working with this language! Thanks for everything! Will cc @danscales ",1.0,"documentation: Go internal abi specification document alignment confusion - Hello everyone! I hope that this is the right place to raise this issue: I have read through the ""Go internal ABI specification"" (src/cmd/compile/internal-abi.md) and have studied the excellent, thorough discussion of the definition of the alignment of sequences (of which a `struct` is a special case) and the alignment of built-in types. I am curious, however, how that squares with the following statement > On ARM, 386, and 32-bit MIPS, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a variable or in an allocated struct, array, or slice can be relied upon to be 64-bit aligned. from https://pkg.go.dev/sync/atomic#pkg-note-BUG. Nothing in the ""Go internal ABI specification"" seems to indicate that there is a special case for these architectures. I was just wondering if this is is because the representation made by https://pkg.go.dev/sync/atomic#pkg-note-BUG concerns the ""public"" ABI and would supersede the definitions/algorithms in the internal ABI in this case? Or, is it simply something that is just out of date with a (admittedly internal) piece of documentation. If it is, I would be glad to submit a patch for the ""Go internal ABI specification"" document to bring it up to date. That document is such a helpful, interesting read for so many reasons and one of the main reasons why I really enjoy working with this language! Thanks for everything! Will cc @danscales ",1,documentation go internal abi specification document alignment confusion hello everyone i hope that this is the right place to raise this issue i have read through the go internal abi specification src cmd compile internal abi md and have studied the excellent thorough discussion of the definition of the alignment of sequences of which a struct is a special case and the alignment of built in types i am curious however how that squares with the following statement on arm and bit mips it is the caller s responsibility to arrange for bit alignment of bit words accessed atomically the first word in a variable or in an allocated struct array or slice can be relied upon to be bit aligned from nothing in the go internal abi specification seems to indicate that there is a special case for these architectures i was just wondering if this is is because the representation made by concerns the public abi and would supersede the definitions algorithms in the internal abi in this case or is it simply something that is just out of date with a admittedly internal piece of documentation if it is i would be glad to submit a patch for the go internal abi specification document to bring it up to date that document is such a helpful interesting read for so many reasons and one of the main reasons why i really enjoy working with this language thanks for everything will cc danscales ,1 309957,26687544727.0,IssuesEvent,2023-01-26 23:43:41,golang/go,https://api.github.com/repos/golang/go,closed,x/vuln/cmd/govulncheck: Print tests consistently failing on `js/wasm`,Testing NeedsFix OS-JS vulncheck or vulndb x/vuln,"https://build.golang.org/log/ade065c29b6482e89b7ea3233ef1bd979511d0ce: ``` --- FAIL: TestPrintTextNoVulns (0.00s) print_test.go:216: mismatch (-want, +got): string( - ""No vulnerabilities found.\n\n=== Informational ===\n\nFound 1 vulnerability in packages that you import, but there are no call\nstacks leading to the use of this vulnerability. You may not need to\ntake any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/go""..., + """", ) --- FAIL: TestPrintTextSource (0.00s) print_test.go:282: mismatch (-want, +got): string( - ""Your code is affected by 1 vulnerability from 1 module.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0.0.1\n Fixed in: golang.org/""..., + """", ) --- FAIL: TestPrintTextBinary (0.00s) print_test.go:338: mismatch (-want, +got): string( - ""Your code is affected by 2 vulnerabilities from 1 module and the Go standard library.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0""..., + """", ) --- FAIL: TestPrintTextMultiModuleAndStacks (0.00s) print_test.go:400: mismatch (-want, +got): string( - ""Your code is affected by 1 vulnerability from 2 modules.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0.0.1\n Fixed in: golang.org""..., + """", ) FAIL FAIL golang.org/x/vuln/cmd/govulncheck 7.572s ``` The failing tests were added in [CL 462795](https://go.dev/cl/462795) (attn @zpavlinovic @jba)",1.0,"x/vuln/cmd/govulncheck: Print tests consistently failing on `js/wasm` - https://build.golang.org/log/ade065c29b6482e89b7ea3233ef1bd979511d0ce: ``` --- FAIL: TestPrintTextNoVulns (0.00s) print_test.go:216: mismatch (-want, +got): string( - ""No vulnerabilities found.\n\n=== Informational ===\n\nFound 1 vulnerability in packages that you import, but there are no call\nstacks leading to the use of this vulnerability. You may not need to\ntake any action. See https://pkg.go.dev/golang.org/x/vuln/cmd/go""..., + """", ) --- FAIL: TestPrintTextSource (0.00s) print_test.go:282: mismatch (-want, +got): string( - ""Your code is affected by 1 vulnerability from 1 module.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0.0.1\n Fixed in: golang.org/""..., + """", ) --- FAIL: TestPrintTextBinary (0.00s) print_test.go:338: mismatch (-want, +got): string( - ""Your code is affected by 2 vulnerabilities from 1 module and the Go standard library.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0""..., + """", ) --- FAIL: TestPrintTextMultiModuleAndStacks (0.00s) print_test.go:400: mismatch (-want, +got): string( - ""Your code is affected by 1 vulnerability from 2 modules.\n\nVulnerability #1: GO-0000-0001\n Third-party vulnerability\n\n More info: https://pkg.go.dev/vuln/GO-0000-0001\n\n Module: golang.org/vmod\n Found in: golang.org/vmod@v0.0.1\n Fixed in: golang.org""..., + """", ) FAIL FAIL golang.org/x/vuln/cmd/govulncheck 7.572s ``` The failing tests were added in [CL 462795](https://go.dev/cl/462795) (attn @zpavlinovic @jba)",0,x vuln cmd govulncheck print tests consistently failing on js wasm fail testprinttextnovulns print test go mismatch want got string no vulnerabilities found n n informational n nfound vulnerability in packages that you import but there are no call nstacks leading to the use of this vulnerability you may not need to ntake any action see fail testprinttextsource print test go mismatch want got string your code is affected by vulnerability from module n nvulnerability go n third party vulnerability n n more info module golang org vmod n found in golang org vmod n fixed in golang org fail testprinttextbinary print test go mismatch want got string your code is affected by vulnerabilities from module and the go standard library n nvulnerability go n third party vulnerability n n more info module golang org vmod n found in golang org vmod fail testprinttextmultimoduleandstacks print test go mismatch want got string your code is affected by vulnerability from modules n nvulnerability go n third party vulnerability n n more info module golang org vmod n found in golang org vmod n fixed in golang org fail fail golang org x vuln cmd govulncheck the failing tests were added in attn zpavlinovic jba ,0 66504,8948912694.0,IssuesEvent,2019-01-25 04:58:43,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/compile, cmd/link: doc: docs are incomplete",Documentation NeedsFix help wanted,"The documentation for those commands on the website ([compile](https://tip.golang.org/cmd/compile/), [link](https://tip.golang.org/cmd/link/)) lacks certain flags. For example, compile's page is missing the very useful `-m` flag, and link's page -- `-a`, `-buildid`, and others. (Ideally, those sections would be generated from `go tool (compile|link) -h` output, but I don't know enough details to propose a full solution.)",1.0,"cmd/compile, cmd/link: doc: docs are incomplete - The documentation for those commands on the website ([compile](https://tip.golang.org/cmd/compile/), [link](https://tip.golang.org/cmd/link/)) lacks certain flags. For example, compile's page is missing the very useful `-m` flag, and link's page -- `-a`, `-buildid`, and others. (Ideally, those sections would be generated from `go tool (compile|link) -h` output, but I don't know enough details to propose a full solution.)",1,cmd compile cmd link doc docs are incomplete the documentation for those commands on the website lacks certain flags for example compile s page is missing the very useful m flag and link s page a buildid and others ideally those sections would be generated from go tool compile link h output but i don t know enough details to propose a full solution ,1 23210,7298859585.0,IssuesEvent,2018-02-26 18:15:30,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gerritbot: editing a title or description should update the Gerrit change,Builders NeedsFix,"In [this change](https://go-review.googlesource.com/c/go/+/92997) the title needs to be adjusted, but it won't get imported unless the PR branch's HEAD SHA changes. We should detect differences in the title and import if need be.",1.0,"x/build/cmd/gerritbot: editing a title or description should update the Gerrit change - In [this change](https://go-review.googlesource.com/c/go/+/92997) the title needs to be adjusted, but it won't get imported unless the PR branch's HEAD SHA changes. We should detect differences in the title and import if need be.",0,x build cmd gerritbot editing a title or description should update the gerrit change in the title needs to be adjusted but it won t get imported unless the pr branch s head sha changes we should detect differences in the title and import if need be ,0 70,2491265635.0,IssuesEvent,2015-01-03 06:41:43,golang/go,https://api.github.com/repos/golang/go,reopened,net: TestPacketConn flaky,accepted priority-later release-none repo-main testing,"
TestPacketConn seems to be flaky. It has been for a while.

TestPacketConn typically runs in milliseconds, which makes the fact that the test
sometimes takes up to 8 seconds in some runs quite strange.

29 March:

--- FAIL: TestPacketConn-37 (8.73 seconds)
packetconn_test.go:101: PacketConn.WriteTo failed: write unixgram: i/o timeout

7 May:

go version devel +1638d2adb665 Mon May 06 17:34:17 2013 -0700 linux/386
=== RUN TestTCPClose-4
--- PASS: TestTCPClose-4 (0.01 seconds)
=== RUN TestPacketConn-4
--- FAIL: TestPacketConn-4 (1.57 seconds)
packetconn_test.go:112: PacketConn.ReadFrom failed: read unixgram /tmp/nettest093076375:
i/o timeout
=== RUN TestConnAndPacketConn-4
--- PASS: TestConnAndPacketConn-4 (0.06 seconds)

15 May:

go version devel +f51b5497fa4c Wed May 15 04:19:19 2013 +0800 linux/amd64
--- FAIL: TestPacketConn-23 (4.53 seconds)
packetconn_test.go:101: PacketConn.WriteTo failed: write unixgram: i/o timeout
",1.0,"net: TestPacketConn flaky - 
TestPacketConn seems to be flaky. It has been for a while.

TestPacketConn typically runs in milliseconds, which makes the fact that the test
sometimes takes up to 8 seconds in some runs quite strange.

29 March:

--- FAIL: TestPacketConn-37 (8.73 seconds)
packetconn_test.go:101: PacketConn.WriteTo failed: write unixgram: i/o timeout

7 May:

go version devel +1638d2adb665 Mon May 06 17:34:17 2013 -0700 linux/386
=== RUN TestTCPClose-4
--- PASS: TestTCPClose-4 (0.01 seconds)
=== RUN TestPacketConn-4
--- FAIL: TestPacketConn-4 (1.57 seconds)
packetconn_test.go:112: PacketConn.ReadFrom failed: read unixgram /tmp/nettest093076375:
i/o timeout
=== RUN TestConnAndPacketConn-4
--- PASS: TestConnAndPacketConn-4 (0.06 seconds)

15 May:

go version devel +f51b5497fa4c Wed May 15 04:19:19 2013 +0800 linux/amd64
--- FAIL: TestPacketConn-23 (4.53 seconds)
packetconn_test.go:101: PacketConn.WriteTo failed: write unixgram: i/o timeout
",0,net testpacketconn flaky testpacketconn seems to be flaky it has been for a while testpacketconn typically runs in milliseconds which makes the fact that the test sometimes takes up to seconds in some runs quite strange march fail testpacketconn seconds packetconn test go packetconn writeto failed write unixgram i o timeout may go version devel mon may linux run testtcpclose pass testtcpclose seconds run testpacketconn fail testpacketconn seconds packetconn test go packetconn readfrom failed read unixgram tmp i o timeout run testconnandpacketconn pass testconnandpacketconn seconds may go version devel wed may linux fail testpacketconn seconds packetconn test go packetconn writeto failed write unixgram i o timeout ,0 14630,3870275812.0,IssuesEvent,2016-04-11 02:06:33,golang/go,https://api.github.com/repos/golang/go,opened,net: use IPv4/IPv6 reserved address blocks for documentation,Documentation,"There are reserved address blocks for documentation; https://tools.ietf.org/html/rfc5737 and https://tools.ietf.org/html/rfc3849. It'd be better to use them for documentation updates. - IPv4 address block for doc: 192.0.2.0/24 - IPv6 address block for doc: 2001:db8::/32 (also see https://tools.ietf.org/html/rfc5952)",1.0,"net: use IPv4/IPv6 reserved address blocks for documentation - There are reserved address blocks for documentation; https://tools.ietf.org/html/rfc5737 and https://tools.ietf.org/html/rfc3849. It'd be better to use them for documentation updates. - IPv4 address block for doc: 192.0.2.0/24 - IPv6 address block for doc: 2001:db8::/32 (also see https://tools.ietf.org/html/rfc5952)",1,net use reserved address blocks for documentation there are reserved address blocks for documentation and it d be better to use them for documentation updates address block for doc address block for doc also see ,1 56257,8059339284.0,IssuesEvent,2018-08-02 21:34:55,golang/go,https://api.github.com/repos/golang/go,closed,encoding/xml: bulleted lists badly formatted in documentation,Documentation NeedsFix help wanted,"The bulleted lists in the doc comments for Marshal, Unmarshal, and perhaps others are indented in a way that confuses the formatter for golang.org/pkg. (It thinks they're code instead of prose.) ![screenshot 2018-08-02 at 16 42 16](https://user-images.githubusercontent.com/5200974/43610070-46188316-9673-11e8-9f3b-f9314c1451e4.png) ",1.0,"encoding/xml: bulleted lists badly formatted in documentation - The bulleted lists in the doc comments for Marshal, Unmarshal, and perhaps others are indented in a way that confuses the formatter for golang.org/pkg. (It thinks they're code instead of prose.) ![screenshot 2018-08-02 at 16 42 16](https://user-images.githubusercontent.com/5200974/43610070-46188316-9673-11e8-9f3b-f9314c1451e4.png) ",1,encoding xml bulleted lists badly formatted in documentation the bulleted lists in the doc comments for marshal unmarshal and perhaps others are indented in a way that confuses the formatter for golang org pkg it thinks they re code instead of prose ,1 50170,7571077201.0,IssuesEvent,2018-04-23 11:01:45,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/ssh/agent: broken link in documentation,Documentation NeedsFix,"The following reference link in the package documentation is broken: [PROTOCOL.agent]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD",1.0,"x/crypto/ssh/agent: broken link in documentation - The following reference link in the package documentation is broken: [PROTOCOL.agent]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD",1,x crypto ssh agent broken link in documentation the following reference link in the package documentation is broken ,1 50503,7607023924.0,IssuesEvent,2018-04-30 15:10:43,golang/go,https://api.github.com/repos/golang/go,closed,"Brand Book: Instead of the RGB color code for Pantone 669 C, the Fuchsia code is listed",Documentation,"### What did you do? I took a look at the Go [Brand Book](https://storage.googleapis.com/golang-assets/go-brand-book-v1.0.pdf) and saw an incorrect color code on page 16. ### What did you expect to see? Under color [Pantone 669 C](https://www.pantone.com/color-finder/669-C) (under the ""More colors"" section on page 16), I expected to see the correct RGB color code, which is `63, 42, 86`. ### What did you see instead? Instead, I saw the RGB code `200, 50, 98` listed underneath, which is the RGB code for Fuchsia. ",1.0,"Brand Book: Instead of the RGB color code for Pantone 669 C, the Fuchsia code is listed - ### What did you do? I took a look at the Go [Brand Book](https://storage.googleapis.com/golang-assets/go-brand-book-v1.0.pdf) and saw an incorrect color code on page 16. ### What did you expect to see? Under color [Pantone 669 C](https://www.pantone.com/color-finder/669-C) (under the ""More colors"" section on page 16), I expected to see the correct RGB color code, which is `63, 42, 86`. ### What did you see instead? Instead, I saw the RGB code `200, 50, 98` listed underneath, which is the RGB code for Fuchsia. ",1,brand book instead of the rgb color code for pantone c the fuchsia code is listed what did you do i took a look at the go and saw an incorrect color code on page what did you expect to see under color under the more colors section on page i expected to see the correct rgb color code which is what did you see instead instead i saw the rgb code listed underneath which is the rgb code for fuchsia ,1 28559,5515129008.0,IssuesEvent,2017-03-17 16:40:47,golang/go,https://api.github.com/repos/golang/go,opened,"doc: figure out, document amd64 minimum requirements",Documentation NeedsDecision,"In https://golang.org/cl/38320, @khr adds POPCOUNT intrinsics for amd64. I realize that our https://golang.org/wiki/MinimumRequirements doesn't say anything about GOARCH=amd64. (only 386) Which version of amd64 do we assume? Decide and document. /cc @randall77 @ianlancetaylor @rsc @mdempsky @josharian @minux @cherrymui @aclements ",1.0,"doc: figure out, document amd64 minimum requirements - In https://golang.org/cl/38320, @khr adds POPCOUNT intrinsics for amd64. I realize that our https://golang.org/wiki/MinimumRequirements doesn't say anything about GOARCH=amd64. (only 386) Which version of amd64 do we assume? Decide and document. /cc @randall77 @ianlancetaylor @rsc @mdempsky @josharian @minux @cherrymui @aclements ",1,doc figure out document minimum requirements in khr adds popcount intrinsics for i realize that our doesn t say anything about goarch only which version of do we assume decide and document cc ianlancetaylor rsc mdempsky josharian minux cherrymui aclements ,1 40847,6872828676.0,IssuesEvent,2017-11-18 01:49:30,golang/go,https://api.github.com/repos/golang/go,closed,builtin: update documentation on builtin `make`,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin amd64 ### 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. read the documentation on the make builtin (https://golang.org/pkg/builtin/#make) ### What did you expect to see? An explanation that specifying the capacity for a slice means that go will allocate an array big enough to hold that capacity without any resizing. (After digging around the source code, I found this to be true) ### What did you see instead? Ambiguous comment: ``` // Slice: The size specifies the length. The capacity of the slice is // equal to its length. A second integer argument may be provided to // specify a different capacity; it must be no smaller than the // length, so make([]int, 0, 10) allocates a slice of length 0 and // capacity 10. ``` ### Proposed Fix Update this section of the comment to read: ``` // Slice: The size specifies the length. The capacity of the slice is // equal to its length. A second integer argument may be provided to // specify a different capacity; it must be no smaller than the // length, so make([]int, 0, 10) allocates an underlying array of size 10 // and returns a slice of length 0 and capacity 10 that is backed by this // underlying array. ```",1.0,"builtin: update documentation on builtin `make` - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin amd64 ### 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. read the documentation on the make builtin (https://golang.org/pkg/builtin/#make) ### What did you expect to see? An explanation that specifying the capacity for a slice means that go will allocate an array big enough to hold that capacity without any resizing. (After digging around the source code, I found this to be true) ### What did you see instead? Ambiguous comment: ``` // Slice: The size specifies the length. The capacity of the slice is // equal to its length. A second integer argument may be provided to // specify a different capacity; it must be no smaller than the // length, so make([]int, 0, 10) allocates a slice of length 0 and // capacity 10. ``` ### Proposed Fix Update this section of the comment to read: ``` // Slice: The size specifies the length. The capacity of the slice is // equal to its length. A second integer argument may be provided to // specify a different capacity; it must be no smaller than the // length, so make([]int, 0, 10) allocates an underlying array of size 10 // and returns a slice of length 0 and capacity 10 that is backed by this // underlying array. ```",1,builtin update documentation on builtin make please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env darwin 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 read the documentation on the make builtin what did you expect to see an explanation that specifying the capacity for a slice means that go will allocate an array big enough to hold that capacity without any resizing after digging around the source code i found this to be true what did you see instead ambiguous comment slice the size specifies the length the capacity of the slice is equal to its length a second integer argument may be provided to specify a different capacity it must be no smaller than the length so make int allocates a slice of length and capacity proposed fix update this section of the comment to read slice the size specifies the length the capacity of the slice is equal to its length a second integer argument may be provided to specify a different capacity it must be no smaller than the length so make int allocates an underlying array of size and returns a slice of length and capacity that is backed by this underlying array ,1 52820,7786242441.0,IssuesEvent,2018-06-06 18:19:10,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: DB documentation should mention DB.Conn(),Documentation NeedsFix help wanted,"https://golang.org/pkg/database/sql/#DB currently states: > If the database has a concept of per-connection state, such state can only be reliably observed within a transaction. This is no longer true: DB.Conn() was added to allow one to have a per-connection state without using transactions. DB documentation should be updated.",1.0,"database/sql: DB documentation should mention DB.Conn() - https://golang.org/pkg/database/sql/#DB currently states: > If the database has a concept of per-connection state, such state can only be reliably observed within a transaction. This is no longer true: DB.Conn() was added to allow one to have a per-connection state without using transactions. DB documentation should be updated.",1,database sql db documentation should mention db conn currently states if the database has a concept of per connection state such state can only be reliably observed within a transaction this is no longer true db conn was added to allow one to have a per connection state without using transactions db documentation should be updated ,1 97516,28310494543.0,IssuesEvent,2023-04-10 14:59:55,golang/go,https://api.github.com/repos/golang/go,reopened,all: test failures with `device not configured`,Builders NeedsInvestigation,"``` #!watchflakes post <- test == """" && log ~ `: device not configured` ```",1.0,"all: test failures with `device not configured` - ``` #!watchflakes post <- test == """" && log ~ `: device not configured` ```",0,all test failures with device not configured watchflakes post test log device not configured ,0 5313,2921979377.0,IssuesEvent,2015-06-25 07:14:34,golang/go,https://api.github.com/repos/golang/go,closed,"os/exec: Cmd can only be executed once, but that isn't documented",Documentation,"Once an exec.Cmd has been Run (e.g. through .Run, .Output or .CombinedOutput) calling one of these run methods again will result in an error. 1. This fact isn't documented. 2. The resulting error messages don't clearly identify what caused the problem. 3. This behaviour probably isn't necessary; for many commands it makes perfectly good sense to run them more than once. I'm not talking about parallel execution here, this is running, checking the output, then running again. Example error message from calling CombinedOutput more than once: ""exec: Stdout already set."" http://play.golang.org/p/Aaj3Gbva_S",1.0,"os/exec: Cmd can only be executed once, but that isn't documented - Once an exec.Cmd has been Run (e.g. through .Run, .Output or .CombinedOutput) calling one of these run methods again will result in an error. 1. This fact isn't documented. 2. The resulting error messages don't clearly identify what caused the problem. 3. This behaviour probably isn't necessary; for many commands it makes perfectly good sense to run them more than once. I'm not talking about parallel execution here, this is running, checking the output, then running again. Example error message from calling CombinedOutput more than once: ""exec: Stdout already set."" http://play.golang.org/p/Aaj3Gbva_S",1,os exec cmd can only be executed once but that isn t documented once an exec cmd has been run e g through run output or combinedoutput calling one of these run methods again will result in an error this fact isn t documented the resulting error messages don t clearly identify what caused the problem this behaviour probably isn t necessary for many commands it makes perfectly good sense to run them more than once i m not talking about parallel execution here this is running checking the output then running again example error message from calling combinedoutput more than once exec stdout already set ,1 16244,4030114778.0,IssuesEvent,2016-05-18 13:18:05,golang/go,https://api.github.com/repos/golang/go,closed,"doc: Clarify what code is referred in the ""Pointers vs. Values"" section of Effective Go",Documentation,"![Pointers vs. Values section of Effective Go document](https://cloud.githubusercontent.com/assets/6612636/13546602/d39a73ae-e2dc-11e5-8f01-d89fe0a40181.png) [`Append`](https://tip.golang.org/doc/effective_go.html#append) section is a few screens before [`Pointers vs. Values`](https://tip.golang.org/doc/effective_go.html#pointers_vs_values) and (1) is easy to miss. It is therefore not clear for the reader what code is referred in the comment of snippet (2) and subsequent ones. At least, that was my experience. I would, transform (1) into a link to `#append` (to attract reader's attention and clarify what exactly `Append` is meant) and change (2) to something like: ```diff - // Body exactly the same as above + // Body is exactly the same as described in the Append section above. ``` ",1.0,"doc: Clarify what code is referred in the ""Pointers vs. Values"" section of Effective Go - ![Pointers vs. Values section of Effective Go document](https://cloud.githubusercontent.com/assets/6612636/13546602/d39a73ae-e2dc-11e5-8f01-d89fe0a40181.png) [`Append`](https://tip.golang.org/doc/effective_go.html#append) section is a few screens before [`Pointers vs. Values`](https://tip.golang.org/doc/effective_go.html#pointers_vs_values) and (1) is easy to miss. It is therefore not clear for the reader what code is referred in the comment of snippet (2) and subsequent ones. At least, that was my experience. I would, transform (1) into a link to `#append` (to attract reader's attention and clarify what exactly `Append` is meant) and change (2) to something like: ```diff - // Body exactly the same as above + // Body is exactly the same as described in the Append section above. ``` ",1,doc clarify what code is referred in the pointers vs values section of effective go section is a few screens before and is easy to miss it is therefore not clear for the reader what code is referred in the comment of snippet and subsequent ones at least that was my experience i would transform into a link to append to attract reader s attention and clarify what exactly append is meant and change to something like diff body exactly the same as above body is exactly the same as described in the append section above ,1 86739,10515961460.0,IssuesEvent,2019-09-28 14:04:15,golang/go,https://api.github.com/repos/golang/go,opened,x/tour: welcome/3 slide missing instructions for installing Go,Documentation NeedsFix,"The first slide of the tour welcomes people and explains how to change slides. The second slide mentions the choice of spoken languages. The third slide strongly suggests running the tour offline. By the [third slide](https://tour.golang.org/welcome/3), the tour assumes users already have Go installed (and/or know how to install Go). This isn't valid for users who are being introduced to Go by being linked to the tour. It can cause unnecessary confusion as demonstrated by the experience reported in [this comment](https://github.com/golang/go/issues/24819#issuecomment-487723046). That slide used to have instructions for installing Go, but they were lost as part of deployment changes in [CL 141857](https://golang.org/cl/141857). /cc @andybons To fix this, we should include a link to https://golang.org/doc/install and/or https://golang.org/dl/ before the first mention of `go get` in the tour. It should also be helpful and a good teaching opportunity to point out where the `tour` binary ends up after `go get` runs successfully. This issue is factored out from #24819, which was about a formatting bug that is resolved by now.",1.0,"x/tour: welcome/3 slide missing instructions for installing Go - The first slide of the tour welcomes people and explains how to change slides. The second slide mentions the choice of spoken languages. The third slide strongly suggests running the tour offline. By the [third slide](https://tour.golang.org/welcome/3), the tour assumes users already have Go installed (and/or know how to install Go). This isn't valid for users who are being introduced to Go by being linked to the tour. It can cause unnecessary confusion as demonstrated by the experience reported in [this comment](https://github.com/golang/go/issues/24819#issuecomment-487723046). That slide used to have instructions for installing Go, but they were lost as part of deployment changes in [CL 141857](https://golang.org/cl/141857). /cc @andybons To fix this, we should include a link to https://golang.org/doc/install and/or https://golang.org/dl/ before the first mention of `go get` in the tour. It should also be helpful and a good teaching opportunity to point out where the `tour` binary ends up after `go get` runs successfully. This issue is factored out from #24819, which was about a formatting bug that is resolved by now.",1,x tour welcome slide missing instructions for installing go the first slide of the tour welcomes people and explains how to change slides the second slide mentions the choice of spoken languages the third slide strongly suggests running the tour offline by the the tour assumes users already have go installed and or know how to install go this isn t valid for users who are being introduced to go by being linked to the tour it can cause unnecessary confusion as demonstrated by the experience reported in that slide used to have instructions for installing go but they were lost as part of deployment changes in cc andybons to fix this we should include a link to and or before the first mention of go get in the tour it should also be helpful and a good teaching opportunity to point out where the tour binary ends up after go get runs successfully this issue is factored out from which was about a formatting bug that is resolved by now ,1 90947,26225556184.0,IssuesEvent,2023-01-04 18:20:35,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gomote: instruct gomote users on how to request authentication credentials,Builders NeedsInvestigation,"Once gomote users can create authentication credentials via the new path, the users should be notified via the following mediums: - [ ] ~~Update the gomote create preamble text to include instructions on how to request credentials.~~ - [x] Update the wiki. - [x] Send out an email. This is a component of the project to revamp the security model used by gomote #47521 @golang/release ",1.0,"x/build/cmd/gomote: instruct gomote users on how to request authentication credentials - Once gomote users can create authentication credentials via the new path, the users should be notified via the following mediums: - [ ] ~~Update the gomote create preamble text to include instructions on how to request credentials.~~ - [x] Update the wiki. - [x] Send out an email. This is a component of the project to revamp the security model used by gomote #47521 @golang/release ",0,x build cmd gomote instruct gomote users on how to request authentication credentials once gomote users can create authentication credentials via the new path the users should be notified via the following mediums update the gomote create preamble text to include instructions on how to request credentials update the wiki send out an email this is a component of the project to revamp the security model used by gomote golang release ,0 35242,9552744612.0,IssuesEvent,2019-05-02 17:26:15,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gopherbot: who is suppose to be congratulated?,Builders,"Does this code means as commented or not to congratulate before 2017/06/17 in UTC?? https://go.googlesource.com/build/+/refs/heads/master/cmd/gopherbot/gopherbot.go#1051",1.0,"x/build/cmd/gopherbot: who is suppose to be congratulated? - Does this code means as commented or not to congratulate before 2017/06/17 in UTC?? https://go.googlesource.com/build/+/refs/heads/master/cmd/gopherbot/gopherbot.go#1051",0,x build cmd gopherbot who is suppose to be congratulated does this code means as commented or not to congratulate before in utc ,0 22020,11457418784.0,IssuesEvent,2020-02-06 23:41:55,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: ARM's MOVWnop causes regalloc to insert unnecessary copies,Performance,"MOVWnop is a nop/copy designed to ensure type safety. It generates no code. However, it is not free; regalloc sometimes makes a copy of a value to provide to MOVWnop, since it doesn't know that MOVWnop doesn't modify its argument. I noticed this while tracking down regressions due to changes in rewrite rule order application. I don't know what the best approach to fixing it is. Suggestions? cc @cherrymui ",True,"cmd/compile: ARM's MOVWnop causes regalloc to insert unnecessary copies - MOVWnop is a nop/copy designed to ensure type safety. It generates no code. However, it is not free; regalloc sometimes makes a copy of a value to provide to MOVWnop, since it doesn't know that MOVWnop doesn't modify its argument. I noticed this while tracking down regressions due to changes in rewrite rule order application. I don't know what the best approach to fixing it is. Suggestions? cc @cherrymui ",0,cmd compile arm s movwnop causes regalloc to insert unnecessary copies movwnop is a nop copy designed to ensure type safety it generates no code however it is not free regalloc sometimes makes a copy of a value to provide to movwnop since it doesn t know that movwnop doesn t modify its argument i noticed this while tracking down regressions due to changes in rewrite rule order application i don t know what the best approach to fixing it is suggestions cc cherrymui ,0 3007,2730806909.0,IssuesEvent,2015-04-16 16:45:15,golang/go,https://api.github.com/repos/golang/go,closed,os: document that FileMode permission bits are Unix bits,Documentation,"by **Mortdeus@gocos2d.org**: 
It would be nice to add 

`rwx(111[7]) rw(110[6]) rx(101[5]) r(100[4]) wx(011[3]) w(010[2]) x(001[1])`

as a godoc comment at

https://code.google.com/p/go/source/browse/src/pkg/os/types.go#56
",1.0,"os: document that FileMode permission bits are Unix bits - by **Mortdeus@gocos2d.org**: 
It would be nice to add 

`rwx(111[7]) rw(110[6]) rx(101[5]) r(100[4]) wx(011[3]) w(010[2]) x(001[1])`

as a godoc comment at

https://code.google.com/p/go/source/browse/src/pkg/os/types.go#56
",1,os document that filemode permission bits are unix bits by mortdeus org it would be nice to add rwx rw rx r wx w x as a godoc comment at a href ,1 65248,16166395035.0,IssuesEvent,2021-05-01 15:32:44,golang/go,https://api.github.com/repos/golang/go,opened,x/build: Add FreeBSD 13.0 builder,Builders OS-FreeBSD new-builder,"Hi @cagedmantis, please add a FreeBSD-13.0 builder. I'm sending a CL to update the expect script for the new image. Thanks!",2.0,"x/build: Add FreeBSD 13.0 builder - Hi @cagedmantis, please add a FreeBSD-13.0 builder. I'm sending a CL to update the expect script for the new image. Thanks!",0,x build add freebsd builder hi cagedmantis please add a freebsd builder i m sending a cl to update the expect script for the new image thanks ,0 24186,5037440604.0,IssuesEvent,2016-12-17 17:26:39,golang/go,https://api.github.com/repos/golang/go,opened,doc: mention that CGO_ENABLED is now sticky in 1.8,Documentation,"CGO_ENABLED is sticky in Go 1.8. Document this. Some discussion in: https://github.com/golang/go/issues/18360#issuecomment-267752866 ",1.0,"doc: mention that CGO_ENABLED is now sticky in 1.8 - CGO_ENABLED is sticky in Go 1.8. Document this. Some discussion in: https://github.com/golang/go/issues/18360#issuecomment-267752866 ",1,doc mention that cgo enabled is now sticky in cgo enabled is sticky in go document this some discussion in ,1 43682,7058410021.0,IssuesEvent,2018-01-04 20:16:04,golang/go,https://api.github.com/repos/golang/go,closed,sync: documentation for Map is inadequate,Documentation,"What's there is correct but unhelpful. How does it differ from the map type? When should it be used? When should it not be used? What are its performance characteristics. I think a newcomer would find what's there inadequate to understand what it's for.",1.0,"sync: documentation for Map is inadequate - What's there is correct but unhelpful. How does it differ from the map type? When should it be used? When should it not be used? What are its performance characteristics. I think a newcomer would find what's there inadequate to understand what it's for.",1,sync documentation for map is inadequate what s there is correct but unhelpful how does it differ from the map type when should it be used when should it not be used what are its performance characteristics i think a newcomer would find what s there inadequate to understand what it s for ,1 37691,18732437785.0,IssuesEvent,2021-11-04 00:12:29,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: mark CSE'd loads as rematerializable,Performance,"CSE will unify loads from the same memory state. In computation-heavy code, such the generic code in crypto/md5, these loads can have a long lifetime, leading the loaded values being spilled to the stack. That's silly: We already have the value in memory, so we can reload it from there as needed, without using stack space. Perhaps we can somehow mark such loads as rematerializable, so that the register allocator knows it can re-issue the load instead of spilling. There are some non-obvious details here, like what to do if we need to recalculate the address of the load, and if the calculation of the address is more expensive than spilling the loaded value. But we currently generate some very silly code for crypto/md5's generic block. To see this, patch in https://gist.github.com/josharian/42e66bf022f32da3da0a9b1bdf0a974b into the md5 code and then observe the effect of disabling CSE for loads, for example by adding to cmpVal code like: ``` if len(v.Args) > 0 && v.Args[len(v.Args)-1].Type.IsMemory() { return lt2Cmp(v.ID < w.ID) } ``` The generated code goes from a morass of spills and restores to long, straightforward calculation. There's no way I found to tweak the code to prevent such CSEs. (Issuing irrelevant writes causes other values to get spilled, negating the benefits of preventing CSE.) cc @randall77 ",True,"cmd/compile: mark CSE'd loads as rematerializable - CSE will unify loads from the same memory state. In computation-heavy code, such the generic code in crypto/md5, these loads can have a long lifetime, leading the loaded values being spilled to the stack. That's silly: We already have the value in memory, so we can reload it from there as needed, without using stack space. Perhaps we can somehow mark such loads as rematerializable, so that the register allocator knows it can re-issue the load instead of spilling. There are some non-obvious details here, like what to do if we need to recalculate the address of the load, and if the calculation of the address is more expensive than spilling the loaded value. But we currently generate some very silly code for crypto/md5's generic block. To see this, patch in https://gist.github.com/josharian/42e66bf022f32da3da0a9b1bdf0a974b into the md5 code and then observe the effect of disabling CSE for loads, for example by adding to cmpVal code like: ``` if len(v.Args) > 0 && v.Args[len(v.Args)-1].Type.IsMemory() { return lt2Cmp(v.ID < w.ID) } ``` The generated code goes from a morass of spills and restores to long, straightforward calculation. There's no way I found to tweak the code to prevent such CSEs. (Issuing irrelevant writes causes other values to get spilled, negating the benefits of preventing CSE.) cc @randall77 ",0,cmd compile mark cse d loads as rematerializable cse will unify loads from the same memory state in computation heavy code such the generic code in crypto these loads can have a long lifetime leading the loaded values being spilled to the stack that s silly we already have the value in memory so we can reload it from there as needed without using stack space perhaps we can somehow mark such loads as rematerializable so that the register allocator knows it can re issue the load instead of spilling there are some non obvious details here like what to do if we need to recalculate the address of the load and if the calculation of the address is more expensive than spilling the loaded value but we currently generate some very silly code for crypto s generic block to see this patch in into the code and then observe the effect of disabling cse for loads for example by adding to cmpval code like if len v args v args type ismemory return v id w id the generated code goes from a morass of spills and restores to long straightforward calculation there s no way i found to tweak the code to prevent such cses issuing irrelevant writes causes other values to get spilled negating the benefits of preventing cse cc ,0 15761,3974440852.0,IssuesEvent,2016-05-04 22:12:26,golang/go,https://api.github.com/repos/golang/go,closed,net/http: MethodPatch references the wrong RFC,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? `go version go1.6.2 darwin/amd64` 2. What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/dmaze/Diffeo/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6.2/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 3. What did you do? Run `godoc net/http MethodPatch`; or visited https://godoc.org/net/http#MethodPatch or http://localhost:6060/pkg/net/http#MethodPatch. 4. What did you expect to see? A reference to [RFC 5789, ""PATCH Method for HTTP""](https://tools.ietf.org/html/rfc5789). 5. What did you see instead? A reference to [RFC 5741, ""RFC Streams, Headers, and Boilerplates""](https://tools.ietf.org/html/rfc5741), the meta-RFC that defines the format of RFCs.",1.0,"net/http: MethodPatch references the wrong RFC - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? `go version go1.6.2 darwin/amd64` 2. What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/dmaze/Diffeo/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6.2/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 3. What did you do? Run `godoc net/http MethodPatch`; or visited https://godoc.org/net/http#MethodPatch or http://localhost:6060/pkg/net/http#MethodPatch. 4. What did you expect to see? A reference to [RFC 5789, ""PATCH Method for HTTP""](https://tools.ietf.org/html/rfc5789). 5. What did you see instead? A reference to [RFC 5741, ""RFC Streams, Headers, and Boilerplates""](https://tools.ietf.org/html/rfc5741), the meta-RFC that defines the format of RFCs.",1,net http methodpatch references the wrong rfc please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users dmaze diffeo go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fno common cxx clang cgo enabled what did you do run godoc net http methodpatch or visited or what did you expect to see a reference to what did you see instead a reference to the meta rfc that defines the format of rfcs ,1 146202,13173719873.0,IssuesEvent,2020-08-11 20:52:30,golang/go,https://api.github.com/repos/golang/go,opened,doc: write Go 1.16 release notes,Documentation NeedsFix help wanted recurring release-blocker,"Tracking bug for writing the Go 1.16 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.16 (it hasn't been created yet, so 404 at this time). Previously #37419, #36878, #17929, #15810, #5929, etc.",1.0,"doc: write Go 1.16 release notes - Tracking bug for writing the Go 1.16 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.16 (it hasn't been created yet, so 404 at this time). Previously #37419, #36878, #17929, #15810, #5929, etc.",1,doc write go release notes tracking bug for writing the go release notes the latest state on tip can be viewed at it hasn t been created yet so at this time previously etc ,1 5818,2794989869.0,IssuesEvent,2015-05-11 19:36:08,golang/go,https://api.github.com/repos/golang/go,closed,net/http: data race in TestClientTimeout_Headers when -race=true -short=false,Testing,"git rev-parse HEAD 19e81a9b3b0d103fe7a9a9605c16eb4ba1f20ed8 ``` ================== WARNING: DATA RACE Write by goroutine 16: sync.raceWrite() /go/src/sync/race.go:41 +0x35 sync.(*WaitGroup).Wait() /go/src/sync/waitgroup.go:125 +0x177 net/http/httptest.(*Server).Close() /go/src/net/http/httptest/server.go:168 +0x83 net/http_test.TestClientTimeout_Headers() /go/src/net/http/client_test.go:952 +0xb1a testing.tRunner() /go/src/testing/testing.go:454 +0xfb Previous read by goroutine 22: sync.raceRead() /go/src/sync/race.go:37 +0x35 sync.(*WaitGroup).Add() /go/src/sync/waitgroup.go:63 +0xc8 net/http/httptest.(*waitGroupHandler).ServeHTTP() /go/src/net/http/httptest/server.go:198 +0x5f net/http.serverHandler.ServeHTTP() /go/src/net/http/server.go:1758 +0x209 net/http.(*conn).serve() /go/src/net/http/server.go:1259 +0x1161 Goroutine 16 (running) created at: testing.RunTests() /go/src/testing/testing.go:562 +0xc95 testing.(*M).Run() /go/src/testing/testing.go:492 +0xe7 net/http_test.TestMain() /go/src/net/http/main_test.go:19 +0x35 main.main() net/http/_test/_testmain.go:536 +0x20c Goroutine 22 (running) created at: net/http.(*Server).Serve() /go/src/net/http/server.go:1806 +0x422 ================== PASS Found 1 data race(s) FAIL net/http 43.465s ```",1.0,"net/http: data race in TestClientTimeout_Headers when -race=true -short=false - git rev-parse HEAD 19e81a9b3b0d103fe7a9a9605c16eb4ba1f20ed8 ``` ================== WARNING: DATA RACE Write by goroutine 16: sync.raceWrite() /go/src/sync/race.go:41 +0x35 sync.(*WaitGroup).Wait() /go/src/sync/waitgroup.go:125 +0x177 net/http/httptest.(*Server).Close() /go/src/net/http/httptest/server.go:168 +0x83 net/http_test.TestClientTimeout_Headers() /go/src/net/http/client_test.go:952 +0xb1a testing.tRunner() /go/src/testing/testing.go:454 +0xfb Previous read by goroutine 22: sync.raceRead() /go/src/sync/race.go:37 +0x35 sync.(*WaitGroup).Add() /go/src/sync/waitgroup.go:63 +0xc8 net/http/httptest.(*waitGroupHandler).ServeHTTP() /go/src/net/http/httptest/server.go:198 +0x5f net/http.serverHandler.ServeHTTP() /go/src/net/http/server.go:1758 +0x209 net/http.(*conn).serve() /go/src/net/http/server.go:1259 +0x1161 Goroutine 16 (running) created at: testing.RunTests() /go/src/testing/testing.go:562 +0xc95 testing.(*M).Run() /go/src/testing/testing.go:492 +0xe7 net/http_test.TestMain() /go/src/net/http/main_test.go:19 +0x35 main.main() net/http/_test/_testmain.go:536 +0x20c Goroutine 22 (running) created at: net/http.(*Server).Serve() /go/src/net/http/server.go:1806 +0x422 ================== PASS Found 1 data race(s) FAIL net/http 43.465s ```",0,net http data race in testclienttimeout headers when race true short false git rev parse head warning data race write by goroutine sync racewrite go src sync race go sync waitgroup wait go src sync waitgroup go net http httptest server close go src net http httptest server go net http test testclienttimeout headers go src net http client test go testing trunner go src testing testing go previous read by goroutine sync raceread go src sync race go sync waitgroup add go src sync waitgroup go net http httptest waitgrouphandler servehttp go src net http httptest server go net http serverhandler servehttp go src net http server go net http conn serve go src net http server go goroutine running created at testing runtests go src testing testing go testing m run go src testing testing go net http test testmain go src net http main test go main main net http test testmain go goroutine running created at net http server serve go src net http server go pass found data race s fail net http ,0 5991,5243488673.0,IssuesEvent,2017-01-31 20:51:23,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: inline small static initializers,Performance,"``` type T struct { a, b, c, d int } func f(p *T) { *p = T{1, 2, 3, 4} } ``` The code for `f` is: ``` (tmp1.go:8) MOVQ """".statictmp_0(SB), AX (tmp1.go:8) MOVQ """".statictmp_0+8(SB), CX (tmp1.go:8) MOVQ """".statictmp_0+16(SB), DX (tmp1.go:8) MOVQ """".statictmp_0+24(SB), BX (tmp1.go:8) MOVQ """".p+8(FP), SI (tmp1.go:8) MOVQ AX, (SI) (tmp1.go:8) MOVQ CX, 8(SI) (tmp1.go:8) MOVQ DX, 16(SI) (tmp1.go:8) MOVQ BX, 24(SI) ``` That's kind of dumb to copy from a statictmp. Just use `MOVQ $1, (SI)` and so forth. ",True,"cmd/compile: inline small static initializers - ``` type T struct { a, b, c, d int } func f(p *T) { *p = T{1, 2, 3, 4} } ``` The code for `f` is: ``` (tmp1.go:8) MOVQ """".statictmp_0(SB), AX (tmp1.go:8) MOVQ """".statictmp_0+8(SB), CX (tmp1.go:8) MOVQ """".statictmp_0+16(SB), DX (tmp1.go:8) MOVQ """".statictmp_0+24(SB), BX (tmp1.go:8) MOVQ """".p+8(FP), SI (tmp1.go:8) MOVQ AX, (SI) (tmp1.go:8) MOVQ CX, 8(SI) (tmp1.go:8) MOVQ DX, 16(SI) (tmp1.go:8) MOVQ BX, 24(SI) ``` That's kind of dumb to copy from a statictmp. Just use `MOVQ $1, (SI)` and so forth. ",0,cmd compile inline small static initializers type t struct a b c d int func f p t p t the code for f is go movq statictmp sb ax go movq statictmp sb cx go movq statictmp sb dx go movq statictmp sb bx go movq p fp si go movq ax si go movq cx si go movq dx si go movq bx si that s kind of dumb to copy from a statictmp just use movq si and so forth ,0 21584,11273806722.0,IssuesEvent,2020-01-14 17:14:08,golang/go,https://api.github.com/repos/golang/go,closed,runtime: scavenger is too eager on Darwin,NeedsFix Performance,"Currently on Darwin the scavenger is too eager and causing performance regressions. The issue mainly stems from the fact that in Go 1.14 the scavenger is paced empirically according to costs of scavenging, most of which comes from `sysUnused` which makes an `madvise` syscall on most platforms, including Darwin. However, the problem on Darwin is that we don't just do `MADV_FREE` anymore, we do `MADV_FREE_REUSABLE` in the `sysUnused` path and `MADV_FREE_REUSE` in the `sysUsed` path (instead of `sysUsed` being a no-op). It turns out the source of the regression is mostly the fact that `sysUsed` is actually quite expensive relative to other systems where it's just a no-op and we instead incur an implicit page fault once the memory is actually touched. The benefits of using this API outweigh the costs, since it updates process RSS counters in the kernel appropriately and `MADV_FREE_REUSABLE` is properly lazy. So since we don't account for `sysUsed` we end up scavenging a lot more frequently than we should to maintain the scavenger's goal of only using 1% of the CPU time of one CPU. The actual size of the regression can be quite large, up to 5%, as seen in #36218, so we should fix this before 1.14 goes out. The fix here is relatively simple: we just need to account for this extra cost somehow. We could measure it directly in the runtime but this then slows down allocation unnecessarily, and even then it's unclear how we should attribute that cost to the scavenger (maybe as a debt it needs to pay down?). Trying to account for this cost on non-Darwin platforms is also tricky because the costs aren't actually coming from `sysUsed` but from the page fault. Instead, I think it's a good idea to do something along the lines of what we did last release: get some empirical measurements and use that to get an order-of-magnitude approximation. In this particular case, I think we should compute an empirical ratio ""r"" of using a scavenged page and `sysUnused` and turn this into a multiplicative constant, ""1+r"" for the time spent scavenging. So for example if `sysUsed` is roughly as expensive as `sysUnused` the factor would be 2.",True,"runtime: scavenger is too eager on Darwin - Currently on Darwin the scavenger is too eager and causing performance regressions. The issue mainly stems from the fact that in Go 1.14 the scavenger is paced empirically according to costs of scavenging, most of which comes from `sysUnused` which makes an `madvise` syscall on most platforms, including Darwin. However, the problem on Darwin is that we don't just do `MADV_FREE` anymore, we do `MADV_FREE_REUSABLE` in the `sysUnused` path and `MADV_FREE_REUSE` in the `sysUsed` path (instead of `sysUsed` being a no-op). It turns out the source of the regression is mostly the fact that `sysUsed` is actually quite expensive relative to other systems where it's just a no-op and we instead incur an implicit page fault once the memory is actually touched. The benefits of using this API outweigh the costs, since it updates process RSS counters in the kernel appropriately and `MADV_FREE_REUSABLE` is properly lazy. So since we don't account for `sysUsed` we end up scavenging a lot more frequently than we should to maintain the scavenger's goal of only using 1% of the CPU time of one CPU. The actual size of the regression can be quite large, up to 5%, as seen in #36218, so we should fix this before 1.14 goes out. The fix here is relatively simple: we just need to account for this extra cost somehow. We could measure it directly in the runtime but this then slows down allocation unnecessarily, and even then it's unclear how we should attribute that cost to the scavenger (maybe as a debt it needs to pay down?). Trying to account for this cost on non-Darwin platforms is also tricky because the costs aren't actually coming from `sysUsed` but from the page fault. Instead, I think it's a good idea to do something along the lines of what we did last release: get some empirical measurements and use that to get an order-of-magnitude approximation. In this particular case, I think we should compute an empirical ratio ""r"" of using a scavenged page and `sysUnused` and turn this into a multiplicative constant, ""1+r"" for the time spent scavenging. So for example if `sysUsed` is roughly as expensive as `sysUnused` the factor would be 2.",0,runtime scavenger is too eager on darwin currently on darwin the scavenger is too eager and causing performance regressions the issue mainly stems from the fact that in go the scavenger is paced empirically according to costs of scavenging most of which comes from sysunused which makes an madvise syscall on most platforms including darwin however the problem on darwin is that we don t just do madv free anymore we do madv free reusable in the sysunused path and madv free reuse in the sysused path instead of sysused being a no op it turns out the source of the regression is mostly the fact that sysused is actually quite expensive relative to other systems where it s just a no op and we instead incur an implicit page fault once the memory is actually touched the benefits of using this api outweigh the costs since it updates process rss counters in the kernel appropriately and madv free reusable is properly lazy so since we don t account for sysused we end up scavenging a lot more frequently than we should to maintain the scavenger s goal of only using of the cpu time of one cpu the actual size of the regression can be quite large up to as seen in so we should fix this before goes out the fix here is relatively simple we just need to account for this extra cost somehow we could measure it directly in the runtime but this then slows down allocation unnecessarily and even then it s unclear how we should attribute that cost to the scavenger maybe as a debt it needs to pay down trying to account for this cost on non darwin platforms is also tricky because the costs aren t actually coming from sysused but from the page fault instead i think it s a good idea to do something along the lines of what we did last release get some empirical measurements and use that to get an order of magnitude approximation in this particular case i think we should compute an empirical ratio r of using a scavenged page and sysunused and turn this into a multiplicative constant r for the time spent scavenging so for example if sysused is roughly as expensive as sysunused the factor would be ,0 215667,16614220069.0,IssuesEvent,2021-06-02 14:52:44,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document time changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
time

time.Time now has a GoString method that will return a more useful value for times when printed with the "%#v" format specifier in the fmt package.

TODO: https://golang.org/cl/264077: add Time.IsDST() to check if its Location is in Daylight Savings Time

TODO: https://golang.org/cl/293349: add Time.Unix{Milli,Micro} and to-Time helpers UnixMicro, UnixMilli

TODO: https://golang.org/cl/300996: support "," as separator for fractional seconds

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46026."" in the body.",1.0,"doc/go1.17: document time changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
time

time.Time now has a GoString method that will return a more useful value for times when printed with the "%#v" format specifier in the fmt package.

TODO: https://golang.org/cl/264077: add Time.IsDST() to check if its Location is in Daylight Savings Time

TODO: https://golang.org/cl/293349: add Time.Unix{Milli,Micro} and to-Time helpers UnixMicro, UnixMilli

TODO: https://golang.org/cl/300996: support "," as separator for fractional seconds

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46026."" in the body.",1,doc document time changes for go as of filing this issue the contained the following html time time time now has a gostring method that will return a more useful value for times when printed with the v format specifier in the fmt package todo a href add time isdst to check if its location is in daylight savings time todo a href add time unix milli micro and to time helpers unixmicro unixmilli todo a href support as separator for fractional seconds this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 202853,23118136116.0,IssuesEvent,2022-07-27 18:32:44,golang/go,https://api.github.com/repos/golang/go,closed,math/big: index out of range in Float.GobDecode,Security NeedsFix,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.6 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/catena/Library/Caches/go-build""
GOENV=""/Users/catena/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/catena/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/catena/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""
GOVCS=""""
GOVERSION=""go1.17.6""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/catena/go/src/github.com/catenacyber/go/src/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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/dc1dtf9x2js3v0jx_m010nqr0000gn/T/go-build4237848497=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.6 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.6
uname -v: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	12.2.1
BuildVersion:	21D62
lldb --version: lldb-1316.0.9.41
Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
gdb --version: GNU gdb (GDB) 9.1
### What did you do? Run https://go.dev/play/p/-iOX1cXown9 ie `Float0.GobDecode([]byte{0x1, 0x0, 0x0, 0x0})` ### What did you expect to see? The program finishing and printing somme Hello, without having allocated too much space ### What did you see instead? ``` panic: runtime error: index out of range [3] with length 2 goroutine 1 [running]: encoding/binary.bigEndian.Uint32(...) /usr/local/go-faketime/src/encoding/binary/binary.go:112 math/big.(*Float).GobDecode(0x60?, {0xc000070f34?, 0xc00006a000?, 0x0?}) /usr/local/go-faketime/src/math/big/floatmarsh.go:83 +0x23d main.main() /tmp/sandbox1173043807/prog.go:12 +0x56 Program exited. ``` Found by https://github.com/catenacyber/ngolo-fuzzing on oss-fuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49120 ",True,"math/big: index out of range in Float.GobDecode - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.6 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/catena/Library/Caches/go-build""
GOENV=""/Users/catena/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/catena/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/catena/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""
GOVCS=""""
GOVERSION=""go1.17.6""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/catena/go/src/github.com/catenacyber/go/src/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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/dc1dtf9x2js3v0jx_m010nqr0000gn/T/go-build4237848497=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.6 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.6
uname -v: Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	12.2.1
BuildVersion:	21D62
lldb --version: lldb-1316.0.9.41
Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)
gdb --version: GNU gdb (GDB) 9.1
### What did you do? Run https://go.dev/play/p/-iOX1cXown9 ie `Float0.GobDecode([]byte{0x1, 0x0, 0x0, 0x0})` ### What did you expect to see? The program finishing and printing somme Hello, without having allocated too much space ### What did you see instead? ``` panic: runtime error: index out of range [3] with length 2 goroutine 1 [running]: encoding/binary.bigEndian.Uint32(...) /usr/local/go-faketime/src/encoding/binary/binary.go:112 math/big.(*Float).GobDecode(0x60?, {0xc000070f34?, 0xc00006a000?, 0x0?}) /usr/local/go-faketime/src/math/big/floatmarsh.go:83 +0x23d main.main() /tmp/sandbox1173043807/prog.go:12 +0x56 Program exited. ``` Found by https://github.com/catenacyber/ngolo-fuzzing on oss-fuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49120 ",0,math big index out of range in float gobdecode what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users catena library caches go build goenv users catena library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users catena go pkg mod gonoproxy gonosumdb goos darwin gopath users catena go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users catena go src github com catenacyber go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders pp t go tmp go build gno record gcc switches fno common goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version wed jan pst root xnu release productname macos productversion buildversion lldb version lldb apple swift version swiftlang clang gdb version gnu gdb gdb what did you do run ie gobdecode byte what did you expect to see the program finishing and printing somme hello without having allocated too much space what did you see instead panic runtime error index out of range with length goroutine encoding binary bigendian usr local go faketime src encoding binary binary go math big float gobdecode usr local go faketime src math big floatmarsh go main main tmp prog go program exited found by on oss fuzz ,0 14883,3900391667.0,IssuesEvent,2016-04-18 05:39:06,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: the fact that go build/install ignores _test.go files is not documented,Documentation,"The documentation (both for 1.6 at https://golang.org/cmd/go/ and for tip at https://tip.golang.org/cmd/go/) for `go test` says that > 'Go test' recompiles each package along with any files with names matching the file pattern ""*_test.go"". However the documentation for `go build` doesn't say anything about `_test.go` files. I think the documentation for `go build` and `go install` should be updated to mention that `_test.go` files are ignored. While most users probably do not read the documentation carefully it is still useful to have something to refer new users to. See the following StackOverflow question for background: http://stackoverflow.com/questions/36638149/undefined-variables-within-a-package-during-build",1.0,"cmd/go: the fact that go build/install ignores _test.go files is not documented - The documentation (both for 1.6 at https://golang.org/cmd/go/ and for tip at https://tip.golang.org/cmd/go/) for `go test` says that > 'Go test' recompiles each package along with any files with names matching the file pattern ""*_test.go"". However the documentation for `go build` doesn't say anything about `_test.go` files. I think the documentation for `go build` and `go install` should be updated to mention that `_test.go` files are ignored. While most users probably do not read the documentation carefully it is still useful to have something to refer new users to. See the following StackOverflow question for background: http://stackoverflow.com/questions/36638149/undefined-variables-within-a-package-during-build",1,cmd go the fact that go build install ignores test go files is not documented the documentation both for at and for tip at for go test says that go test recompiles each package along with any files with names matching the file pattern test go however the documentation for go build doesn t say anything about test go files i think the documentation for go build and go install should be updated to mention that test go files are ignored while most users probably do not read the documentation carefully it is still useful to have something to refer new users to see the following stackoverflow question for background ,1 7157,3081443706.0,IssuesEvent,2015-08-22 18:40:32,golang/go,https://api.github.com/repos/golang/go,closed,all: move all examples to external test packages,Documentation,"This is an extraction from #11254. Having the package prefix in examples is clearer than omitting it. Since examples must not make use of unexported functionality anyway, it is always ok to have them in an external test package. Let's move all examples to external test packages. If Go 1 compatibility didn't prevent it, I'd suggest that we modify the testing package to enforce this. ",1.0,"all: move all examples to external test packages - This is an extraction from #11254. Having the package prefix in examples is clearer than omitting it. Since examples must not make use of unexported functionality anyway, it is always ok to have them in an external test package. Let's move all examples to external test packages. If Go 1 compatibility didn't prevent it, I'd suggest that we modify the testing package to enforce this. ",1,all move all examples to external test packages this is an extraction from having the package prefix in examples is clearer than omitting it since examples must not make use of unexported functionality anyway it is always ok to have them in an external test package let s move all examples to external test packages if go compatibility didn t prevent it i d suggest that we modify the testing package to enforce this ,1 49612,7523410403.0,IssuesEvent,2018-04-13 00:51:03,golang/go,https://api.github.com/repos/golang/go,closed,time: Sub is inaccurate after computer has slept,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version go1.9.2 darwin/amd64` ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/pmoore/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v9/mll6p_rj5h94dt_m5m8j0f9c0000gn/T/go-build287238210=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` ``` $ sw_vers ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1003 ``` ### What did you do? I ran the following program, and then waited for my iMac sleep. I woke it up again. ``` $ cat main.go package main import ( ""fmt"" ""time"" ) func main() { start := time.Now() for { time.Sleep(time.Second) end := time.Now() fmt.Printf(""Start: %v, End: %v, Duration: %v\n"", start, end, end.Sub(start)) } } $ go run main.go .... .... Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:22.691501 +0100 CET m=+153.190165077, Duration: 2m33.189775511s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:23.691737 +0100 CET m=+154.190447504, Duration: 2m34.190057938s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:24.691824 +0100 CET m=+155.190580407, Duration: 2m35.190190841s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:25.692191 +0100 CET m=+156.190990386, Duration: 2m36.19060082s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:26.692307 +0100 CET m=+157.191153372, Duration: 2m37.190763806s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:33.892169 +0100 CET m=+158.581754838, Duration: 2m38.581365272s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:34.893832 +0100 CET m=+159.583462000, Duration: 2m39.583072434s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:35.894375 +0100 CET m=+160.584051261, Duration: 2m40.583661695s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:36.895479 +0100 CET m=+161.585199077, Duration: 2m41.584809511s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:37.895651 +0100 CET m=+162.585417039, Duration: 2m42.585027473s ``` ### What did you expect to see? I expected the log output for Duration to equal the difference between the timestamps logged for Start and End. For example, the last line is: ``` Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:37.895651 +0100 CET m=+162.585417039, Duration: 2m42.585027473s ``` If start is 14:03:49.5 and end is 14:14:37.9 then duration should be 10m48.4s not 2m42.6s. Note, the 8 minute jump in end time from 14:06:26.7 to 14:14:33.9 was when the computer was sleeping. ### What did you see instead? The duration calculation seemed to match the amount of _awake_ time between start and end time. Notice how when the end time jumps eight minutes (due to the computer being asleep), the duration only increments by around one second, as if no sleep had occurred.",1.0,"time: Sub is inaccurate after computer has slept - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version go1.9.2 darwin/amd64` ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/pmoore/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v9/mll6p_rj5h94dt_m5m8j0f9c0000gn/T/go-build287238210=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` ``` $ sw_vers ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B1003 ``` ### What did you do? I ran the following program, and then waited for my iMac sleep. I woke it up again. ``` $ cat main.go package main import ( ""fmt"" ""time"" ) func main() { start := time.Now() for { time.Sleep(time.Second) end := time.Now() fmt.Printf(""Start: %v, End: %v, Duration: %v\n"", start, end, end.Sub(start)) } } $ go run main.go .... .... Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:22.691501 +0100 CET m=+153.190165077, Duration: 2m33.189775511s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:23.691737 +0100 CET m=+154.190447504, Duration: 2m34.190057938s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:24.691824 +0100 CET m=+155.190580407, Duration: 2m35.190190841s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:25.692191 +0100 CET m=+156.190990386, Duration: 2m36.19060082s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:06:26.692307 +0100 CET m=+157.191153372, Duration: 2m37.190763806s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:33.892169 +0100 CET m=+158.581754838, Duration: 2m38.581365272s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:34.893832 +0100 CET m=+159.583462000, Duration: 2m39.583072434s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:35.894375 +0100 CET m=+160.584051261, Duration: 2m40.583661695s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:36.895479 +0100 CET m=+161.585199077, Duration: 2m41.584809511s Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:37.895651 +0100 CET m=+162.585417039, Duration: 2m42.585027473s ``` ### What did you expect to see? I expected the log output for Duration to equal the difference between the timestamps logged for Start and End. For example, the last line is: ``` Start: 2017-12-19 14:03:49.50865 +0100 CET m=+0.000389566, End: 2017-12-19 14:14:37.895651 +0100 CET m=+162.585417039, Duration: 2m42.585027473s ``` If start is 14:03:49.5 and end is 14:14:37.9 then duration should be 10m48.4s not 2m42.6s. Note, the 8 minute jump in end time from 14:06:26.7 to 14:14:33.9 was when the computer was sleeping. ### What did you see instead? The duration calculation seemed to match the amount of _awake_ time between start and end time. Notice how when the end time jumps eight minutes (due to the computer being asleep), the duration only increments by around one second, as if no sleep had occurred.",1,time sub is inaccurate after computer has slept please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users pmoore go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config sw vers productname mac os x productversion buildversion what did you do i ran the following program and then waited for my imac sleep i woke it up again cat main go package main import fmt time func main start time now for time sleep time second end time now fmt printf start v end v duration v n start end end sub start go run main go start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration start cet m end cet m duration what did you expect to see i expected the log output for duration to equal the difference between the timestamps logged for start and end for example the last line is start cet m end cet m duration if start is and end is then duration should be not note the minute jump in end time from to was when the computer was sleeping what did you see instead the duration calculation seemed to match the amount of awake time between start and end time notice how when the end time jumps eight minutes due to the computer being asleep the duration only increments by around one second as if no sleep had occurred ,1 84766,10417820304.0,IssuesEvent,2019-09-15 01:58:47,golang/go,https://api.github.com/repos/golang/go,closed,net/http: Content-Length is not set in outgoing request when using ioutil.NopCloser,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/1041775/Library/Caches/go-build""
GOENV=""/Users/1041775/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/1041775/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.13/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/1041775/projects/js-scripts/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/d6/809nhvwd23nd_wryrw60j6hdms016p/T/go-build703352534=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Start a httpbin server locally. 
docker run -p 80:80 kennethreitz/httpbin
Run the following program ```go package main import ( ""bytes"" ""io/ioutil"" ""log"" ""net/http"" ) func main() { reqBody := ioutil.NopCloser(bytes.NewBufferString(`{}`)) req, err := http.NewRequest(""POST"", ""http://localhost:80/post"", reqBody) if err != nil { log.Fatalf(""Cannot create request: %v"", err) } res, err := http.DefaultClient.Do(req) if err != nil { log.Fatalf(""Cannot do: %v"", err) } defer res.Body.Close() resBody, err := ioutil.ReadAll(res.Body) if err != nil { log.Fatalf(""Cannot read body: %v"", err) } log.Printf(""Response Body: %s"", resBody) } ``` ### What did you expect to see? Content-Length header is set when it is received by the server. ### What did you see instead? Content-Length header is missing when it is received by the server. 
2019/09/14 12:55:00 Response Body: {
  ""args"": {}, 
  ""data"": ""{}"", 
  ""files"": {}, 
  ""form"": {}, 
  ""headers"": {
    ""Accept-Encoding"": ""gzip"", 
    ""Host"": ""localhost:80"", 
    ""Transfer-Encoding"": ""chunked"", 
    ""User-Agent"": ""Go-http-client/1.1""
  }, 
  ""json"": {}, 
  ""origin"": ""172.17.0.1"", 
  ""url"": ""http://localhost:80/post""
}
Versus what I would receive if I use 
reqBody := bytes.NewBufferString(`{}`)
. 
2019/09/14 12:55:22 Response Body: {
  ""args"": {}, 
  ""data"": ""{}"", 
  ""files"": {}, 
  ""form"": {}, 
  ""headers"": {
    ""Accept-Encoding"": ""gzip"", 
    ""Content-Length"": ""2"", 
    ""Host"": ""localhost:80"", 
    ""User-Agent"": ""Go-http-client/1.1""
  }, 
  ""json"": {}, 
  ""origin"": ""172.17.0.1"", 
  ""url"": ""http://localhost:80/post""
}
",1.0,"net/http: Content-Length is not set in outgoing request when using ioutil.NopCloser - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/1041775/Library/Caches/go-build""
GOENV=""/Users/1041775/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/1041775/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.13/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/1041775/projects/js-scripts/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/d6/809nhvwd23nd_wryrw60j6hdms016p/T/go-build703352534=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Start a httpbin server locally. 
docker run -p 80:80 kennethreitz/httpbin
Run the following program ```go package main import ( ""bytes"" ""io/ioutil"" ""log"" ""net/http"" ) func main() { reqBody := ioutil.NopCloser(bytes.NewBufferString(`{}`)) req, err := http.NewRequest(""POST"", ""http://localhost:80/post"", reqBody) if err != nil { log.Fatalf(""Cannot create request: %v"", err) } res, err := http.DefaultClient.Do(req) if err != nil { log.Fatalf(""Cannot do: %v"", err) } defer res.Body.Close() resBody, err := ioutil.ReadAll(res.Body) if err != nil { log.Fatalf(""Cannot read body: %v"", err) } log.Printf(""Response Body: %s"", resBody) } ``` ### What did you expect to see? Content-Length header is set when it is received by the server. ### What did you see instead? Content-Length header is missing when it is received by the server. 
2019/09/14 12:55:00 Response Body: {
  ""args"": {}, 
  ""data"": ""{}"", 
  ""files"": {}, 
  ""form"": {}, 
  ""headers"": {
    ""Accept-Encoding"": ""gzip"", 
    ""Host"": ""localhost:80"", 
    ""Transfer-Encoding"": ""chunked"", 
    ""User-Agent"": ""Go-http-client/1.1""
  }, 
  ""json"": {}, 
  ""origin"": ""172.17.0.1"", 
  ""url"": ""http://localhost:80/post""
}
Versus what I would receive if I use 
reqBody := bytes.NewBufferString(`{}`)
. 
2019/09/14 12:55:22 Response Body: {
  ""args"": {}, 
  ""data"": ""{}"", 
  ""files"": {}, 
  ""form"": {}, 
  ""headers"": {
    ""Accept-Encoding"": ""gzip"", 
    ""Content-Length"": ""2"", 
    ""Host"": ""localhost:80"", 
    ""User-Agent"": ""Go-http-client/1.1""
  }, 
  ""json"": {}, 
  ""origin"": ""172.17.0.1"", 
  ""url"": ""http://localhost:80/post""
}
",1,net http content length is not set in outgoing request when using ioutil nopcloser what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users library caches go build goenv users library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users go goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users projects js scripts go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common 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 start a httpbin server locally docker run p kennethreitz httpbin run the following program go package main import bytes io ioutil log net http func main reqbody ioutil nopcloser bytes newbufferstring req err http newrequest post reqbody if err nil log fatalf cannot create request v err res err http defaultclient do req if err nil log fatalf cannot do v err defer res body close resbody err ioutil readall res body if err nil log fatalf cannot read body v err log printf response body s resbody what did you expect to see content length header is set when it is received by the server what did you see instead content length header is missing when it is received by the server response body args data files form headers accept encoding gzip host localhost transfer encoding chunked user agent go http client json origin url versus what i would receive if i use reqbody bytes newbufferstring response body args data files form headers accept encoding gzip content length host localhost user agent go http client json origin url ,1 87368,10544380364.0,IssuesEvent,2019-10-02 16:48:15,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document Request.Host value in HTTP/2,Documentation NeedsFix,"HTTP/2 has `:authority` rather than Host, but I presume the Request.Host filed is filled in with that value for HTTP/2 requests. That should be documented. /cc @bradfitz ",1.0,"net/http: document Request.Host value in HTTP/2 - HTTP/2 has `:authority` rather than Host, but I presume the Request.Host filed is filled in with that value for HTTP/2 requests. That should be documented. /cc @bradfitz ",1,net http document request host value in http http has authority rather than host but i presume the request host filed is filled in with that value for http requests that should be documented cc bradfitz ,1 9444,4531817403.0,IssuesEvent,2016-09-08 04:56:46,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/coordinator: git sync to github going slowly,Builders,"@dsnet reports that the Github sync of the code is behind. Luckily we have logs now: http://farmer.golang.org/debug/watcher/go ``` watcher status for repo: ""go"" 2016-08-31T23:18:55Z 23s ago 35360 refs to push; pushing batch 2016-08-31T23:13:28Z 5m50s ago 35560 refs to push; pushing batch 2016-08-31T23:07:51Z 11m27s ago 35760 refs to push; pushing batch 2016-08-31T23:02:08Z 17m10s ago 35960 refs to push; pushing batch 2016-08-31T22:56:29Z 22m49s ago 36160 refs to push; pushing batch 2016-08-31T22:50:55Z 28m22s ago 36360 refs to push; pushing batch 2016-08-31T22:45:21Z 33m56s ago 36560 refs to push; pushing batch 2016-08-31T22:39:42Z 39m35s ago 36760 refs to push; pushing batch 2016-08-31T22:34:05Z 45m12s ago 36960 refs to push; pushing batch 2016-08-31T22:28:25Z 50m53s ago 37160 refs to push; pushing batch 2016-08-31T22:22:46Z 56m32s ago 37360 refs to push; pushing batch 2016-08-31T22:17:14Z 1h2m3s ago 37560 refs to push; pushing batch 2016-08-31T22:11:47Z 1h7m30s ago 37760 refs to push; pushing batch 2016-08-31T22:06:20Z 1h12m58s ago 37960 refs to push; pushing batch 2016-08-31T22:00:52Z 1h18m26s ago 38160 refs to push; pushing batch 2016-08-31T21:55:23Z 1h23m55s ago 38360 refs to push; pushing batch 2016-08-31T21:49:52Z 1h29m26s ago 38560 refs to push; pushing batch 2016-08-31T21:44:06Z 1h35m12s ago 38760 refs to push; pushing batch 2016-08-31T21:38:27Z 1h40m50s ago 38960 refs to push; pushing batch 2016-08-31T21:32:50Z 1h46m27s ago 39160 refs to push; pushing batch 2016-08-31T21:27:02Z 1h52m15s ago 39360 refs to push; pushing batch 2016-08-31T21:21:27Z 1h57m50s ago 39560 refs to push; pushing batch 2016-08-31T21:15:48Z 2h3m29s ago 39760 refs to push; pushing batch 2016-08-31T21:10:12Z 2h9m5s ago 39960 refs to push; pushing batch 2016-08-31T21:04:48Z 2h14m30s ago 40160 refs to push; pushing batch 2016-08-31T20:59:23Z 2h19m54s ago 40360 refs to push; pushing batch 2016-08-31T20:53:44Z 2h25m33s ago 40560 refs to push; pushing batch 2016-08-31T20:48:09Z 2h31m9s ago 40760 refs to push; pushing batch 2016-08-31T20:42:29Z 2h36m49s ago 40960 refs to push; pushing batch 2016-08-31T20:36:43Z 2h42m34s ago 41160 refs to push; pushing batch 2016-08-31T20:30:55Z 2h48m22s ago 41360 refs to push; pushing batch 2016-08-31T20:25:11Z 2h54m7s ago 41560 refs to push; pushing batch 2016-08-31T20:19:23Z 2h59m55s ago 41760 refs to push; pushing batch 2016-08-31T20:13:47Z 3h5m31s ago 41960 refs to push; pushing batch 2016-08-31T20:08:12Z 3h11m5s ago 42160 refs to push; pushing batch 2016-08-31T20:02:40Z 3h16m37s ago 42360 refs to push; pushing batch 2016-08-31T19:56:39Z 3h22m39s ago 42560 refs to push; pushing batch 2016-08-31T19:50:51Z 3h28m26s ago 42760 refs to push; pushing batch 2016-08-31T19:45:20Z 3h33m57s ago 42960 refs to push; pushing batch 2016-08-31T19:45:20Z 3h33m57s ago sync: got 0 remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: fetching remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: got 42960 local refs 2016-08-31T19:43:13Z 3h36m5s ago sync: fetching local refs 2016-08-31T19:43:13Z 3h36m5s ago syncing to github, attempt 2 2016-08-31T19:43:08Z 3h36m10s ago git push failure 2016-08-31T19:41:01Z 3h38m17s ago 1 refs to push; pushing batch 2016-08-31T19:41:01Z 3h38m17s ago sync: got 43078 remote refs 2016-08-31T19:41:00Z 3h38m18s ago sync: fetching remote refs 2016-08-31T19:41:00Z 3h38m18s ago sync: got 42960 local refs ``` This is where things went poorly: ``` 2016-08-31T19:45:20Z 3h33m57s ago sync: got 0 remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: fetching remote refs ``` The syncer got 0 remote refs from Github, so thought it had to push all 43000 refs, and has been working on it for the past 3 hours, doing 200 at a time, and doing them very slowly. Not sure why on either part. Last time we had problems we switched from the https git transport to the native and earlier ssh transport and things got super fast. Not sure why it's slow now. /cc @dsnet @broady @quentinmit ",1.0,"x/build/cmd/coordinator: git sync to github going slowly - @dsnet reports that the Github sync of the code is behind. Luckily we have logs now: http://farmer.golang.org/debug/watcher/go ``` watcher status for repo: ""go"" 2016-08-31T23:18:55Z 23s ago 35360 refs to push; pushing batch 2016-08-31T23:13:28Z 5m50s ago 35560 refs to push; pushing batch 2016-08-31T23:07:51Z 11m27s ago 35760 refs to push; pushing batch 2016-08-31T23:02:08Z 17m10s ago 35960 refs to push; pushing batch 2016-08-31T22:56:29Z 22m49s ago 36160 refs to push; pushing batch 2016-08-31T22:50:55Z 28m22s ago 36360 refs to push; pushing batch 2016-08-31T22:45:21Z 33m56s ago 36560 refs to push; pushing batch 2016-08-31T22:39:42Z 39m35s ago 36760 refs to push; pushing batch 2016-08-31T22:34:05Z 45m12s ago 36960 refs to push; pushing batch 2016-08-31T22:28:25Z 50m53s ago 37160 refs to push; pushing batch 2016-08-31T22:22:46Z 56m32s ago 37360 refs to push; pushing batch 2016-08-31T22:17:14Z 1h2m3s ago 37560 refs to push; pushing batch 2016-08-31T22:11:47Z 1h7m30s ago 37760 refs to push; pushing batch 2016-08-31T22:06:20Z 1h12m58s ago 37960 refs to push; pushing batch 2016-08-31T22:00:52Z 1h18m26s ago 38160 refs to push; pushing batch 2016-08-31T21:55:23Z 1h23m55s ago 38360 refs to push; pushing batch 2016-08-31T21:49:52Z 1h29m26s ago 38560 refs to push; pushing batch 2016-08-31T21:44:06Z 1h35m12s ago 38760 refs to push; pushing batch 2016-08-31T21:38:27Z 1h40m50s ago 38960 refs to push; pushing batch 2016-08-31T21:32:50Z 1h46m27s ago 39160 refs to push; pushing batch 2016-08-31T21:27:02Z 1h52m15s ago 39360 refs to push; pushing batch 2016-08-31T21:21:27Z 1h57m50s ago 39560 refs to push; pushing batch 2016-08-31T21:15:48Z 2h3m29s ago 39760 refs to push; pushing batch 2016-08-31T21:10:12Z 2h9m5s ago 39960 refs to push; pushing batch 2016-08-31T21:04:48Z 2h14m30s ago 40160 refs to push; pushing batch 2016-08-31T20:59:23Z 2h19m54s ago 40360 refs to push; pushing batch 2016-08-31T20:53:44Z 2h25m33s ago 40560 refs to push; pushing batch 2016-08-31T20:48:09Z 2h31m9s ago 40760 refs to push; pushing batch 2016-08-31T20:42:29Z 2h36m49s ago 40960 refs to push; pushing batch 2016-08-31T20:36:43Z 2h42m34s ago 41160 refs to push; pushing batch 2016-08-31T20:30:55Z 2h48m22s ago 41360 refs to push; pushing batch 2016-08-31T20:25:11Z 2h54m7s ago 41560 refs to push; pushing batch 2016-08-31T20:19:23Z 2h59m55s ago 41760 refs to push; pushing batch 2016-08-31T20:13:47Z 3h5m31s ago 41960 refs to push; pushing batch 2016-08-31T20:08:12Z 3h11m5s ago 42160 refs to push; pushing batch 2016-08-31T20:02:40Z 3h16m37s ago 42360 refs to push; pushing batch 2016-08-31T19:56:39Z 3h22m39s ago 42560 refs to push; pushing batch 2016-08-31T19:50:51Z 3h28m26s ago 42760 refs to push; pushing batch 2016-08-31T19:45:20Z 3h33m57s ago 42960 refs to push; pushing batch 2016-08-31T19:45:20Z 3h33m57s ago sync: got 0 remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: fetching remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: got 42960 local refs 2016-08-31T19:43:13Z 3h36m5s ago sync: fetching local refs 2016-08-31T19:43:13Z 3h36m5s ago syncing to github, attempt 2 2016-08-31T19:43:08Z 3h36m10s ago git push failure 2016-08-31T19:41:01Z 3h38m17s ago 1 refs to push; pushing batch 2016-08-31T19:41:01Z 3h38m17s ago sync: got 43078 remote refs 2016-08-31T19:41:00Z 3h38m18s ago sync: fetching remote refs 2016-08-31T19:41:00Z 3h38m18s ago sync: got 42960 local refs ``` This is where things went poorly: ``` 2016-08-31T19:45:20Z 3h33m57s ago sync: got 0 remote refs 2016-08-31T19:43:13Z 3h36m4s ago sync: fetching remote refs ``` The syncer got 0 remote refs from Github, so thought it had to push all 43000 refs, and has been working on it for the past 3 hours, doing 200 at a time, and doing them very slowly. Not sure why on either part. Last time we had problems we switched from the https git transport to the native and earlier ssh transport and things got super fast. Not sure why it's slow now. /cc @dsnet @broady @quentinmit ",0,x build cmd coordinator git sync to github going slowly dsnet reports that the github sync of the code is behind luckily we have logs now watcher status for repo go ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago refs to push pushing batch ago sync got remote refs ago sync fetching remote refs ago sync got local refs ago sync fetching local refs ago syncing to github attempt ago git push failure ago refs to push pushing batch ago sync got remote refs ago sync fetching remote refs ago sync got local refs this is where things went poorly ago sync got remote refs ago sync fetching remote refs the syncer got remote refs from github so thought it had to push all refs and has been working on it for the past hours doing at a time and doing them very slowly not sure why on either part last time we had problems we switched from the https git transport to the native and earlier ssh transport and things got super fast not sure why it s slow now cc dsnet broady quentinmit ,0 115586,11882665464.0,IssuesEvent,2020-03-27 14:45:32,golang/go,https://api.github.com/repos/golang/go,opened,cmd/asm: update where NOFRAME is valid,Documentation,"The current comment for `NOFRAME` in `runtime/textflag.h` says: ``` // TODO(mwhudson): only implemented for ppc64x at present. ``` It's been implemented for lots (all?) architectures since. Check our coverage and update (delete) this comment. @mwhudson @zhangfannie ",1.0,"cmd/asm: update where NOFRAME is valid - The current comment for `NOFRAME` in `runtime/textflag.h` says: ``` // TODO(mwhudson): only implemented for ppc64x at present. ``` It's been implemented for lots (all?) architectures since. Check our coverage and update (delete) this comment. @mwhudson @zhangfannie ",1,cmd asm update where noframe is valid the current comment for noframe in runtime textflag h says todo mwhudson only implemented for at present it s been implemented for lots all architectures since check our coverage and update delete this comment mwhudson zhangfannie ,1 70633,18243693197.0,IssuesEvent,2021-10-01 15:38:20,golang/go,https://api.github.com/repos/golang/go,opened,x/build/cmd/gomote: enable Identity Aware Proxy,Builders NeedsInvestigation,"This tracks the enabling of Identity Aware Proxy for the new gomote API and its associated work. This is a component of the project to revamp the security model used by gomote #47521 @golang/release ",1.0,"x/build/cmd/gomote: enable Identity Aware Proxy - This tracks the enabling of Identity Aware Proxy for the new gomote API and its associated work. This is a component of the project to revamp the security model used by gomote #47521 @golang/release ",0,x build cmd gomote enable identity aware proxy this tracks the enabling of identity aware proxy for the new gomote api and its associated work this is a component of the project to revamp the security model used by gomote golang release ,0 8843,3226051888.0,IssuesEvent,2015-10-10 00:49:18,golang/go,https://api.github.com/repos/golang/go,closed,compress/flate: Inconsistent error handling,Documentation,"The package defines a ReadError which ""reports an error encountered while reading input"" and a WriteError which ""reports an error encountered while writing output"". However, a quick peruse through the package code shows that WriteError is never used. Secondly, its use of ReadError is inconsistent. There are 3 instances where the Reader is used in inflate.go: [L635](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L635), [L677](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L667), and [L699](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L699). The call to ReadByte lacks a the wrapper for ReadError. Interestingly, the bulk of DEFLATE compression will be done through the ReadByte call, thus, usage of ReadError seems to only occur when decoding a raw block. Should use of ReadError and WriteError be removed and marked as deprecated? Or should the library properly handle both error types? Other packages don't seem to wrap IO errors with package specific errors.",1.0,"compress/flate: Inconsistent error handling - The package defines a ReadError which ""reports an error encountered while reading input"" and a WriteError which ""reports an error encountered while writing output"". However, a quick peruse through the package code shows that WriteError is never used. Secondly, its use of ReadError is inconsistent. There are 3 instances where the Reader is used in inflate.go: [L635](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L635), [L677](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L667), and [L699](https://github.com/golang/go/blob/b03129aa2758a337823071ffda37e49da5a814d0/src/compress/flate/inflate.go#L699). The call to ReadByte lacks a the wrapper for ReadError. Interestingly, the bulk of DEFLATE compression will be done through the ReadByte call, thus, usage of ReadError seems to only occur when decoding a raw block. Should use of ReadError and WriteError be removed and marked as deprecated? Or should the library properly handle both error types? Other packages don't seem to wrap IO errors with package specific errors.",1,compress flate inconsistent error handling the package defines a readerror which reports an error encountered while reading input and a writeerror which reports an error encountered while writing output however a quick peruse through the package code shows that writeerror is never used secondly its use of readerror is inconsistent there are instances where the reader is used in inflate go and the call to readbyte lacks a the wrapper for readerror interestingly the bulk of deflate compression will be done through the readbyte call thus usage of readerror seems to only occur when decoding a raw block should use of readerror and writeerror be removed and marked as deprecated or should the library properly handle both error types other packages don t seem to wrap io errors with package specific errors ,1 126941,10440858504.0,IssuesEvent,2019-09-18 09:34:14,golang/go,https://api.github.com/repos/golang/go,reopened,syscall: TestAmbientCapsUserns test failing with operation not permitted,NeedsInvestigation Testing," ### What version of Go are you using (`go version`)? 
$ go version
1.13-rc2
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? Ubuntu devel, 19.10 ### What did you do? trying to build the source code, I get ``` ok sync/atomic 0.047s --- FAIL: TestAmbientCapsUserns (0.00s) exec_linux_test.go:667: fork/exec /tmp/gotest465803457: operation not permitted FAIL FAIL syscall 0.033s ``` I suspect Ubuntu builders should ignore that test?",1.0,"syscall: TestAmbientCapsUserns test failing with operation not permitted - ### What version of Go are you using (`go version`)? 
$ go version
1.13-rc2
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? Ubuntu devel, 19.10 ### What did you do? trying to build the source code, I get ``` ok sync/atomic 0.047s --- FAIL: TestAmbientCapsUserns (0.00s) exec_linux_test.go:667: fork/exec /tmp/gotest465803457: operation not permitted FAIL FAIL syscall 0.033s ``` I suspect Ubuntu builders should ignore that test?",0,syscall testambientcapsuserns test failing with operation not permitted what version of go are you using go version go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env ubuntu devel what did you do trying to build the source code i get ok sync atomic fail testambientcapsuserns exec linux test go fork exec tmp operation not permitted fail fail syscall i suspect ubuntu builders should ignore that test ,0 123510,12199938714.0,IssuesEvent,2020-04-30 03:08:29,golang/go,https://api.github.com/repos/golang/go,closed,debug/gosym: Table.Files doc is stale?,Documentation NeedsInvestigation,"https://golang.org/pkg/debug/gosym/#Table says: ```go Files map[string]*Obj // nil for Go 1.2 and later binaries ``` But empirically that is not true. It's populated. And https://golang.org/pkg/debug/gosym/#Obj.Paths says: > // Use the keys of Table.Files to obtain a list of source files. ... which further suggests it's meant to be non-nil. /cc @randall77 @ianlancetaylor (not sure who owns this) ",1.0,"debug/gosym: Table.Files doc is stale? - https://golang.org/pkg/debug/gosym/#Table says: ```go Files map[string]*Obj // nil for Go 1.2 and later binaries ``` But empirically that is not true. It's populated. And https://golang.org/pkg/debug/gosym/#Obj.Paths says: > // Use the keys of Table.Files to obtain a list of source files. ... which further suggests it's meant to be non-nil. /cc @randall77 @ianlancetaylor (not sure who owns this) ",1,debug gosym table files doc is stale says go files map obj nil for go and later binaries but empirically that is not true it s populated and says use the keys of table files to obtain a list of source files which further suggests it s meant to be non nil cc ianlancetaylor not sure who owns this ,1 16172,4021320195.0,IssuesEvent,2016-05-16 21:30:58,golang/go,https://api.github.com/repos/golang/go,closed,doc: update docs as a followup of deprecation of 1.4 dependent code in x/tools,Documentation,"A few packages in golang.org/x/tools have been removed as part of https://groups.google.com/forum/#!topic/golang-announce/qu_rAphYdxY, and the deletion makes a few dead links on https://golang.org/doc/cmd; e.g., https://godoc.org/golang.org/x/tools/cmd/vet. It needs to be updated for avoiding confusion.",1.0,"doc: update docs as a followup of deprecation of 1.4 dependent code in x/tools - A few packages in golang.org/x/tools have been removed as part of https://groups.google.com/forum/#!topic/golang-announce/qu_rAphYdxY, and the deletion makes a few dead links on https://golang.org/doc/cmd; e.g., https://godoc.org/golang.org/x/tools/cmd/vet. It needs to be updated for avoiding confusion.",1,doc update docs as a followup of deprecation of dependent code in x tools a few packages in golang org x tools have been removed as part of and the deletion makes a few dead links on e g it needs to be updated for avoiding confusion ,1 3198,2743660174.0,IssuesEvent,2015-04-21 23:15:17,golang/go,https://api.github.com/repos/golang/go,closed,math/big: clarify addVW and subVW preconditions,Documentation,"I'm working on an arm64 math/big implementation. The docs for addVW (arith.go) say: ```go // Argument y must be either 0 or 1. func addVW_g(z, x []Word, y Word) (c Word) ``` But e.g. running `TestFloatSetPrec` sends in many values for y. The existing implementations handle them correctly. I care because my initial arm64 implementation transfers y directly to the carry flag at the start, which only works if y is 0 or 1. subVW does not say that y must be either 0 or 1, but in practice it appears to be, and the semantics are less clear if it is not. However, TestFunVW appears to intentionally send in y=2 to confirm that there's no bad behavior when z and x are nil. What preconditions do addVW and subVW actually have? @griesemer feel free to clarify here or just send a CL. (Additional docs in general in arith.go would be awesome. Right now I'm inferring shlVU and friends from the existing code.) ",1.0,"math/big: clarify addVW and subVW preconditions - I'm working on an arm64 math/big implementation. The docs for addVW (arith.go) say: ```go // Argument y must be either 0 or 1. func addVW_g(z, x []Word, y Word) (c Word) ``` But e.g. running `TestFloatSetPrec` sends in many values for y. The existing implementations handle them correctly. I care because my initial arm64 implementation transfers y directly to the carry flag at the start, which only works if y is 0 or 1. subVW does not say that y must be either 0 or 1, but in practice it appears to be, and the semantics are less clear if it is not. However, TestFunVW appears to intentionally send in y=2 to confirm that there's no bad behavior when z and x are nil. What preconditions do addVW and subVW actually have? @griesemer feel free to clarify here or just send a CL. (Additional docs in general in arith.go would be awesome. Right now I'm inferring shlVU and friends from the existing code.) ",1,math big clarify addvw and subvw preconditions i m working on an math big implementation the docs for addvw arith go say go argument y must be either or func addvw g z x word y word c word but e g running testfloatsetprec sends in many values for y the existing implementations handle them correctly i care because my initial implementation transfers y directly to the carry flag at the start which only works if y is or subvw does not say that y must be either or but in practice it appears to be and the semantics are less clear if it is not however testfunvw appears to intentionally send in y to confirm that there s no bad behavior when z and x are nil what preconditions do addvw and subvw actually have griesemer feel free to clarify here or just send a cl additional docs in general in arith go would be awesome right now i m inferring shlvu and friends from the existing code ,1 21592,4727222019.0,IssuesEvent,2016-10-18 12:54:20,golang/go,https://api.github.com/repos/golang/go,closed,io: PipeWriter.Write should not block when writing zero bytes,Documentation NeedsDecision,"`io.PipeWriter.Write([]byte{})` blocks when no readers are waiting at the other end of the pipe. To unblock the pipe **zero** or more bytes must be read from `io.PipeWriter.Read`. I expect `io.PipeWriter.Write([]byte{})` to not ever block. See https://groups.google.com/forum/#!topic/golang-nuts/nRPhBt0zoAM for the discussion. See http://play.golang.org/p/MNSyKafKYf for an example.",1.0,"io: PipeWriter.Write should not block when writing zero bytes - `io.PipeWriter.Write([]byte{})` blocks when no readers are waiting at the other end of the pipe. To unblock the pipe **zero** or more bytes must be read from `io.PipeWriter.Read`. I expect `io.PipeWriter.Write([]byte{})` to not ever block. See https://groups.google.com/forum/#!topic/golang-nuts/nRPhBt0zoAM for the discussion. See http://play.golang.org/p/MNSyKafKYf for an example.",1,io pipewriter write should not block when writing zero bytes io pipewriter write byte blocks when no readers are waiting at the other end of the pipe to unblock the pipe zero or more bytes must be read from io pipewriter read i expect io pipewriter write byte to not ever block see for the discussion see for an example ,1 200715,22833841366.0,IssuesEvent,2022-07-12 14:59:22,golang/go,https://api.github.com/repos/golang/go,closed,net/http/httputil: NewSingleHostReverseProxy - omit X-Forwarded-For not working [1.18 backport],Security release-blocker CherryPickApproved,"@neild requested issue #53423 to be considered for backport to the next 1.18 minor release. > @gopherbot please open backport issues. ",True,"net/http/httputil: NewSingleHostReverseProxy - omit X-Forwarded-For not working [1.18 backport] - @neild requested issue #53423 to be considered for backport to the next 1.18 minor release. > @gopherbot please open backport issues. ",0,net http httputil newsinglehostreverseproxy omit x forwarded for not working neild requested issue to be considered for backport to the next minor release gopherbot please open backport issues ,0 106231,11473388820.0,IssuesEvent,2020-02-09 22:51:10,golang/go,https://api.github.com/repos/golang/go,closed,wiki: SettingGOPATH (redesign),Documentation NeedsInvestigation,"suggested to overwrite that [page](https://github.com/golang/go/wiki/SettingGOPATH) Basic information on GOPATH is accessible by typing `go help gopath`. ``` $ go help gopath | head -7 The Go path is used to resolve import statements. It is implemented by and documented in the go/build package. The GOPATH environment variable lists places to look for Go code. On Unix, the value is a colon-separated string. On Windows, the value is a semicolon-separated string. On Plan 9, the value is a list. $ ``` The value is unset, but a default is encoded in the go compiler. ($HOME/go on Unix, %USERPROFILE%\go on Windows, and $home/go on Plan 9) login shells (Unix) ``` $ echo ""export GOPATH=$HOME/go"" >> ~/.profile $ ``` ``` % echo ""setenv GOPATH $HOME/go"" >> ~/.login % ``` interactive shells (Unix) ``` $ echo ""export GOPATH=$HOME/go"" >> ~/.bashrc $ ``` ``` % echo ""setenv GOPATH $HOME/go"" >> ~/.cshrc % ``` sourced files (Unix) ``` $ cat gopher # GNU Bourne-Again SHell export GOPATH=$HOME/go:/usr/share/gocode $ . ~/gopher $ ``` ``` % cat go-gopher # Berkeley UNIX C shell setenv GOPATH $HOME/go:/usr/share/gocode % source ~/go-gopher % ``` scripts (Windows) ``` C:\>TYPE gopher.bat @ECHO OFF SET GOPATH=%USERPROFILE%\go C:\> ``` ``` PS C:\> gc gopher.ps1 $env:GOPATH = ""$HOME\go"" PS C:\> .\gopher.ps1 PS C:\> ``` sourced file (Plan 9) ``` % cat gopher # Rc shell (usually a value of a single component) GOPATH=$home/go % . gopher % ``` using GOENV (all) ``` $ go version go version go1.13.3 linux/386 $ ed $GOROOT/src/os/file.go 17452 406,415p // UserConfigDir returns the default root directory to use for user-specific // configuration data. Users should create their own application-specific // subdirectory within this one and use that. // // On Unix systems, it returns $XDG_CONFIG_HOME as specified by // https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html if // non-empty, else $HOME/.config. // On Darwin, it returns $HOME/Library/Application Support. // On Windows, it returns %AppData%. // On Plan 9, it returns $home/lib. q $ ``` NB: The root of the Go tree cannot be included as a value in the Go path.",1.0,"wiki: SettingGOPATH (redesign) - suggested to overwrite that [page](https://github.com/golang/go/wiki/SettingGOPATH) Basic information on GOPATH is accessible by typing `go help gopath`. ``` $ go help gopath | head -7 The Go path is used to resolve import statements. It is implemented by and documented in the go/build package. The GOPATH environment variable lists places to look for Go code. On Unix, the value is a colon-separated string. On Windows, the value is a semicolon-separated string. On Plan 9, the value is a list. $ ``` The value is unset, but a default is encoded in the go compiler. ($HOME/go on Unix, %USERPROFILE%\go on Windows, and $home/go on Plan 9) login shells (Unix) ``` $ echo ""export GOPATH=$HOME/go"" >> ~/.profile $ ``` ``` % echo ""setenv GOPATH $HOME/go"" >> ~/.login % ``` interactive shells (Unix) ``` $ echo ""export GOPATH=$HOME/go"" >> ~/.bashrc $ ``` ``` % echo ""setenv GOPATH $HOME/go"" >> ~/.cshrc % ``` sourced files (Unix) ``` $ cat gopher # GNU Bourne-Again SHell export GOPATH=$HOME/go:/usr/share/gocode $ . ~/gopher $ ``` ``` % cat go-gopher # Berkeley UNIX C shell setenv GOPATH $HOME/go:/usr/share/gocode % source ~/go-gopher % ``` scripts (Windows) ``` C:\>TYPE gopher.bat @ECHO OFF SET GOPATH=%USERPROFILE%\go C:\> ``` ``` PS C:\> gc gopher.ps1 $env:GOPATH = ""$HOME\go"" PS C:\> .\gopher.ps1 PS C:\> ``` sourced file (Plan 9) ``` % cat gopher # Rc shell (usually a value of a single component) GOPATH=$home/go % . gopher % ``` using GOENV (all) ``` $ go version go version go1.13.3 linux/386 $ ed $GOROOT/src/os/file.go 17452 406,415p // UserConfigDir returns the default root directory to use for user-specific // configuration data. Users should create their own application-specific // subdirectory within this one and use that. // // On Unix systems, it returns $XDG_CONFIG_HOME as specified by // https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html if // non-empty, else $HOME/.config. // On Darwin, it returns $HOME/Library/Application Support. // On Windows, it returns %AppData%. // On Plan 9, it returns $home/lib. q $ ``` NB: The root of the Go tree cannot be included as a value in the Go path.",1,wiki settinggopath redesign suggested to overwrite that basic information on gopath is accessible by typing go help gopath go help gopath head the go path is used to resolve import statements it is implemented by and documented in the go build package the gopath environment variable lists places to look for go code on unix the value is a colon separated string on windows the value is a semicolon separated string on plan the value is a list the value is unset but a default is encoded in the go compiler home go on unix userprofile go on windows and home go on plan login shells unix echo export gopath home go profile echo setenv gopath home go login interactive shells unix echo export gopath home go bashrc echo setenv gopath home go cshrc sourced files unix cat gopher gnu bourne again shell export gopath home go usr share gocode gopher cat go gopher berkeley unix c shell setenv gopath home go usr share gocode source go gopher scripts windows c type gopher bat echo off set gopath userprofile go c ps c gc gopher env gopath home go ps c gopher ps c sourced file plan cat gopher rc shell usually a value of a single component gopath home go gopher using goenv all go version go version linux ed goroot src os file go userconfigdir returns the default root directory to use for user specific configuration data users should create their own application specific subdirectory within this one and use that on unix systems it returns xdg config home as specified by if non empty else home config on darwin it returns home library application support on windows it returns appdata on plan it returns home lib q nb the root of the go tree cannot be included as a value in the go path ,1 130269,12425750074.0,IssuesEvent,2020-05-24 17:47:38,golang/go,https://api.github.com/repos/golang/go,closed,syscall/js: document more clearly how early js.Func can be released,Arch-Wasm Documentation NeedsFix OS-JS,"The documentation for [`js.Func`](https://pkg.go.dev/syscall/js#Func) currently says: > Func.Release must be called to free up resources when the function will not be used any more. > Release frees up resources allocated for the function. The function must not be invoked after calling Release. Based on [a comment](https://go-review.googlesource.com/c/go/+/226204/2/src/net/http/roundtrip_js.go#113) from @neelance and my understanding of the code, it seems the intention is for it to be safe to release a `js.Func` at a time when no future invocations of the `js.Func` will be made. An invocation here means the time the execution begins. So, if a `js.Func` will only be invoked once, it is safe to release a `js.Func` right away in the Go function that will be executing: ```Go var f js.Func f = js.FuncOf(func(this js.Value, args []js.Value) interface{} { f.Release() // okay, even though this Go function is still in the middle of executing ... ``` I believe the documentation needs to make this more clear, so that users can rely on this behavior. /cc @neelance @hajimehoshi @johanbrandhorst",1.0,"syscall/js: document more clearly how early js.Func can be released - The documentation for [`js.Func`](https://pkg.go.dev/syscall/js#Func) currently says: > Func.Release must be called to free up resources when the function will not be used any more. > Release frees up resources allocated for the function. The function must not be invoked after calling Release. Based on [a comment](https://go-review.googlesource.com/c/go/+/226204/2/src/net/http/roundtrip_js.go#113) from @neelance and my understanding of the code, it seems the intention is for it to be safe to release a `js.Func` at a time when no future invocations of the `js.Func` will be made. An invocation here means the time the execution begins. So, if a `js.Func` will only be invoked once, it is safe to release a `js.Func` right away in the Go function that will be executing: ```Go var f js.Func f = js.FuncOf(func(this js.Value, args []js.Value) interface{} { f.Release() // okay, even though this Go function is still in the middle of executing ... ``` I believe the documentation needs to make this more clear, so that users can rely on this behavior. /cc @neelance @hajimehoshi @johanbrandhorst",1,syscall js document more clearly how early js func can be released the documentation for currently says func release must be called to free up resources when the function will not be used any more release frees up resources allocated for the function the function must not be invoked after calling release based on from neelance and my understanding of the code it seems the intention is for it to be safe to release a js func at a time when no future invocations of the js func will be made an invocation here means the time the execution begins so if a js func will only be invoked once it is safe to release a js func right away in the go function that will be executing go var f js func f js funcof func this js value args js value interface f release okay even though this go function is still in the middle of executing i believe the documentation needs to make this more clear so that users can rely on this behavior cc neelance hajimehoshi johanbrandhorst,1 24332,5050089162.0,IssuesEvent,2016-12-20 17:39:15,golang/go,https://api.github.com/repos/golang/go,closed,net: LookupCNAME only works for hostnames with CNAME records,Documentation NeedsFix,"### What version of Go are you using (`go version`)? `go version go1.7.3 linux/amd64` ### What operating system and processor architecture are you using (`go env`)? ```sh GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH="""" GORACE="""" GOROOT=""/usr/lib/google-golang"" GOTOOLDIR=""/usr/lib/google-golang/pkg/tool/linux_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build668040631=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" ``` ### What did you do? ```go package main import ( ""fmt"" ""net"" ) func main() { if cname, err := net.LookupCNAME(""www.google.com""); err != nil { fmt.Printf(""lookup failed: %q\n"", err) } else { fmt.Printf(""lookup success: %s\n"", cname) } } ``` ### What did you expect to see? [The documentation](https://golang.org/pkg/net/#LookupCNAME) says ""LookupCNAME returns the canonical DNS host for the given name."" To me, this means that it returns the canonical name as provided by the [POSIX `getaddrinfo()` function](http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html) when given the `AI_CANONNAME` flag. So I expected the following: `lookup success: www.google.com` ### What did you see instead? `lookup failed: ""lookup www.google.com on 127.0.1.1:53: no such host""` It turns out that `LookupCNAME` simply resolves CNAME records, it does NOT return the canonical DNS host for the given name as documented. ### Proposed change Ideally `LookupCNAME` would return the canonical hostname as provided by the POSIX `getaddrinfo()` function. If the intention of the `LookupCNAME` function is to only resolve CNAME records, then replace the first sentence of the documentation with: > LookupCNAME resolves the CNAME DNS record for the given name. It is an error if the given hostname does not have a CNAME record.",1.0,"net: LookupCNAME only works for hostnames with CNAME records - ### What version of Go are you using (`go version`)? `go version go1.7.3 linux/amd64` ### What operating system and processor architecture are you using (`go env`)? ```sh GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH="""" GORACE="""" GOROOT=""/usr/lib/google-golang"" GOTOOLDIR=""/usr/lib/google-golang/pkg/tool/linux_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build668040631=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" ``` ### What did you do? ```go package main import ( ""fmt"" ""net"" ) func main() { if cname, err := net.LookupCNAME(""www.google.com""); err != nil { fmt.Printf(""lookup failed: %q\n"", err) } else { fmt.Printf(""lookup success: %s\n"", cname) } } ``` ### What did you expect to see? [The documentation](https://golang.org/pkg/net/#LookupCNAME) says ""LookupCNAME returns the canonical DNS host for the given name."" To me, this means that it returns the canonical name as provided by the [POSIX `getaddrinfo()` function](http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html) when given the `AI_CANONNAME` flag. So I expected the following: `lookup success: www.google.com` ### What did you see instead? `lookup failed: ""lookup www.google.com on 127.0.1.1:53: no such host""` It turns out that `LookupCNAME` simply resolves CNAME records, it does NOT return the canonical DNS host for the given name as documented. ### Proposed change Ideally `LookupCNAME` would return the canonical hostname as provided by the POSIX `getaddrinfo()` function. If the intention of the `LookupCNAME` function is to only resolve CNAME records, then replace the first sentence of the documentation with: > LookupCNAME resolves the CNAME DNS record for the given name. It is an error if the given hostname does not have a CNAME record.",1,net lookupcname only works for hostnames with cname records what version of go are you using go version go version linux what operating system and processor architecture are you using go env sh goarch gobin goexe gohostarch gohostos linux goos linux gopath gorace goroot usr lib google golang gotooldir usr lib google golang pkg tool linux cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled what did you do go package main import fmt net func main if cname err net lookupcname err nil fmt printf lookup failed q n err else fmt printf lookup success s n cname what did you expect to see says lookupcname returns the canonical dns host for the given name to me this means that it returns the canonical name as provided by the when given the ai canonname flag so i expected the following lookup success what did you see instead lookup failed lookup on no such host it turns out that lookupcname simply resolves cname records it does not return the canonical dns host for the given name as documented proposed change ideally lookupcname would return the canonical hostname as provided by the posix getaddrinfo function if the intention of the lookupcname function is to only resolve cname records then replace the first sentence of the documentation with lookupcname resolves the cname dns record for the given name it is an error if the given hostname does not have a cname record ,1 12290,3594534024.0,IssuesEvent,2016-02-02 00:10:50,golang/go,https://api.github.com/repos/golang/go,closed,blog: /race-detector points to a dead link ,Documentation,`go get -race code.google.com/p/go.blog/support/racy` should be `go get -race golang.org/x/blog/support/racy`,1.0,blog: /race-detector points to a dead link - `go get -race code.google.com/p/go.blog/support/racy` should be `go get -race golang.org/x/blog/support/racy`,1,blog race detector points to a dead link go get race code google com p go blog support racy should be go get race golang org x blog support racy ,1 23419,4934573006.0,IssuesEvent,2016-11-28 19:28:17,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that Etags in ServeContent must be RFC 7232 compliant,Documentation,"Change f3862742b67a84edf939f41276360ada4e7197a6 ([CL/32014](http://golang.org/cl/32014)) caused a regression in the behavior of http.ServeContent such that explicitly setting the Etag no longer caused the server to return status 304 when the Etags match. ```go func Test(t *testing.T) { fs := http.FileServer(http.Dir(""/tmp"")) h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // Delete if-modified-since header so that ETags can be used instead of the standard cache policy. r.Header.Del(""If-Modified-Since"") // Set ETag to to uniquely identify the unchanged static asset. w.Header().Set(""Etag"", ""6"") fs.ServeHTTP(w, r) }) ts := httptest.NewServer(h) // Ensure /tmp/test.txt exists. if err := ioutil.WriteFile(""/tmp/test.txt"", nil, 0664); err != nil { t.Fatal(err) } var c http.Client req, err := http.NewRequest(""GET"", ts.URL+""/test.txt"", nil) if err != nil { t.Fatal(err) } req.Header.Add(""If-None-Match"", ""6"") // Same Etag as above resp, err := c.Do(req) if err != nil { t.Fatal(err) } if resp.StatusCode != 304 { t.Error() } } ``` I believe this is a regression because the documentation for `ServeContent` explicitly says: > If the caller has set w's ETag header, ServeContent uses it to handle requests using If-Range and If-None-Match. \cc @bradfitz ",1.0,"net/http: document that Etags in ServeContent must be RFC 7232 compliant - Change f3862742b67a84edf939f41276360ada4e7197a6 ([CL/32014](http://golang.org/cl/32014)) caused a regression in the behavior of http.ServeContent such that explicitly setting the Etag no longer caused the server to return status 304 when the Etags match. ```go func Test(t *testing.T) { fs := http.FileServer(http.Dir(""/tmp"")) h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // Delete if-modified-since header so that ETags can be used instead of the standard cache policy. r.Header.Del(""If-Modified-Since"") // Set ETag to to uniquely identify the unchanged static asset. w.Header().Set(""Etag"", ""6"") fs.ServeHTTP(w, r) }) ts := httptest.NewServer(h) // Ensure /tmp/test.txt exists. if err := ioutil.WriteFile(""/tmp/test.txt"", nil, 0664); err != nil { t.Fatal(err) } var c http.Client req, err := http.NewRequest(""GET"", ts.URL+""/test.txt"", nil) if err != nil { t.Fatal(err) } req.Header.Add(""If-None-Match"", ""6"") // Same Etag as above resp, err := c.Do(req) if err != nil { t.Fatal(err) } if resp.StatusCode != 304 { t.Error() } } ``` I believe this is a regression because the documentation for `ServeContent` explicitly says: > If the caller has set w's ETag header, ServeContent uses it to handle requests using If-Range and If-None-Match. \cc @bradfitz ",1,net http document that etags in servecontent must be rfc compliant change caused a regression in the behavior of http servecontent such that explicitly setting the etag no longer caused the server to return status when the etags match go func test t testing t fs http fileserver http dir tmp h http handlerfunc func w http responsewriter r http request delete if modified since header so that etags can be used instead of the standard cache policy r header del if modified since set etag to to uniquely identify the unchanged static asset w header set etag fs servehttp w r ts httptest newserver h ensure tmp test txt exists if err ioutil writefile tmp test txt nil err nil t fatal err var c http client req err http newrequest get ts url test txt nil if err nil t fatal err req header add if none match same etag as above resp err c do req if err nil t fatal err if resp statuscode t error i believe this is a regression because the documentation for servecontent explicitly says if the caller has set w s etag header servecontent uses it to handle requests using if range and if none match cc bradfitz ,1 47181,24900544238.0,IssuesEvent,2022-10-28 20:21:48,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: deepCompletionState.enqueue is an allocation hotspot,gopls Tools gopls/performance,"I noticed while running `TestBenchmarkConfiguredCompletion` on k8s that `deepCompletionState.enqueue` ``` func (s *deepCompletionState) enqueue(cand candidate) { s.nextQueue = append(s.nextQueue, cand) } ``` allocates 10GB of memory because it adds 5 million completion candidates to the queue, each being an 18-word structure. This causes each call of `env.Completion` in the benchmark to take 10s. There are two calls, the warmup and the one in the b.N loop (which only reaches N=1). This was the command. The .go file is my favorite large file in k8s. ``` $ go test -bench=TestBenchmarkConfiguredCompletion ./gopls/internal/regtest/bench -completion_workdir=$HOME/w/kubernetes -completion_file=../kubernetes/pkg/generated/openapi/zz_generated.openapi.go -completion_regexp=Get ``` Also, 2GB (and 3s CPU) are spent on this call to `Type.String` in `completer.methodsAndFields`: ``` if typ.String() == ""*testing.F"" && addressable { // is that a sufficient test? (or is more care needed?) if c.fuzz(typ, mset, imp, cb, c.snapshot.FileSet()) { return } } ``` @muirdm",True,"x/tools/gopls: deepCompletionState.enqueue is an allocation hotspot - I noticed while running `TestBenchmarkConfiguredCompletion` on k8s that `deepCompletionState.enqueue` ``` func (s *deepCompletionState) enqueue(cand candidate) { s.nextQueue = append(s.nextQueue, cand) } ``` allocates 10GB of memory because it adds 5 million completion candidates to the queue, each being an 18-word structure. This causes each call of `env.Completion` in the benchmark to take 10s. There are two calls, the warmup and the one in the b.N loop (which only reaches N=1). This was the command. The .go file is my favorite large file in k8s. ``` $ go test -bench=TestBenchmarkConfiguredCompletion ./gopls/internal/regtest/bench -completion_workdir=$HOME/w/kubernetes -completion_file=../kubernetes/pkg/generated/openapi/zz_generated.openapi.go -completion_regexp=Get ``` Also, 2GB (and 3s CPU) are spent on this call to `Type.String` in `completer.methodsAndFields`: ``` if typ.String() == ""*testing.F"" && addressable { // is that a sufficient test? (or is more care needed?) if c.fuzz(typ, mset, imp, cb, c.snapshot.FileSet()) { return } } ``` @muirdm",0,x tools gopls deepcompletionstate enqueue is an allocation hotspot i noticed while running testbenchmarkconfiguredcompletion on that deepcompletionstate enqueue func s deepcompletionstate enqueue cand candidate s nextqueue append s nextqueue cand allocates of memory because it adds million completion candidates to the queue each being an word structure this causes each call of env completion in the benchmark to take there are two calls the warmup and the one in the b n loop which only reaches n this was the command the go file is my favorite large file in go test bench testbenchmarkconfiguredcompletion gopls internal regtest bench completion workdir home w kubernetes completion file kubernetes pkg generated openapi zz generated openapi go completion regexp get also and cpu are spent on this call to type string in completer methodsandfields if typ string testing f addressable is that a sufficient test or is more care needed if c fuzz typ mset imp cb c snapshot fileset return muirdm,0 64942,8780250670.0,IssuesEvent,2018-12-19 16:48:24,golang/go,https://api.github.com/repos/golang/go,reopened,documentation: modules quick start example does not work,Documentation WaitingForInfo modules," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/test/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/test/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/tmp/scratchpad/hello/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=/tmp/go-build952622232=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Followed the quick-start example from the Go 1.11 Wiki page. Link: [https://github.com/golang/go/wiki/Modules#quick-start-example](https://github.com/golang/go/wiki/Modules#quick-start-example) ### What did you expect to see? It work ### What did you see instead? Error after running `go build` the first time. 
build github.com/you/hello: cannot find module for path rsc.io/quote
",1.0,"documentation: modules quick start example does not work - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/test/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/test/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/tmp/scratchpad/hello/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=/tmp/go-build952622232=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Followed the quick-start example from the Go 1.11 Wiki page. Link: [https://github.com/golang/go/wiki/Modules#quick-start-example](https://github.com/golang/go/wiki/Modules#quick-start-example) ### What did you expect to see? It work ### What did you see instead? Error after running `go build` the first time. 
build github.com/you/hello: cannot find module for path rsc.io/quote
",1,documentation modules quick start example does not work what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home test cache go build goexe goflags gohostarch gohostos linux goos linux gopath home test go goproxy gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod tmp scratchpad hello go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do followed the quick start example from the go wiki page link what did you expect to see it work what did you see instead error after running go build the first time build github com you hello cannot find module for path rsc io quote ,1 94249,27152148559.0,IssuesEvent,2023-02-17 02:50:44,golang/go,https://api.github.com/repos/golang/go,closed,x/build: linux-amd64-wsl builder failing,Builders NeedsFix,"The linux-amd64-wsl builder (owned by @mengzhuo) flipped abruptly from almost always passing to almost always failing on December 13, 2022: On the main branch, it happened first on [CL 457055](https://go.dev/cl/457055) on Dec 13. But it also started happening on 1.19 and 1.18 release branches on a completely unrelated change ([CL 456560](https://go.dev/cl/456560) and [456561](https://go.dev/cl/456561)) on Dec 14. This suggests that the failure is more likely to be caused by something that happened on that week rather than a particular code change. The most common error is: ``` fatal error: trace: ReadTrace got invalid frequency ``` Here are the 3 most recent build logs: - https://build.golang.org/log/fbc66b6fd21efece15fba6a5793ab39a5534a4dc - https://build.golang.org/log/f11b716d9f72e7322f25bda7b946041b90370df5 - https://build.golang.org/log/4b224c4fdd65698d08c0e5a00a42bb952310f86f @mengzhuo Do you know if there were changes to the builder or its environment around Dec 13? CC @golang/runtime, @golang/release.",1.0,"x/build: linux-amd64-wsl builder failing - The linux-amd64-wsl builder (owned by @mengzhuo) flipped abruptly from almost always passing to almost always failing on December 13, 2022: On the main branch, it happened first on [CL 457055](https://go.dev/cl/457055) on Dec 13. But it also started happening on 1.19 and 1.18 release branches on a completely unrelated change ([CL 456560](https://go.dev/cl/456560) and [456561](https://go.dev/cl/456561)) on Dec 14. This suggests that the failure is more likely to be caused by something that happened on that week rather than a particular code change. The most common error is: ``` fatal error: trace: ReadTrace got invalid frequency ``` Here are the 3 most recent build logs: - https://build.golang.org/log/fbc66b6fd21efece15fba6a5793ab39a5534a4dc - https://build.golang.org/log/f11b716d9f72e7322f25bda7b946041b90370df5 - https://build.golang.org/log/4b224c4fdd65698d08c0e5a00a42bb952310f86f @mengzhuo Do you know if there were changes to the builder or its environment around Dec 13? CC @golang/runtime, @golang/release.",0,x build linux wsl builder failing the linux wsl builder owned by mengzhuo flipped abruptly from almost always passing to almost always failing on december img width alt image src on the main branch it happened first on on dec but it also started happening on and release branches on a completely unrelated change and on dec this suggests that the failure is more likely to be caused by something that happened on that week rather than a particular code change the most common error is fatal error trace readtrace got invalid frequency here are the most recent build logs mengzhuo do you know if there were changes to the builder or its environment around dec cc golang runtime golang release ,0 85937,24727655960.0,IssuesEvent,2022-10-20 15:06:10,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/relui/sign: race in SigningServer.send,Builders NeedsFix,"`SigningServer.send` has a possibility of panicking when executing this line: https://cs.opensource.google/go/x/build/+/master:internal/relui/sign/server.go;l=110;drc=656fd833c86463e51c5e722b28134318ab25bf6a
Stack trace
``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x10357eeac] goroutine 1582 [running]: golang.org/x/build/internal/relui/sign.(*SigningServer).send(0x1400095dbc0, {0x103b881d8, 0x14000f9a0f0}, 0x14000f9a190) $HOME/go/src/golang.org/x/build/internal/relui/sign/server.go:110 +0x1dc golang.org/x/build/internal/relui/sign.(*SigningServer).SignArtifact(0x14000d9e8a8?, {0x103b881d8, 0x14000f9a0f0}, 0x1, {0x14001a7e6f0, 0x1, 0x1}) $HOME/go/src/golang.org/x/build/internal/relui/sign/server.go:115 +0x168 golang.org/x/build/internal/relui.(*BuildReleaseTasks).signArtifacts(0x140009490e0, 0x14000f9a0f0, 0x10395a040?, {0x14001a7e6f0?, 0x140008bb138?, 0x14000a060a0?}) $HOME/go/src/golang.org/x/build/internal/relui/workflows.go:829 +0x6c golang.org/x/build/internal/relui.(*BuildReleaseTasks).signDarwinPKG(_, _, {0x14000576680, {0x14000a060a0, 0x47}, {0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}) $HOME/go/src/golang.org/x/build/internal/relui/workflows.go:706 +0xbc reflect.Value.call({0x103972160?, 0x1400018d520?, 0x14000a22c18?}, {0x1035afedb, 0x4}, {0x14001088930, 0x2, 0x1033b3314?}) /usr/local/go/src/reflect/value.go:584 +0x688 reflect.Value.Call({0x103972160?, 0x1400018d520?, 0x1400018dad0?}, {0x14001088930?, 0x20?, 0x102a43144?}) /usr/local/go/src/reflect/value.go:368 +0x90 golang.org/x/build/internal/workflow.runTask({0x103b87d08?, 0x140008fe9c0?}, {0xab, 0xf9, 0xd, 0x86, 0xda, 0xf8, 0x4d, 0x53, ...}, ...) $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:834 +0x3f4 golang.org/x/build/internal/workflow.(*Workflow).Run.func2() $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:753 +0xc8 created by golang.org/x/build/internal/workflow.(*Workflow).Run $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:753 +0xa78 exit status 2 ```
If the parent context expires, that can cause `<-respCtx.Done()` to unblock before the callback sets `resp` to a non-nil value. CL incoming.",1.0,"x/build/internal/relui/sign: race in SigningServer.send - `SigningServer.send` has a possibility of panicking when executing this line: https://cs.opensource.google/go/x/build/+/master:internal/relui/sign/server.go;l=110;drc=656fd833c86463e51c5e722b28134318ab25bf6a
Stack trace
``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x10357eeac] goroutine 1582 [running]: golang.org/x/build/internal/relui/sign.(*SigningServer).send(0x1400095dbc0, {0x103b881d8, 0x14000f9a0f0}, 0x14000f9a190) $HOME/go/src/golang.org/x/build/internal/relui/sign/server.go:110 +0x1dc golang.org/x/build/internal/relui/sign.(*SigningServer).SignArtifact(0x14000d9e8a8?, {0x103b881d8, 0x14000f9a0f0}, 0x1, {0x14001a7e6f0, 0x1, 0x1}) $HOME/go/src/golang.org/x/build/internal/relui/sign/server.go:115 +0x168 golang.org/x/build/internal/relui.(*BuildReleaseTasks).signArtifacts(0x140009490e0, 0x14000f9a0f0, 0x10395a040?, {0x14001a7e6f0?, 0x140008bb138?, 0x14000a060a0?}) $HOME/go/src/golang.org/x/build/internal/relui/workflows.go:829 +0x6c golang.org/x/build/internal/relui.(*BuildReleaseTasks).signDarwinPKG(_, _, {0x14000576680, {0x14000a060a0, 0x47}, {0x0, 0x0}, {0x0, 0x0}, {0x0, ...}, ...}) $HOME/go/src/golang.org/x/build/internal/relui/workflows.go:706 +0xbc reflect.Value.call({0x103972160?, 0x1400018d520?, 0x14000a22c18?}, {0x1035afedb, 0x4}, {0x14001088930, 0x2, 0x1033b3314?}) /usr/local/go/src/reflect/value.go:584 +0x688 reflect.Value.Call({0x103972160?, 0x1400018d520?, 0x1400018dad0?}, {0x14001088930?, 0x20?, 0x102a43144?}) /usr/local/go/src/reflect/value.go:368 +0x90 golang.org/x/build/internal/workflow.runTask({0x103b87d08?, 0x140008fe9c0?}, {0xab, 0xf9, 0xd, 0x86, 0xda, 0xf8, 0x4d, 0x53, ...}, ...) $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:834 +0x3f4 golang.org/x/build/internal/workflow.(*Workflow).Run.func2() $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:753 +0xc8 created by golang.org/x/build/internal/workflow.(*Workflow).Run $HOME/go/src/golang.org/x/build/internal/workflow/workflow.go:753 +0xa78 exit status 2 ```
If the parent context expires, that can cause `<-respCtx.Done()` to unblock before the callback sets `resp` to a non-nil value. CL incoming.",0,x build internal relui sign race in signingserver send signingserver send has a possibility of panicking when executing this line stack trace panic runtime error invalid memory address or nil pointer dereference goroutine golang org x build internal relui sign signingserver send home go src golang org x build internal relui sign server go golang org x build internal relui sign signingserver signartifact home go src golang org x build internal relui sign server go golang org x build internal relui buildreleasetasks signartifacts home go src golang org x build internal relui workflows go golang org x build internal relui buildreleasetasks signdarwinpkg home go src golang org x build internal relui workflows go reflect value call usr local go src reflect value go reflect value call usr local go src reflect value go golang org x build internal workflow runtask home go src golang org x build internal workflow workflow go golang org x build internal workflow workflow run home go src golang org x build internal workflow workflow go created by golang org x build internal workflow workflow run home go src golang org x build internal workflow workflow go exit status if the parent context expires that can cause respctx done to unblock before the callback sets resp to a non nil value cl incoming ,0 433791,30350190944.0,IssuesEvent,2023-07-11 18:20:01,golang/go,https://api.github.com/repos/golang/go,closed,runtime: Race detector causes exit status 0xc0000139 on Windows 11 with 1.21rc2 running gcc 9.2.0,Documentation OS-Windows NeedsDecision release-blocker compiler/runtime," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.21rc2 windows/amd64
### Does this issue reproduce with the latest release? Reproducible with 1.21rc2 but not reproducible with 1.20.5. I'm not sure how to download 1.21rc1 to test that. ### What operating system and processor architecture are you using (`go env`)? Windows 11 Pro Version 10.0.22621 Build 22621
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\james\AppData\Local\go-build
set GOENV=C:\Users\james\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\james\go\pkg\mod
set GONOPROXY=gerrit.levenlabs.com,gitlab.com/levenlabs
set GONOSUMDB=gerrit.levenlabs.com,gitlab.com/levenlabs
set GOOS=windows
set GOPATH=C:\Users\james\go;
set GOPRIVATE=gerrit.levenlabs.com,gitlab.com/levenlabs
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.21rc2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\james\Dropbox\aftermath\backend\go-llib\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\james\AppData\Local\Temp\go-build2611928154=/tmp/go-build -gno-record-gcc-switches
I had previously installed tdm-gcc 9.2.0 which causes the error:
gcc -v Output
> gcc -v
Using built-in specs.
COLLECT_GCC=C:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-git-9.2.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --enable-large-address-aware --disable-rpath --disable-symvers --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 9.2.0 (tdm64-1)
But upon upgrading to tdm-gcc 10.3.0 the error no longer occurs:
gcc -v Output
> gcc -v
Using built-in specs.
COLLECT_GCC=C:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-git-10.3.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,jit,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --enable-libstdcxx-threads --enable-libstdcxx-time=yes --enable-mingw-wildcard --with-gnu-ld --disable-werror --enable-nls --disable-win32-registry --enable-large-address-aware --disable-rpath --disable-symvers --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=https://github.com/jmeubank/tdm-gcc/issues
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (tdm64-1)
### What did you do? Trying to run any tests with `-race` and gcc 9.2.0 ends up failing with `exit status 0xc0000139`. https://go.dev/play/p/RFjBrSPywGg ``` > go.exe test ./... -v -race exit status 0xc0000139 ``` ``` > go.exe test ./... -v === RUN TestAdd --- PASS: TestAdd (0.00s) PASS ``` But upon upgrading to gcc 10.3.0: ``` > go.exe test ./... -v -race === RUN TestAdd --- PASS: TestAdd (0.00s) PASS ``` ### What did you expect to see? I expected for the race detector not to break between versions without something in the release notes pointing out an expectation of breakage. All I noticed in the release notes for 1.21 that might be related is: > On Windows AMD64, the linker (with help from the compiler) now emits SEH unwinding data by default, which improves the integration of Go applications with Windows debuggers and other tools. But it's not obvious that this would require an upgraded gcc. It wasn't until after several hours of Googling and debugging that I ended up attempting to update gcc. ### What did you see instead? Instead I saw a bizarre exit status that led me down a deep rabbit hole on Google to try and figure out why my go tests suddenly don't work. ",1.0,"runtime: Race detector causes exit status 0xc0000139 on Windows 11 with 1.21rc2 running gcc 9.2.0 - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.21rc2 windows/amd64
### Does this issue reproduce with the latest release? Reproducible with 1.21rc2 but not reproducible with 1.20.5. I'm not sure how to download 1.21rc1 to test that. ### What operating system and processor architecture are you using (`go env`)? Windows 11 Pro Version 10.0.22621 Build 22621
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\james\AppData\Local\go-build
set GOENV=C:\Users\james\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\james\go\pkg\mod
set GONOPROXY=gerrit.levenlabs.com,gitlab.com/levenlabs
set GONOSUMDB=gerrit.levenlabs.com,gitlab.com/levenlabs
set GOOS=windows
set GOPATH=C:\Users\james\go;
set GOPRIVATE=gerrit.levenlabs.com,gitlab.com/levenlabs
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.21rc2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\james\Dropbox\aftermath\backend\go-llib\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\james\AppData\Local\Temp\go-build2611928154=/tmp/go-build -gno-record-gcc-switches
I had previously installed tdm-gcc 9.2.0 which causes the error:
gcc -v Output
> gcc -v
Using built-in specs.
COLLECT_GCC=C:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-git-9.2.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --enable-large-address-aware --disable-rpath --disable-symvers --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 9.2.0 (tdm64-1)
But upon upgrading to tdm-gcc 10.3.0 the error no longer occurs:
gcc -v Output
> gcc -v
Using built-in specs.
COLLECT_GCC=C:\TDM-GCC-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-git-10.3.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,jit,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --enable-libstdcxx-threads --enable-libstdcxx-time=yes --enable-mingw-wildcard --with-gnu-ld --disable-werror --enable-nls --disable-win32-registry --enable-large-address-aware --disable-rpath --disable-symvers --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=https://github.com/jmeubank/tdm-gcc/issues
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (tdm64-1)
### What did you do? Trying to run any tests with `-race` and gcc 9.2.0 ends up failing with `exit status 0xc0000139`. https://go.dev/play/p/RFjBrSPywGg ``` > go.exe test ./... -v -race exit status 0xc0000139 ``` ``` > go.exe test ./... -v === RUN TestAdd --- PASS: TestAdd (0.00s) PASS ``` But upon upgrading to gcc 10.3.0: ``` > go.exe test ./... -v -race === RUN TestAdd --- PASS: TestAdd (0.00s) PASS ``` ### What did you expect to see? I expected for the race detector not to break between versions without something in the release notes pointing out an expectation of breakage. All I noticed in the release notes for 1.21 that might be related is: > On Windows AMD64, the linker (with help from the compiler) now emits SEH unwinding data by default, which improves the integration of Go applications with Windows debuggers and other tools. But it's not obvious that this would require an upgraded gcc. It wasn't until after several hours of Googling and debugging that I ended up attempting to update gcc. ### What did you see instead? Instead I saw a bizarre exit status that led me down a deep rabbit hole on Google to try and figure out why my go tests suddenly don't work. ",1,runtime race detector causes exit status on windows with running gcc please answer these questions before submitting your issue thanks what version of go are you using go version go version go version windows does this issue reproduce with the latest release reproducible with but not reproducible with i m not sure how to download to test that what operating system and processor architecture are you using go env windows pro version build go env output go env set set goarch set gobin set gocache c users james appdata local go build set goenv c users james appdata roaming go env set goexe exe set goexperiment set goflags set gohostarch set gohostos windows set goinsecure set gomodcache c users james go pkg mod set gonoproxy gerrit levenlabs com gitlab com levenlabs set gonosumdb gerrit levenlabs com gitlab com levenlabs set goos windows set gopath c users james go set goprivate gerrit levenlabs com gitlab com levenlabs set goproxy set goroot c program files go set gosumdb sum golang org set gotmpdir set gotoolchain auto set gotooldir c program files go pkg tool windows set govcs set goversion set gccgo gccgo set set ar ar set cc gcc set cxx g set cgo enabled set gomod c users james dropbox aftermath backend go llib go mod set gowork set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags mthreads wl no gc sections fmessage length ffile prefix map c users james appdata local temp go tmp go build gno record gcc switches i had previously installed tdm gcc which causes the error gcc v output gcc v using built in specs collect gcc c tdm gcc bin gcc exe collect lto wrapper c tdm gcc bin libexec gcc lto wrapper exe target configured with src gcc git configure build enable targets all enable languages ada c c fortran lto objc obj c enable libgomp enable lto enable graphite enable cxx flags dwinpthread static disable build with cxx disable build with cxx enable libstdcxx debug enable threads posix enable version specific runtime libs enable fully dynamic string enable libstdcxx threads enable libstdcxx time with gnu ld disable werror disable nls disable registry enable large address aware disable rpath disable symvers prefix with local prefix with pkgversion with bugurl thread model posix gcc version but upon upgrading to tdm gcc the error no longer occurs gcc v output gcc v using built in specs collect gcc c tdm gcc bin gcc exe collect lto wrapper c tdm gcc bin libexec gcc lto wrapper exe target configured with src gcc git configure build enable targets all enable languages ada c c fortran jit lto objc obj c enable libgomp enable lto enable graphite enable cxx flags dwinpthread static disable build with cxx disable build with cxx enable libstdcxx debug enable threads posix enable version specific runtime libs enable fully dynamic string enable libstdcxx filesystem ts yes disable libstdcxx pch enable libstdcxx threads enable libstdcxx time yes enable mingw wildcard with gnu ld disable werror enable nls disable registry enable large address aware disable rpath disable symvers prefix with local prefix with pkgversion with bugurl thread model posix supported lto compression algorithms zlib zstd gcc version what did you do trying to run any tests with race and gcc ends up failing with exit status go exe test v race exit status go exe test v run testadd pass testadd pass but upon upgrading to gcc go exe test v race run testadd pass testadd pass what did you expect to see i expected for the race detector not to break between versions without something in the release notes pointing out an expectation of breakage all i noticed in the release notes for that might be related is on windows the linker with help from the compiler now emits seh unwinding data by default which improves the integration of go applications with windows debuggers and other tools but it s not obvious that this would require an upgraded gcc it wasn t until after several hours of googling and debugging that i ended up attempting to update gcc what did you see instead instead i saw a bizarre exit status that led me down a deep rabbit hole on google to try and figure out why my go tests suddenly don t work ,1 33452,15950993079.0,IssuesEvent,2021-04-15 09:18:54,golang/go,https://api.github.com/repos/golang/go,closed,strconv: implement the Ryu algorithm to speed up float64->decimal conversion,Performance,"go version devel +15f2d0e Fri May 13 01:19:05 2016 +0000 linux/amd64 ``` go func BenchmarkAppendFloatLarge1(b *testing.B) { benchmarkAppendFloat(b, 622666234635.321e-320, 'e', -1, 64) } func BenchmarkAppendFloatLarge2(b *testing.B) { benchmarkAppendFloat(b, 622666234635.3213e-320, 'e', -1, 64) } func BenchmarkAppendFloatLarge3(b *testing.B) { benchmarkAppendFloat(b, 622666234635.322e-320, 'e', -1, 64) } ``` ``` BenchmarkAppendFloatLarge1-48 5000000 276 ns/op BenchmarkAppendFloatLarge2-48 2000 89589 ns/op BenchmarkAppendFloatLarge3-48 500000 278 ns/op ``` ",True,"strconv: implement the Ryu algorithm to speed up float64->decimal conversion - go version devel +15f2d0e Fri May 13 01:19:05 2016 +0000 linux/amd64 ``` go func BenchmarkAppendFloatLarge1(b *testing.B) { benchmarkAppendFloat(b, 622666234635.321e-320, 'e', -1, 64) } func BenchmarkAppendFloatLarge2(b *testing.B) { benchmarkAppendFloat(b, 622666234635.3213e-320, 'e', -1, 64) } func BenchmarkAppendFloatLarge3(b *testing.B) { benchmarkAppendFloat(b, 622666234635.322e-320, 'e', -1, 64) } ``` ``` BenchmarkAppendFloatLarge1-48 5000000 276 ns/op BenchmarkAppendFloatLarge2-48 2000 89589 ns/op BenchmarkAppendFloatLarge3-48 500000 278 ns/op ``` ",0,strconv implement the ryu algorithm to speed up decimal conversion go version devel fri may linux go func b testing b benchmarkappendfloat b e func b testing b benchmarkappendfloat b e func b testing b benchmarkappendfloat b e ns op ns op ns op ,0 63938,15761586636.0,IssuesEvent,2021-03-31 10:08:23,golang/go,https://api.github.com/repos/golang/go,opened,x/build: dragonfly-amd64 builder missing,Builders OS-Dragonfly,"SlowBot runs for dragonfly were/are stuck on several CLs, e.g. https://golang.org/cl/304870, https://golang.org/cl/305230 or https://golang.org/cl/304369 (I re-triggered the latter to run on the dragonfly-amd64-5_8 builder which seems to be up). On https://farmer.golang.org I see: ``` * host-dragonfly-amd64-master: 252 waiting (oldest 203h26m13s, newest 112h33m44s, progress 171h4m40s) * try: 1 (oldest 112h33m44s, newest 112h33m44s) ``` and ``` host-dragonfly-amd64-master: 0/0 (1 missing) ``` Related? #44584 #45215 /cc @golang/release @bcmills @dmitshur @tuxillo ",1.0,"x/build: dragonfly-amd64 builder missing - SlowBot runs for dragonfly were/are stuck on several CLs, e.g. https://golang.org/cl/304870, https://golang.org/cl/305230 or https://golang.org/cl/304369 (I re-triggered the latter to run on the dragonfly-amd64-5_8 builder which seems to be up). On https://farmer.golang.org I see: ``` * host-dragonfly-amd64-master: 252 waiting (oldest 203h26m13s, newest 112h33m44s, progress 171h4m40s) * try: 1 (oldest 112h33m44s, newest 112h33m44s) ``` and ``` host-dragonfly-amd64-master: 0/0 (1 missing) ``` Related? #44584 #45215 /cc @golang/release @bcmills @dmitshur @tuxillo ",0,x build dragonfly builder missing slowbot runs for dragonfly were are stuck on several cls e g or i re triggered the latter to run on the dragonfly builder which seems to be up on i see host dragonfly master waiting oldest newest progress try oldest newest and host dragonfly master missing related cc golang release bcmills dmitshur tuxillo ,0 39036,6717980047.0,IssuesEvent,2017-10-15 06:04:20,golang/go,https://api.github.com/repos/golang/go,closed,fmt: documentation on Printf * modifier is misleading,Documentation,"### What version of Go are you using (`go version`)? `go version go1.9 darwin/amd64` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/dpinela/dev/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/41/2xpv_r1j5n5bnflwb7s1hv580000gp/T/go-build477584587=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` ### What did you do? Run this program: https://play.golang.org/p/uBOhH86MEv ### What did you expect to see? The program prints: ``` $%!(BADWIDTH)%!g(int=8) $00001.68 ``` ### What did you see instead? It prints the following instead: ``` $00001.68 $%!(BADWIDTH)%!g(int=8) ``` --- The documentation says this about the behaviour of the `*` modifier (emphasis mine): > Width and precision are measured in units of Unicode code points, that is, runes. (This differs from C's printf where the units are always measured in bytes.) Either or both of the flags may be replaced with the character '*', causing their values to be obtained from the **next** operand, which must be of type int. I was therefore expecting that `Printf` would get the width from the argument following the one to be formatted, rather than the preceding one. I think the wording could be clarified, such as by specifying ""causing their values to be obtained from the next operand, _before obtaining the value to be formatted_"", and/or by adding an example.",1.0,"fmt: documentation on Printf * modifier is misleading - ### What version of Go are you using (`go version`)? `go version go1.9 darwin/amd64` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/dpinela/dev/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.9/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.9/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/41/2xpv_r1j5n5bnflwb7s1hv580000gp/T/go-build477584587=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ``` ### What did you do? Run this program: https://play.golang.org/p/uBOhH86MEv ### What did you expect to see? The program prints: ``` $%!(BADWIDTH)%!g(int=8) $00001.68 ``` ### What did you see instead? It prints the following instead: ``` $00001.68 $%!(BADWIDTH)%!g(int=8) ``` --- The documentation says this about the behaviour of the `*` modifier (emphasis mine): > Width and precision are measured in units of Unicode code points, that is, runes. (This differs from C's printf where the units are always measured in bytes.) Either or both of the flags may be replaced with the character '*', causing their values to be obtained from the **next** operand, which must be of type int. I was therefore expecting that `Printf` would get the width from the argument following the one to be formatted, rather than the preceding one. I think the wording could be clarified, such as by specifying ""causing their values to be obtained from the next operand, _before obtaining the value to be formatted_"", and/or by adding an example.",1,fmt documentation on printf modifier is misleading what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users dpinela dev go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config what did you do run this program what did you expect to see the program prints badwidth g int what did you see instead it prints the following instead badwidth g int the documentation says this about the behaviour of the modifier emphasis mine width and precision are measured in units of unicode code points that is runes this differs from c s printf where the units are always measured in bytes either or both of the flags may be replaced with the character causing their values to be obtained from the next operand which must be of type int i was therefore expecting that printf would get the width from the argument following the one to be formatted rather than the preceding one i think the wording could be clarified such as by specifying causing their values to be obtained from the next operand before obtaining the value to be formatted and or by adding an example ,1 150190,13325334725.0,IssuesEvent,2020-08-27 09:48:27,golang/go,https://api.github.com/repos/golang/go,closed,doc: include fix for #34437 in Go 1.14 release notes,Documentation NeedsFix help wanted,"Hello, I wanted to reach out and see whether there is an interest in the fix for #34437 being included in the Go release notes. Someone I know was finally working through upgrading to Go 1.14 and ran in to some peculiar issues with their JSON being unmarshaled differently. Here is that commit on our side: - https://github.com/golang/go/commit/fb9af8411eaa3e38d2f72e28a305772f50042657#diff-4299c3082a8bb7e546723132c992fa4c It took them some time to figure it out, while it having been mentioned in the release notes could have saved them some time (as they looked there first). I understand we can't document all fixes without the release notes becoming silly, but wondered whether that change may meet the bar of inclusion. Cheers!",1.0,"doc: include fix for #34437 in Go 1.14 release notes - Hello, I wanted to reach out and see whether there is an interest in the fix for #34437 being included in the Go release notes. Someone I know was finally working through upgrading to Go 1.14 and ran in to some peculiar issues with their JSON being unmarshaled differently. Here is that commit on our side: - https://github.com/golang/go/commit/fb9af8411eaa3e38d2f72e28a305772f50042657#diff-4299c3082a8bb7e546723132c992fa4c It took them some time to figure it out, while it having been mentioned in the release notes could have saved them some time (as they looked there first). I understand we can't document all fixes without the release notes becoming silly, but wondered whether that change may meet the bar of inclusion. Cheers!",1,doc include fix for in go release notes hello i wanted to reach out and see whether there is an interest in the fix for being included in the go release notes someone i know was finally working through upgrading to go and ran in to some peculiar issues with their json being unmarshaled differently here is that commit on our side it took them some time to figure it out while it having been mentioned in the release notes could have saved them some time as they looked there first i understand we can t document all fixes without the release notes becoming silly but wondered whether that change may meet the bar of inclusion cheers ,1 302376,22820498182.0,IssuesEvent,2022-07-12 01:27:14,golang/go,https://api.github.com/repos/golang/go,closed,design: add metadata to all design documents ,Documentation help wanted WaitingForInfo,"Today a gopher on Telegram reported a problem when trying to install `staticcheck` with go1.16. Here is the error: ```sh go1.16.12 install honnef.co/go/tools/cmd/staticcheck@latest ``` ``` .local/lib/go/pkg/mod/honnef.co/go/tools@v0.3.0/go/ir/builder.go:36:2: //go:build comment without // +build comment ``` I remembered that there was a transition period, so I checked the original proposal https://go.dev/design/draft-gobuild. Here is a list of problems: 1. The document is **still** marked as a draft 2. In the transition section, the text uses `Go 1.(N−1)`, `Go 1.N` and so on. This is, IMHO, not very easy to follow. I suggest to add metadata (like Python PEP) to **all** design documents, so that a reader can easily identify - If the design has been accepted - If the design has been implemented - In what Go version the design has been implemented Thanks.",1.0,"design: add metadata to all design documents - Today a gopher on Telegram reported a problem when trying to install `staticcheck` with go1.16. Here is the error: ```sh go1.16.12 install honnef.co/go/tools/cmd/staticcheck@latest ``` ``` .local/lib/go/pkg/mod/honnef.co/go/tools@v0.3.0/go/ir/builder.go:36:2: //go:build comment without // +build comment ``` I remembered that there was a transition period, so I checked the original proposal https://go.dev/design/draft-gobuild. Here is a list of problems: 1. The document is **still** marked as a draft 2. In the transition section, the text uses `Go 1.(N−1)`, `Go 1.N` and so on. This is, IMHO, not very easy to follow. I suggest to add metadata (like Python PEP) to **all** design documents, so that a reader can easily identify - If the design has been accepted - If the design has been implemented - In what Go version the design has been implemented Thanks.",1,design add metadata to all design documents today a gopher on telegram reported a problem when trying to install staticcheck with here is the error sh install honnef co go tools cmd staticcheck latest local lib go pkg mod honnef co go tools go ir builder go go build comment without build comment i remembered that there was a transition period so i checked the original proposal here is a list of problems the document is still marked as a draft in the transition section the text uses go n− go n and so on this is imho not very easy to follow i suggest to add metadata like python pep to all design documents so that a reader can easily identify if the design has been accepted if the design has been implemented in what go version the design has been implemented thanks ,1 102029,16543841541.0,IssuesEvent,2021-05-27 20:37:06,golang/go,https://api.github.com/repos/golang/go,closed,net: Lookup functions may return invalid host names [1.15 backport],CherryPickApproved Security release-blocker,"@rolandshoemaker requested issue #46241 to be considered for backport to the next 1.15 minor release. > @gopherbot please consider this for backport to 1.15 and 1.16 as this is a security issue. ",True,"net: Lookup functions may return invalid host names [1.15 backport] - @rolandshoemaker requested issue #46241 to be considered for backport to the next 1.15 minor release. > @gopherbot please consider this for backport to 1.15 and 1.16 as this is a security issue. ",0,net lookup functions may return invalid host names rolandshoemaker requested issue to be considered for backport to the next minor release gopherbot please consider this for backport to and as this is a security issue ,0 110434,11700810250.0,IssuesEvent,2020-03-06 18:17:46,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: gopls ignores the fact that the client doesn't support hierarchicalDocumentSymbolSupport,Documentation NeedsFix Tools gopls help wanted," ### What version of Go are you using (`go version`)? 
$ go version

go version go1.13.1 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/edkolev/Library/Caches/go-build""
GOENV=""/Users/edkolev/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/edkolev/gocode""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.13.1/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.13.1/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/v7/fnkk7zpd0hvdsl45hpj92cc40000gn/T/go-build203896190=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? 1. Start emacs, install `eglot` LSP client 2. Open a main.go with contents ``` package main func main() { print(""hello"") } ``` 3. Run `M-x eglot`. At this point eglot notifies gopls for its capabilities as a client. Note that it doesn't report `hierarchicalDocumentSymbolSupport` as supported. ``` :capabilities (:workspace (:applyEdit t :executeCommand (:dynamicRegistration :json-false) :workspaceEdit (:documentChanges :json-false) :didChangeWatchedFiles (:dynamicRegistration t) :symbol (:dynamicRegistration :json-false)) :textDocument (:synchronization (:dynamicRegistration :json-false :willSave t :willSaveWaitUntil t :didSave t) :completion (:dynamicRegistration :json-false :completionItem (:snippetSupport t) :contextSupport t) :hover (:dynamicRegistration :json-false) :signatureHelp (:dynamicRegistration :json-false :signatureInformation (:parameterInformation (:labelOffsetSupport t))) :references (:dynamicRegistration :json-false) :definition (:dynamicRegistration :json-false) :documentSymbol (:dynamicRegistration :json-false :symbolKind (:valueSet [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26])) :documentHighlight (:dynamicRegistration :json-false) :codeAction (:dynamicRegistration :json-false :codeActionLiteralSupport (:codeActionKind (:valueSet [""quickfix"" ""refactor"" ""refactor.extract"" ""refactor.inline"" ""refactor.rewrite"" ""source"" ""source.organizeImports""]))) :formatting (:dynamicRegistration :json-false) :rangeFormatting (:dynamicRegistration :json-false) :rename (:dynamicRegistration :json-false) :publishDiagnostics (:relatedInformation :json-false)) :experimental nil) ``` 4. Run `M-x imenu` which causes the following communication, note that gopls replies with a hierarchical document symbol response. ``` client-request (id:4) Sat Oct 12 11:59:33 2019: (:jsonrpc ""2.0"" :id 4 :method ""textDocument/documentSymbol"" :params (:textDocument (:uri ""file:///Users/edkolev/dev/go-play/main.go""))) server-reply (id:4) Sat Oct 12 11:59:33 2019: (:jsonrpc ""2.0"" :result [(:name ""main"" :detail ""()"" :kind 12 :range (:start (:line 2 :character 0) :end (:line 4 :character 1)) :selectionRange (:start (:line 2 :character 5) :end (:line 2 :character 9)))] :id 4) ``` 5. Emacs shows an error ### What did you expect to see? The list of symbols in the main.go file, i.e. the `main()` function. ### What did you see instead? Emacs error. ## Notes - this issue has been reported in eglot here https://github.com/joaotavora/eglot/issues/317 - there's an open PR in eglot to add support for hierarchical response to `textDocument/documentSymbol` https://github.com/joaotavora/eglot/pull/303 ",1.0,"x/tools/gopls: gopls ignores the fact that the client doesn't support hierarchicalDocumentSymbolSupport - ### What version of Go are you using (`go version`)? 
$ go version

go version go1.13.1 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/edkolev/Library/Caches/go-build""
GOENV=""/Users/edkolev/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/edkolev/gocode""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.13.1/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.13.1/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""""
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/v7/fnkk7zpd0hvdsl45hpj92cc40000gn/T/go-build203896190=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? 1. Start emacs, install `eglot` LSP client 2. Open a main.go with contents ``` package main func main() { print(""hello"") } ``` 3. Run `M-x eglot`. At this point eglot notifies gopls for its capabilities as a client. Note that it doesn't report `hierarchicalDocumentSymbolSupport` as supported. ``` :capabilities (:workspace (:applyEdit t :executeCommand (:dynamicRegistration :json-false) :workspaceEdit (:documentChanges :json-false) :didChangeWatchedFiles (:dynamicRegistration t) :symbol (:dynamicRegistration :json-false)) :textDocument (:synchronization (:dynamicRegistration :json-false :willSave t :willSaveWaitUntil t :didSave t) :completion (:dynamicRegistration :json-false :completionItem (:snippetSupport t) :contextSupport t) :hover (:dynamicRegistration :json-false) :signatureHelp (:dynamicRegistration :json-false :signatureInformation (:parameterInformation (:labelOffsetSupport t))) :references (:dynamicRegistration :json-false) :definition (:dynamicRegistration :json-false) :documentSymbol (:dynamicRegistration :json-false :symbolKind (:valueSet [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26])) :documentHighlight (:dynamicRegistration :json-false) :codeAction (:dynamicRegistration :json-false :codeActionLiteralSupport (:codeActionKind (:valueSet [""quickfix"" ""refactor"" ""refactor.extract"" ""refactor.inline"" ""refactor.rewrite"" ""source"" ""source.organizeImports""]))) :formatting (:dynamicRegistration :json-false) :rangeFormatting (:dynamicRegistration :json-false) :rename (:dynamicRegistration :json-false) :publishDiagnostics (:relatedInformation :json-false)) :experimental nil) ``` 4. Run `M-x imenu` which causes the following communication, note that gopls replies with a hierarchical document symbol response. ``` client-request (id:4) Sat Oct 12 11:59:33 2019: (:jsonrpc ""2.0"" :id 4 :method ""textDocument/documentSymbol"" :params (:textDocument (:uri ""file:///Users/edkolev/dev/go-play/main.go""))) server-reply (id:4) Sat Oct 12 11:59:33 2019: (:jsonrpc ""2.0"" :result [(:name ""main"" :detail ""()"" :kind 12 :range (:start (:line 2 :character 0) :end (:line 4 :character 1)) :selectionRange (:start (:line 2 :character 5) :end (:line 2 :character 9)))] :id 4) ``` 5. Emacs shows an error ### What did you expect to see? The list of symbols in the main.go file, i.e. the `main()` function. ### What did you see instead? Emacs error. ## Notes - this issue has been reported in eglot here https://github.com/joaotavora/eglot/issues/317 - there's an open PR in eglot to add support for hierarchical response to `textDocument/documentSymbol` https://github.com/joaotavora/eglot/pull/303 ",1,x tools gopls gopls ignores the fact that the client doesn t support hierarchicaldocumentsymbolsupport what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users edkolev library caches go build goenv users edkolev library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users edkolev gocode goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do start emacs install eglot lsp client open a main go with contents package main func main print hello run m x eglot at this point eglot notifies gopls for its capabilities as a client note that it doesn t report hierarchicaldocumentsymbolsupport as supported capabilities workspace applyedit t executecommand dynamicregistration json false workspaceedit documentchanges json false didchangewatchedfiles dynamicregistration t symbol dynamicregistration json false textdocument synchronization dynamicregistration json false willsave t willsavewaituntil t didsave t completion dynamicregistration json false completionitem snippetsupport t contextsupport t hover dynamicregistration json false signaturehelp dynamicregistration json false signatureinformation parameterinformation labeloffsetsupport t references dynamicregistration json false definition dynamicregistration json false documentsymbol dynamicregistration json false symbolkind valueset documenthighlight dynamicregistration json false codeaction dynamicregistration json false codeactionliteralsupport codeactionkind valueset formatting dynamicregistration json false rangeformatting dynamicregistration json false rename dynamicregistration json false publishdiagnostics relatedinformation json false experimental nil run m x imenu which causes the following communication note that gopls replies with a hierarchical document symbol response client request id sat oct jsonrpc id method textdocument documentsymbol params textdocument uri file users edkolev dev go play main go server reply id sat oct jsonrpc result name main detail kind range start line character end line character selectionrange start line character end line character id emacs shows an error what did you expect to see the list of symbols in the main go file i e the main function what did you see instead emacs error notes this issue has been reported in eglot here there s an open pr in eglot to add support for hierarchical response to textdocument documentsymbol ,1 73978,9742421800.0,IssuesEvent,2019-06-02 16:58:30,golang/go,https://api.github.com/repos/golang/go,closed,wiki: transfer label descriptions from wiki to labels themselves,Documentation,"Now that GitHub has [added descriptions to labels](https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more), it would probably be helpful to transfer the label descriptions from https://github.com/golang/go/wiki/IssueLabels to the labels themselves. I think it would make it easier for more people to discover what the labels mean. If we do this, I think the wiki page should be removed (maybe not right away, and also having made a backup), to avoid having to maintain same information in two places. This issue is to consider/discuss this opportunity.",1.0,"wiki: transfer label descriptions from wiki to labels themselves - Now that GitHub has [added descriptions to labels](https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more), it would probably be helpful to transfer the label descriptions from https://github.com/golang/go/wiki/IssueLabels to the labels themselves. I think it would make it easier for more people to discover what the labels mean. If we do this, I think the wiki page should be removed (maybe not right away, and also having made a backup), to avoid having to maintain same information in two places. This issue is to consider/discuss this opportunity.",1,wiki transfer label descriptions from wiki to labels themselves now that github has it would probably be helpful to transfer the label descriptions from to the labels themselves i think it would make it easier for more people to discover what the labels mean if we do this i think the wiki page should be removed maybe not right away and also having made a backup to avoid having to maintain same information in two places this issue is to consider discuss this opportunity ,1 30096,8476246536.0,IssuesEvent,2018-10-24 21:18:22,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/tip: migrate beta.golang.org to tip GKE service,Builders,"beta.golang.org runs on a GCE VM in a somewhat ad-hoc config. Now that tip.golang.org on GKE is stable (I think?), let's nuke the weird VM and just make tip.golang.org and beta.golang.org have the same IP and be served by the same place. The difference between betas and tip is always tiny anyway, and there's basically never a case where we want beta.golang.org to serve something older than tip. If anything, it's been tedious logging into beta.golang.org regularly during the beta/rc cycle and running ""git pull"" and restarting systemd services when needed. /cc @FiloSottile @bcmills ",1.0,"x/tools/cmd/tip: migrate beta.golang.org to tip GKE service - beta.golang.org runs on a GCE VM in a somewhat ad-hoc config. Now that tip.golang.org on GKE is stable (I think?), let's nuke the weird VM and just make tip.golang.org and beta.golang.org have the same IP and be served by the same place. The difference between betas and tip is always tiny anyway, and there's basically never a case where we want beta.golang.org to serve something older than tip. If anything, it's been tedious logging into beta.golang.org regularly during the beta/rc cycle and running ""git pull"" and restarting systemd services when needed. /cc @FiloSottile @bcmills ",0,x tools cmd tip migrate beta golang org to tip gke service beta golang org runs on a gce vm in a somewhat ad hoc config now that tip golang org on gke is stable i think let s nuke the weird vm and just make tip golang org and beta golang org have the same ip and be served by the same place the difference between betas and tip is always tiny anyway and there s basically never a case where we want beta golang org to serve something older than tip if anything it s been tedious logging into beta golang org regularly during the beta rc cycle and running git pull and restarting systemd services when needed cc filosottile bcmills ,0 13564,3739391460.0,IssuesEvent,2016-03-09 04:24:47,golang/go,https://api.github.com/repos/golang/go,closed,x/net/websocket: Document goroutine safety of websocket.Conn,Documentation HelpWanted,"
The documentation of websocket.Conn[1] does not state that it is safe to share it among
multiple goroutines. From the implementation (rio and wio mutexes), it appears that it
is safe.

It'll be convenient if this is explicitly stated like in the case of net.Conn in
stdlib[2].

[1] - http://godoc.org/code.google.com/p/go.net/websocket#Conn
",1.0,"x/net/websocket: Document goroutine safety of websocket.Conn - 
The documentation of websocket.Conn[1] does not state that it is safe to share it among
multiple goroutines. From the implementation (rio and wio mutexes), it appears that it
is safe.

It'll be convenient if this is explicitly stated like in the case of net.Conn in
stdlib[2].

[1] - http://godoc.org/code.google.com/p/go.net/websocket#Conn
",1,x net websocket document goroutine safety of websocket conn the documentation of websocket conn does not state that it is safe to share it among multiple goroutines from the implementation rio and wio mutexes it appears that it is safe it ll be convenient if this is explicitly stated like in the case of net conn in stdlib a href ,1 123286,12196303654.0,IssuesEvent,2020-04-29 18:51:02,golang/go,https://api.github.com/repos/golang/go,closed,crypto/x509/pkix: FillFromRDNSequence does not preserve multi-value RDNs,Documentation NeedsFix Unfortunate help wanted,"### What version of Go are you using (`go version`)? This issue affects Go 1.8 and later as a consequence of https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231 to fix [#16836](https://github.com/golang/go/issues/16836) (and #12342). Prior to Go 1.8 and that change, Go did not process multi-value RDNs -- it always assumed just one attribute and value (the first) per RDN. ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? The OS and architecture should not matter. ### What did you do? https://play.golang.org/p/7OIuhautCe ### What did you expect to see? The multi-value nature of any RDN is preserved. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence should match. ### What did you see instead? The multi-value nature of any RDN is not preserved by pkix.FillFromRDNSequence. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence do not match. As previously noted in comments on https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231, the [original Gerrit CR](https://go-review.googlesource.com/c/go/+/30810#message-a29d12cfb3550dc2ce212ec60ddf32bf86363f13), and #12342, if this will not be fixed, then the behavior should be documented at a minimum.",1.0,"crypto/x509/pkix: FillFromRDNSequence does not preserve multi-value RDNs - ### What version of Go are you using (`go version`)? This issue affects Go 1.8 and later as a consequence of https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231 to fix [#16836](https://github.com/golang/go/issues/16836) (and #12342). Prior to Go 1.8 and that change, Go did not process multi-value RDNs -- it always assumed just one attribute and value (the first) per RDN. ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? The OS and architecture should not matter. ### What did you do? https://play.golang.org/p/7OIuhautCe ### What did you expect to see? The multi-value nature of any RDN is preserved. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence should match. ### What did you see instead? The multi-value nature of any RDN is not preserved by pkix.FillFromRDNSequence. That is, the length of the subject (and issuer) RDNSequence before pkix.FillFromRDNSequence and after pkix.ToRDNSequence do not match. As previously noted in comments on https://github.com/golang/go/commit/809a1de1ac1ccc76f7a4faf630017626f2f68231, the [original Gerrit CR](https://go-review.googlesource.com/c/go/+/30810#message-a29d12cfb3550dc2ce212ec60ddf32bf86363f13), and #12342, if this will not be fixed, then the behavior should be documented at a minimum.",1,crypto pkix fillfromrdnsequence does not preserve multi value rdns what version of go are you using go version this issue affects go and later as a consequence of to fix and prior to go and that change go did not process multi value rdns it always assumed just one attribute and value the first per rdn does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env the os and architecture should not matter what did you do what did you expect to see the multi value nature of any rdn is preserved that is the length of the subject and issuer rdnsequence before pkix fillfromrdnsequence and after pkix tordnsequence should match what did you see instead the multi value nature of any rdn is not preserved by pkix fillfromrdnsequence that is the length of the subject and issuer rdnsequence before pkix fillfromrdnsequence and after pkix tordnsequence do not match as previously noted in comments on the and if this will not be fixed then the behavior should be documented at a minimum ,1 26062,7780822567.0,IssuesEvent,2018-06-05 21:19:24,golang/go,https://api.github.com/repos/golang/go,closed,x/build/maintner: refactor out gcs and api from maintnerd,Builders,"I want to create a customized maintnerd (one feature is being able to add tracked repos while the daemon is running). Here's a small proposal to make that more possible: * move all of the GCS (gcslog.go) and API functions (api.go) to a new package: ""maintnerapi"". optional: move GCS functionality into its own package. * ~~move the protos into a subpackage (currently named ""apipb"" but maybe ""maintpb"" is better?)~~ nevermind, there's already a maintpb for storage. maintnerd then becomes a 500 line program that uses the maintnerapi package, which looks like this: ``` PACKAGE DOCUMENTATION package maintnerapi import ""."" FUNCTIONS func NewAPIService(corpus *maintner.Corpus) apipb.MaintnerServiceServer TYPES type GCSLog struct { // contains filtered or unexported fields } func NewGCSLog(ctx context.Context, bucketName string) (*GCSLog, error) func (gl *GCSLog) CopyFrom(src maintner.MutationSource) error CopyFrom is only used for the one-time migrate from disk-to-GCS code path. func (gl *GCSLog) GetMutations(ctx context.Context) <-chan maintner.MutationStreamEvent func (gl *GCSLog) Log(m *maintpb.Mutation) error func (gl *GCSLog) ServeJSONLogsIndex(w http.ResponseWriter, r *http.Request) func (gl *GCSLog) ServeLogFile(w http.ResponseWriter, r *http.Request) ```",1.0,"x/build/maintner: refactor out gcs and api from maintnerd - I want to create a customized maintnerd (one feature is being able to add tracked repos while the daemon is running). Here's a small proposal to make that more possible: * move all of the GCS (gcslog.go) and API functions (api.go) to a new package: ""maintnerapi"". optional: move GCS functionality into its own package. * ~~move the protos into a subpackage (currently named ""apipb"" but maybe ""maintpb"" is better?)~~ nevermind, there's already a maintpb for storage. maintnerd then becomes a 500 line program that uses the maintnerapi package, which looks like this: ``` PACKAGE DOCUMENTATION package maintnerapi import ""."" FUNCTIONS func NewAPIService(corpus *maintner.Corpus) apipb.MaintnerServiceServer TYPES type GCSLog struct { // contains filtered or unexported fields } func NewGCSLog(ctx context.Context, bucketName string) (*GCSLog, error) func (gl *GCSLog) CopyFrom(src maintner.MutationSource) error CopyFrom is only used for the one-time migrate from disk-to-GCS code path. func (gl *GCSLog) GetMutations(ctx context.Context) <-chan maintner.MutationStreamEvent func (gl *GCSLog) Log(m *maintpb.Mutation) error func (gl *GCSLog) ServeJSONLogsIndex(w http.ResponseWriter, r *http.Request) func (gl *GCSLog) ServeLogFile(w http.ResponseWriter, r *http.Request) ```",0,x build maintner refactor out gcs and api from maintnerd i want to create a customized maintnerd one feature is being able to add tracked repos while the daemon is running here s a small proposal to make that more possible move all of the gcs gcslog go and api functions api go to a new package maintnerapi optional move gcs functionality into its own package move the protos into a subpackage currently named apipb but maybe maintpb is better nevermind there s already a maintpb for storage maintnerd then becomes a line program that uses the maintnerapi package which looks like this package documentation package maintnerapi import functions func newapiservice corpus maintner corpus apipb maintnerserviceserver types type gcslog struct contains filtered or unexported fields func newgcslog ctx context context bucketname string gcslog error func gl gcslog copyfrom src maintner mutationsource error copyfrom is only used for the one time migrate from disk to gcs code path func gl gcslog getmutations ctx context context chan maintner mutationstreamevent func gl gcslog log m maintpb mutation error func gl gcslog servejsonlogsindex w http responsewriter r http request func gl gcslog servelogfile w http responsewriter r http request ,0 82651,10302240572.0,IssuesEvent,2019-08-28 16:20:35,golang/go,https://api.github.com/repos/golang/go,closed,math/big: Rat.Denom has side effects,Documentation NeedsInvestigation,"From here: https://github.com/ericlagergren/decimal/issues/138 My package divides `(*Rat).Num` by `(*Rat).Denom` to produce a decimal number. It turns out that `(*Rat).Denom` lazily sets its denominator, meaning it cannot be used concurrently. Since the receiver is `x` not `z`, I assumed that the method simply read the denominator. The receiver name should be updated to indicate side effects and/or the documentation for `big.Rat` should mention this side effect. I assume that the 7 years this has spent in the tree is too long to be reverted 😄. And, at any rate, not materializing the denominator can save allocations for whole numbers, which is a good thing. I can send a CL if you want.",1.0,"math/big: Rat.Denom has side effects - From here: https://github.com/ericlagergren/decimal/issues/138 My package divides `(*Rat).Num` by `(*Rat).Denom` to produce a decimal number. It turns out that `(*Rat).Denom` lazily sets its denominator, meaning it cannot be used concurrently. Since the receiver is `x` not `z`, I assumed that the method simply read the denominator. The receiver name should be updated to indicate side effects and/or the documentation for `big.Rat` should mention this side effect. I assume that the 7 years this has spent in the tree is too long to be reverted 😄. And, at any rate, not materializing the denominator can save allocations for whole numbers, which is a good thing. I can send a CL if you want.",1,math big rat denom has side effects from here my package divides rat num by rat denom to produce a decimal number it turns out that rat denom lazily sets its denominator meaning it cannot be used concurrently since the receiver is x not z i assumed that the method simply read the denominator the receiver name should be updated to indicate side effects and or the documentation for big rat should mention this side effect i assume that the years this has spent in the tree is too long to be reverted 😄 and at any rate not materializing the denominator can save allocations for whole numbers which is a good thing i can send a cl if you want ,1 313224,26910885415.0,IssuesEvent,2023-02-06 23:35:34,golang/go,https://api.github.com/repos/golang/go,reopened,net/http: TestIssue4191_InfiniteGetTimeout failures,Testing NeedsFix,"``` #!watchflakes post <- pkg == ""net/http"" && test == ""TestIssue4191_InfiniteGetTimeout"" ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/86eafcf43d85a75041c3d91b3f4f67a81290a67e)): 2022/10/14 13:21:56 http: TLS handshake error from 127.0.0.1:34378: EOF 2022/10/14 13:21:56 http: TLS handshake error from 127.0.0.1:58818: EOF 2022/10/14 13:22:06 http: TLS handshake error from 127.0.0.1:46802: EOF 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:37914: write tcp 127.0.0.1:33957->127.0.0.1:37914: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55294: read tcp 127.0.0.1:32777->127.0.0.1:55294: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55306: read tcp 127.0.0.1:32777->127.0.0.1:55306: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55308: read tcp 127.0.0.1:32777->127.0.0.1:55308: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55290: read tcp 127.0.0.1:32777->127.0.0.1:55290: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55292: read tcp 127.0.0.1:32777->127.0.0.1:55292: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55300: write tcp 127.0.0.1:32777->127.0.0.1:55300: use of closed network connection ... --- FAIL: TestIssue4191_InfiniteGetTimeout (0.00s) --- FAIL: TestIssue4191_InfiniteGetTimeout/h2 (1.72s) transport_test.go:2167: increasing timeout transport_test.go:2172: Error issuing GET: Get ""https://127.0.0.1:33957/get"": read tcp 127.0.0.1:37936->127.0.0.1:33957: i/o timeout 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43514: read tcp 127.0.0.1:32901->127.0.0.1:43514: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43516: read tcp 127.0.0.1:32901->127.0.0.1:43516: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43520: read tcp 127.0.0.1:32901->127.0.0.1:43520: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43528: read tcp 127.0.0.1:32901->127.0.0.1:43528: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43522: write tcp 127.0.0.1:32901->127.0.0.1:43522: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43512: write tcp 127.0.0.1:32901->127.0.0.1:43512: use of closed network connection ... 2022/10/14 13:22:39 http: TLS handshake error from 127.0.0.1:54936: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55624: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55618: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55620: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54942: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54946: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54948: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55630: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55634: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54952: EOF — [watchflakes](https://go.dev/wiki/Watchflakes) ",1.0,"net/http: TestIssue4191_InfiniteGetTimeout failures - ``` #!watchflakes post <- pkg == ""net/http"" && test == ""TestIssue4191_InfiniteGetTimeout"" ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/86eafcf43d85a75041c3d91b3f4f67a81290a67e)): 2022/10/14 13:21:56 http: TLS handshake error from 127.0.0.1:34378: EOF 2022/10/14 13:21:56 http: TLS handshake error from 127.0.0.1:58818: EOF 2022/10/14 13:22:06 http: TLS handshake error from 127.0.0.1:46802: EOF 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:37914: write tcp 127.0.0.1:33957->127.0.0.1:37914: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55294: read tcp 127.0.0.1:32777->127.0.0.1:55294: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55306: read tcp 127.0.0.1:32777->127.0.0.1:55306: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55308: read tcp 127.0.0.1:32777->127.0.0.1:55308: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55290: read tcp 127.0.0.1:32777->127.0.0.1:55290: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55292: read tcp 127.0.0.1:32777->127.0.0.1:55292: use of closed network connection 2022/10/14 13:22:08 http: TLS handshake error from 127.0.0.1:55300: write tcp 127.0.0.1:32777->127.0.0.1:55300: use of closed network connection ... --- FAIL: TestIssue4191_InfiniteGetTimeout (0.00s) --- FAIL: TestIssue4191_InfiniteGetTimeout/h2 (1.72s) transport_test.go:2167: increasing timeout transport_test.go:2172: Error issuing GET: Get ""https://127.0.0.1:33957/get"": read tcp 127.0.0.1:37936->127.0.0.1:33957: i/o timeout 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43514: read tcp 127.0.0.1:32901->127.0.0.1:43514: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43516: read tcp 127.0.0.1:32901->127.0.0.1:43516: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43520: read tcp 127.0.0.1:32901->127.0.0.1:43520: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43528: read tcp 127.0.0.1:32901->127.0.0.1:43528: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43522: write tcp 127.0.0.1:32901->127.0.0.1:43522: use of closed network connection 2022/10/14 13:22:10 http: TLS handshake error from 127.0.0.1:43512: write tcp 127.0.0.1:32901->127.0.0.1:43512: use of closed network connection ... 2022/10/14 13:22:39 http: TLS handshake error from 127.0.0.1:54936: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55624: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55618: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55620: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54942: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54946: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54948: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55630: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:55634: EOF 2022/10/14 13:22:40 http: TLS handshake error from 127.0.0.1:54952: EOF — [watchflakes](https://go.dev/wiki/Watchflakes) ",0,net http infinitegettimeout failures watchflakes post pkg net http test infinitegettimeout issue created automatically to collect these failures example http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from write tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection fail infinitegettimeout fail infinitegettimeout transport test go increasing timeout transport test go error issuing get get read tcp i o timeout http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof — ,0 232842,17796845621.0,IssuesEvent,2021-08-31 23:55:58,golang/go,https://api.github.com/repos/golang/go,opened,spec: clarify sequencing of function calls within expressions,Documentation NeedsDecision,"The program below tests the order-of-evaluation semantics of `return *p, f(p)`. With gccgo, it prints 0 (i.e., evaluating `*p` before calling `f(p)`), and with cmd/compile it prints 2 (i.e., evaluating `*p` after `f(p)` returns). But is it allowed to print `1`? I.e., can `*p` be evaluated *in the middle* of `f(p)` being evaluated, after the `*p = 1` and before the `*p = 2`? The spec says simply: > For example, in the (function-local) assignment > > ``` > y[f()], ok = g(h(), i()+x[j()], <-c), k() > ``` > > the function calls and communication happen in the order `f()`, `h()`, `i()`, `j()`, `<-c`, `g()`, and `k()`. However, the order of those events compared to the evaluation and indexing of `x` and the evaluation of `y` is not specified. I don't think there's any other text in the spec that requires evaluation of a function call to within an expression to be handled atomically with respect to other expressions either. @griesemer and I agree only 0 or 2 should be allowed (i.e., 1 should not be allowed), but that the spec could be clearer about this. ``` package main func main() { x, _ := g() println(x) } func g() (int, int) { p := new(int) return *p, f(p) } func f(p *int) int { *p = 1 *p = 2 return 0 } ``` ",1.0,"spec: clarify sequencing of function calls within expressions - The program below tests the order-of-evaluation semantics of `return *p, f(p)`. With gccgo, it prints 0 (i.e., evaluating `*p` before calling `f(p)`), and with cmd/compile it prints 2 (i.e., evaluating `*p` after `f(p)` returns). But is it allowed to print `1`? I.e., can `*p` be evaluated *in the middle* of `f(p)` being evaluated, after the `*p = 1` and before the `*p = 2`? The spec says simply: > For example, in the (function-local) assignment > > ``` > y[f()], ok = g(h(), i()+x[j()], <-c), k() > ``` > > the function calls and communication happen in the order `f()`, `h()`, `i()`, `j()`, `<-c`, `g()`, and `k()`. However, the order of those events compared to the evaluation and indexing of `x` and the evaluation of `y` is not specified. I don't think there's any other text in the spec that requires evaluation of a function call to within an expression to be handled atomically with respect to other expressions either. @griesemer and I agree only 0 or 2 should be allowed (i.e., 1 should not be allowed), but that the spec could be clearer about this. ``` package main func main() { x, _ := g() println(x) } func g() (int, int) { p := new(int) return *p, f(p) } func f(p *int) int { *p = 1 *p = 2 return 0 } ``` ",1,spec clarify sequencing of function calls within expressions the program below tests the order of evaluation semantics of return p f p with gccgo it prints i e evaluating p before calling f p and with cmd compile it prints i e evaluating p after f p returns but is it allowed to print i e can p be evaluated in the middle of f p being evaluated after the p and before the p the spec says simply for example in the function local assignment y ok g h i x c k the function calls and communication happen in the order f h i j c g and k however the order of those events compared to the evaluation and indexing of x and the evaluation of y is not specified i don t think there s any other text in the spec that requires evaluation of a function call to within an expression to be handled atomically with respect to other expressions either griesemer and i agree only or should be allowed i e should not be allowed but that the spec could be clearer about this package main func main x g println x func g int int p new int return p f p func f p int int p p return ,1 369550,25856303499.0,IssuesEvent,2022-12-13 14:00:58,golang/go,https://api.github.com/repos/golang/go,closed,x/sys/unix: Undocumented (possibly incorrect?) SendmsgBuffers behavior with empty iovec,Documentation help wanted NeedsInvestigation compiler/runtime," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.3 linux/amd64
$ cat go.sum
golang.org/x/sys v0.2.0 h1:ljd4t30dBnAvMZaQCevtY0xLLD0A+bRZXbgLMLU1F/A=
golang.org/x/sys v0.2.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/dave/.cache/go-build""
GOENV=""/home/dave/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/dave/Source/Go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/dave/Source/Go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.19""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.19/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19.3""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/dave/Source/keyholder/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1272319925=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I'm interfacing with the Linux kernel cryptography API using the AF_ALG interface, across two processes. One process is responsible for setting up an AF_ALG (SOCK_SEQPACKET) socket, including setting the key and IV, and then the resulting socket file descriptor is passed to another process (using SCM_RIGHTS), which uses it for encryption or decryption. By design, the first process does not have access to any of the plaintext or ciphertext data, and the second process does not have access to the encryption key. The bug I was encountering was seemingly an extra '\0' in the decrypted plaintext output and an off-by-one error between plaintext and expected ciphertext length. I discovered this is because an extra byte is silently added by x/sys/unix.sendmsgN() if passed an empty Iovec but non-empty out-of-band data, on a non-SOCK_DGRAM socket: https://cs.opensource.google/go/x/sys/+/refs/tags/v0.2.0:unix/syscall_linux.go;l=1538;drc=d684c6f886692f8b63049d3dabe4f1911ae979c3;bpv=1;bpt=1 As far as I can tell, this behavior is undocumented. I believe some socket types require at least one byte of data with OOB, but AF_ALG sockets do not. (The Linux kernel documentation references https://www.chronox.de/libkcapi.html as the canonical client implementation, and it follows the pattern of OOB-but-empty-data to set up the socket, and then it uses vmsplice() to send the non-OOB data.) The following call results in the extra byte being sent to the socket (error handling and populating `var oob []byte` omitted): ``` unix.SendmsgBuffers(fd, nil, oob, nil, unix.MSG_MORE) ``` This code works as expected: ``` msg := &unix.Msghdr{ Control: &oob[0], // Remaining fields, including Iov and Iovlen are zero } msg.SetControllen(len(oob)) unix.Syscall(unix.SYS_SENDMSG, uintptr(fd), uintptr(unsafe.Pointer(msg)), unix.MSG_MORE) ``` ### What did you expect to see? An empty [][]byte resulting in no data being sent. The documentation for SendmsgBuffers states, ""the function returns the number of bytes written to the socket."" ### What did you see instead? A '\0' byte being sent to the socket unexpectedly. SendmsgBuffers returns 0, but actually sends 1 byte to the socket. ### Possible solutions/topics for discussion The implicit extra byte with Sendmsg appears to date back to the very first Go commit, so it probably comes from Plan 9. SendmsgBuffers is, however, relatively new (https://github.com/golang/go/issues/52885) so maybe its API/behavior is not as set in stone. Whether or not their behavior in this regard should diverge is probably a topic for debate. Should SOCK_SEQPACKET be treated the same as SOCK_DGRAM, and excluded from having the extra byte sent? If so, should the socket types (maybe just SOCK_STREAM) that require special empty-iovec handling be an allowlist instead of a denylist? Should the SendmsgBuffers return value be updated to reflect the actual number of bytes sent when passed an empty [][]byte? Instead of silently adding an invisible byte, should an error be returned if SendmsgBuffers is not supposed to be called with an empty [][]byte? Even if no changes to behavior are warranted, should SendmsgBuffer's documentation be improved? (Yes, I am volunteering to do so. :)) ",1.0,"x/sys/unix: Undocumented (possibly incorrect?) SendmsgBuffers behavior with empty iovec - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.3 linux/amd64
$ cat go.sum
golang.org/x/sys v0.2.0 h1:ljd4t30dBnAvMZaQCevtY0xLLD0A+bRZXbgLMLU1F/A=
golang.org/x/sys v0.2.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/dave/.cache/go-build""
GOENV=""/home/dave/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/dave/Source/Go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/dave/Source/Go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.19""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.19/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.19.3""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/dave/Source/keyholder/go.mod""
GOWORK=""""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1272319925=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I'm interfacing with the Linux kernel cryptography API using the AF_ALG interface, across two processes. One process is responsible for setting up an AF_ALG (SOCK_SEQPACKET) socket, including setting the key and IV, and then the resulting socket file descriptor is passed to another process (using SCM_RIGHTS), which uses it for encryption or decryption. By design, the first process does not have access to any of the plaintext or ciphertext data, and the second process does not have access to the encryption key. The bug I was encountering was seemingly an extra '\0' in the decrypted plaintext output and an off-by-one error between plaintext and expected ciphertext length. I discovered this is because an extra byte is silently added by x/sys/unix.sendmsgN() if passed an empty Iovec but non-empty out-of-band data, on a non-SOCK_DGRAM socket: https://cs.opensource.google/go/x/sys/+/refs/tags/v0.2.0:unix/syscall_linux.go;l=1538;drc=d684c6f886692f8b63049d3dabe4f1911ae979c3;bpv=1;bpt=1 As far as I can tell, this behavior is undocumented. I believe some socket types require at least one byte of data with OOB, but AF_ALG sockets do not. (The Linux kernel documentation references https://www.chronox.de/libkcapi.html as the canonical client implementation, and it follows the pattern of OOB-but-empty-data to set up the socket, and then it uses vmsplice() to send the non-OOB data.) The following call results in the extra byte being sent to the socket (error handling and populating `var oob []byte` omitted): ``` unix.SendmsgBuffers(fd, nil, oob, nil, unix.MSG_MORE) ``` This code works as expected: ``` msg := &unix.Msghdr{ Control: &oob[0], // Remaining fields, including Iov and Iovlen are zero } msg.SetControllen(len(oob)) unix.Syscall(unix.SYS_SENDMSG, uintptr(fd), uintptr(unsafe.Pointer(msg)), unix.MSG_MORE) ``` ### What did you expect to see? An empty [][]byte resulting in no data being sent. The documentation for SendmsgBuffers states, ""the function returns the number of bytes written to the socket."" ### What did you see instead? A '\0' byte being sent to the socket unexpectedly. SendmsgBuffers returns 0, but actually sends 1 byte to the socket. ### Possible solutions/topics for discussion The implicit extra byte with Sendmsg appears to date back to the very first Go commit, so it probably comes from Plan 9. SendmsgBuffers is, however, relatively new (https://github.com/golang/go/issues/52885) so maybe its API/behavior is not as set in stone. Whether or not their behavior in this regard should diverge is probably a topic for debate. Should SOCK_SEQPACKET be treated the same as SOCK_DGRAM, and excluded from having the extra byte sent? If so, should the socket types (maybe just SOCK_STREAM) that require special empty-iovec handling be an allowlist instead of a denylist? Should the SendmsgBuffers return value be updated to reflect the actual number of bytes sent when passed an empty [][]byte? Instead of silently adding an invisible byte, should an error be returned if SendmsgBuffers is not supposed to be called with an empty [][]byte? Even if no changes to behavior are warranted, should SendmsgBuffer's documentation be improved? (Yes, I am volunteering to do so. :)) ",1,x sys unix undocumented possibly incorrect sendmsgbuffers behavior with empty iovec please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux cat go sum golang org x sys a golang org x sys go mod does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home dave cache go build goenv home dave config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home dave source go pkg mod gonoproxy gonosumdb goos linux gopath home dave source go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home dave source keyholder go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread wl no gc sections fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do i m interfacing with the linux kernel cryptography api using the af alg interface across two processes one process is responsible for setting up an af alg sock seqpacket socket including setting the key and iv and then the resulting socket file descriptor is passed to another process using scm rights which uses it for encryption or decryption by design the first process does not have access to any of the plaintext or ciphertext data and the second process does not have access to the encryption key the bug i was encountering was seemingly an extra in the decrypted plaintext output and an off by one error between plaintext and expected ciphertext length i discovered this is because an extra byte is silently added by x sys unix sendmsgn if passed an empty iovec but non empty out of band data on a non sock dgram socket as far as i can tell this behavior is undocumented i believe some socket types require at least one byte of data with oob but af alg sockets do not the linux kernel documentation references as the canonical client implementation and it follows the pattern of oob but empty data to set up the socket and then it uses vmsplice to send the non oob data the following call results in the extra byte being sent to the socket error handling and populating var oob byte omitted unix sendmsgbuffers fd nil oob nil unix msg more this code works as expected msg unix msghdr control oob remaining fields including iov and iovlen are zero msg setcontrollen len oob unix syscall unix sys sendmsg uintptr fd uintptr unsafe pointer msg unix msg more what did you expect to see an empty byte resulting in no data being sent the documentation for sendmsgbuffers states the function returns the number of bytes written to the socket what did you see instead a byte being sent to the socket unexpectedly sendmsgbuffers returns but actually sends byte to the socket possible solutions topics for discussion the implicit extra byte with sendmsg appears to date back to the very first go commit so it probably comes from plan sendmsgbuffers is however relatively new so maybe its api behavior is not as set in stone whether or not their behavior in this regard should diverge is probably a topic for debate should sock seqpacket be treated the same as sock dgram and excluded from having the extra byte sent if so should the socket types maybe just sock stream that require special empty iovec handling be an allowlist instead of a denylist should the sendmsgbuffers return value be updated to reflect the actual number of bytes sent when passed an empty byte instead of silently adding an invisible byte should an error be returned if sendmsgbuffers is not supposed to be called with an empty byte even if no changes to behavior are warranted should sendmsgbuffer s documentation be improved yes i am volunteering to do so ,1 53634,7846973481.0,IssuesEvent,2018-06-19 16:58:33,golang/go,https://api.github.com/repos/golang/go,opened,crypto/rand: decide on the hyphenation of pseudorandom vs pseudo-random,Documentation,"The docs for crypto/rand contain both ""pseudorandom"" and ""pseudo-random"" for the same part of speech. Decide which to use. Also, the package doc says: > Package rand implements a cryptographically secure pseudorandom number generator. But the Reader says: > Reader is a global, shared instance of a cryptographically strong pseudo-random generator. Is it cryptographically ""strong"" or is it ""secure""? Can we pick a word there too? Or can we just remove ""pseudorandom"" altogether? I feel like it makes it sound too much like math/rand. Can we just say ""cryptographically secure random number generator""? /cc @FiloSottile @agl @ianlancetaylor ",1.0,"crypto/rand: decide on the hyphenation of pseudorandom vs pseudo-random - The docs for crypto/rand contain both ""pseudorandom"" and ""pseudo-random"" for the same part of speech. Decide which to use. Also, the package doc says: > Package rand implements a cryptographically secure pseudorandom number generator. But the Reader says: > Reader is a global, shared instance of a cryptographically strong pseudo-random generator. Is it cryptographically ""strong"" or is it ""secure""? Can we pick a word there too? Or can we just remove ""pseudorandom"" altogether? I feel like it makes it sound too much like math/rand. Can we just say ""cryptographically secure random number generator""? /cc @FiloSottile @agl @ianlancetaylor ",1,crypto rand decide on the hyphenation of pseudorandom vs pseudo random the docs for crypto rand contain both pseudorandom and pseudo random for the same part of speech decide which to use also the package doc says package rand implements a cryptographically secure pseudorandom number generator but the reader says reader is a global shared instance of a cryptographically strong pseudo random generator is it cryptographically strong or is it secure can we pick a word there too or can we just remove pseudorandom altogether i feel like it makes it sound too much like math rand can we just say cryptographically secure random number generator cc filosottile agl ianlancetaylor ,1 182403,14913986345.0,IssuesEvent,2021-01-22 14:51:11,golang/go,https://api.github.com/repos/golang/go,closed,time: Timer.Reset documentation not accurate for AfterFunc timers,Documentation NeedsFix help wanted,"https://golang.org/pkg/time/#Timer.Reset says: > Resetting a timer must take care not to race with the send into t.C that happens when the current timer expires. If a program has already received a value from t.C, the timer is known to have expired, and t.Reset can be used directly. If a program has not yet received a value from t.C, however, the timer must be stopped and—if Stop reports that the timer expired before being stopped—the channel explicitly drained: And proceeds to give an example of proper usage of Reset. But a Timer created by [AfterFunc](https://golang.org/pkg/time/#AfterFunc) never sends on the channel. We should probably say something about AfterFunc in the Timer.Reset docs. /cc @dmitshur @ianlancetaylor ",1.0,"time: Timer.Reset documentation not accurate for AfterFunc timers - https://golang.org/pkg/time/#Timer.Reset says: > Resetting a timer must take care not to race with the send into t.C that happens when the current timer expires. If a program has already received a value from t.C, the timer is known to have expired, and t.Reset can be used directly. If a program has not yet received a value from t.C, however, the timer must be stopped and—if Stop reports that the timer expired before being stopped—the channel explicitly drained: And proceeds to give an example of proper usage of Reset. But a Timer created by [AfterFunc](https://golang.org/pkg/time/#AfterFunc) never sends on the channel. We should probably say something about AfterFunc in the Timer.Reset docs. /cc @dmitshur @ianlancetaylor ",1,time timer reset documentation not accurate for afterfunc timers says resetting a timer must take care not to race with the send into t c that happens when the current timer expires if a program has already received a value from t c the timer is known to have expired and t reset can be used directly if a program has not yet received a value from t c however the timer must be stopped and—if stop reports that the timer expired before being stopped—the channel explicitly drained and proceeds to give an example of proper usage of reset but a timer created by never sends on the channel we should probably say something about afterfunc in the timer reset docs cc dmitshur ianlancetaylor ,1 330123,24248159560.0,IssuesEvent,2022-09-27 12:19:50,golang/go,https://api.github.com/repos/golang/go,closed,unsafe: document valid uses of `unsafe.Pointer` for non-Go memory,Documentation WaitingForInfo," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.10 linux/amd64
### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for `unsafe.Pointer` ### What did you expect to see? A documented method for accessing memory outside of the garbage-collected heap, such as memory allocated by C’s `malloc`. ### What did you see instead? No such method.",1.0,"unsafe: document valid uses of `unsafe.Pointer` for non-Go memory - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.10 linux/amd64
### Does this issue reproduce with the latest release? N/A ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? Read the documentation for `unsafe.Pointer` ### What did you expect to see? A documented method for accessing memory outside of the garbage-collected heap, such as memory allocated by C’s `malloc`. ### What did you see instead? No such method.",1,unsafe document valid uses of unsafe pointer for non go memory please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release n a what operating system and processor architecture are you using go env n a 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 read the documentation for unsafe pointer what did you expect to see a documented method for accessing memory outside of the garbage collected heap such as memory allocated by c’s malloc what did you see instead no such method ,1 152143,13446463489.0,IssuesEvent,2020-09-08 13:00:05,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: It looks like there's a copy paste error in the ""Create a Go module"" tutorial",Documentation NeedsFix,"> Create a module -- Write a small module with functions you can call from another module. > Call your code from another module -- Add simple error handling. > Return and handle an error -- Add simple error handling. > Return a random greeting -- Handle data in slices (Go's dynamically-sized arrays). The text in the 2nd list item is a duplicate of the text in the 3rd list item.",1.0,"x/website: It looks like there's a copy paste error in the ""Create a Go module"" tutorial - > Create a module -- Write a small module with functions you can call from another module. > Call your code from another module -- Add simple error handling. > Return and handle an error -- Add simple error handling. > Return a random greeting -- Handle data in slices (Go's dynamically-sized arrays). The text in the 2nd list item is a duplicate of the text in the 3rd list item.",1,x website it looks like there s a copy paste error in the create a go module tutorial create a module write a small module with functions you can call from another module call your code from another module add simple error handling return and handle an error add simple error handling return a random greeting handle data in slices go s dynamically sized arrays the text in the list item is a duplicate of the text in the list item ,1 36787,17935400609.0,IssuesEvent,2021-09-10 14:44:03,golang/go,https://api.github.com/repos/golang/go,closed,strange performance regression: lookup vs rsh,Performance," ### What version of Go are you using (`go version`)? 
go version go1.17 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/user/.cache/go-build""
GOENV=""/home/user/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/user/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/user/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.17""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/user/go/src/github.com/ethereum/go-ethereum/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-build171075918=/tmp/go-build -gno-record-gcc-switches""
### What did you do? In [go-ethereum](https://github.com/ethereum/go-ethereum), we have a an algorithm that iterates over a slice of bytes, and fills a bitmap depending on the values of those bytes. Certain values set a `1`, others leave it at `0`. While optimizing it, we found a behaviour that was very unintuitive, and we could not explain it. By using a small lookup table instead of a right-shift, performance increased by ~20%. This PR attempts to remove the lookup, and notes the performance regression: https://github.com/ethereum/go-ethereum/pull/23472 . I've made a PoC repro. analysis.go ```go package main type bitvec []byte var lookup = [8]byte{ 0x80, 0x40, 0x20, 0x10, 0x8, 0x4, 0x2, 0x1, } func (bits bitvec) set1(pos uint64) { if true { bits[pos/8] |= lookup[pos%8] } else { bits[pos/8] |= 0x80 >> (pos & 7) } } func codeBitmapInternal(code []byte, bits bitvec) bitvec { for pc := uint64(0); pc < uint64(len(code)); { op := code[pc] pc++ if op < 0x60 || op > 0x7f { continue } numbits := op - 0x60 + 1 switch numbits { case 1: bits.set1(pc) pc += 1 } } return bits } ``` analysis_test.go: ```go package main import ( ""fmt"" ""testing"" ) const analysisCodeSize = 1200 * 1024 func BenchmarkJumpdestOpAnalysis(bench *testing.B) { var op byte bencher := func(b *testing.B) { code := make([]byte, analysisCodeSize) b.SetBytes(analysisCodeSize) for i := range code { code[i] = op } bits := make(bitvec, len(code)/8+1+4) b.ResetTimer() for i := 0; i < b.N; i++ { for j := range bits { bits[j] = 0 } codeBitmapInternal(code, bits) } } op = 0x60 bench.Run(fmt.Sprintf(""%x"", op), bencher) op = 0 bench.Run(fmt.Sprintf(""%x"", op), bencher) } ``` And a script to perform the benchmark, then replace the shift with a `lookup`: test.sh: ```bash sed -i 's/true/false/' analysis.go go test . -bench . --count 5 > 1.txt sed -i 's/false/true/' analysis.go go test . -bench . --count 5 > 2.txt benchstat 1.txt 2.txt ``` Running this yields: ``` bash test.sh name old time/op new time/op delta JumpdestOpAnalysis/60-6 1.06ms ± 2% 0.87ms ± 3% -17.81% (p=0.008 n=5+5) JumpdestOpAnalysis/0-6 1.01ms ± 3% 1.01ms ± 4% ~ (p=0.548 n=5+5) name old speed new speed delta JumpdestOpAnalysis/60-6 1.16GB/s ± 2% 1.41GB/s ± 3% +21.70% (p=0.008 n=5+5) JumpdestOpAnalysis/0-6 1.21GB/s ± 3% 1.22GB/s ± 4% ~ (p=0.548 n=5+5) ``` In other words, the code using: ```go var lookup = [8]byte{ 0x80, 0x40, 0x20, 0x10, 0x8, 0x4, 0x2, 0x1, } ... bits[pos/8] |= lookup[pos%8] ``` Is a lot faster than the code using right shift: ```go bits[pos/8] |= 0x80 >> (pos & 7) ``` ### What did you expect to see? I expected the right shift operation to be at least as fast as the lookup-based variant. ### What did you see instead? The lookup being faster. So, this is maybe not a bug, but it's behaviour that I would be grateful to figure out the underlying reason for. I guess also there is a slight chance that the compiler somehow misses an opportunity to optimize something here. I have studied the `gcflags=""-m -m ""` output to see if the inlining output showed anything: but afaict the inlining behaviour is identical across both variants. ",True,"strange performance regression: lookup vs rsh - ### What version of Go are you using (`go version`)? 
go version go1.17 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/user/.cache/go-build""
GOENV=""/home/user/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/user/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/user/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.17""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/user/go/src/github.com/ethereum/go-ethereum/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-build171075918=/tmp/go-build -gno-record-gcc-switches""
### What did you do? In [go-ethereum](https://github.com/ethereum/go-ethereum), we have a an algorithm that iterates over a slice of bytes, and fills a bitmap depending on the values of those bytes. Certain values set a `1`, others leave it at `0`. While optimizing it, we found a behaviour that was very unintuitive, and we could not explain it. By using a small lookup table instead of a right-shift, performance increased by ~20%. This PR attempts to remove the lookup, and notes the performance regression: https://github.com/ethereum/go-ethereum/pull/23472 . I've made a PoC repro. analysis.go ```go package main type bitvec []byte var lookup = [8]byte{ 0x80, 0x40, 0x20, 0x10, 0x8, 0x4, 0x2, 0x1, } func (bits bitvec) set1(pos uint64) { if true { bits[pos/8] |= lookup[pos%8] } else { bits[pos/8] |= 0x80 >> (pos & 7) } } func codeBitmapInternal(code []byte, bits bitvec) bitvec { for pc := uint64(0); pc < uint64(len(code)); { op := code[pc] pc++ if op < 0x60 || op > 0x7f { continue } numbits := op - 0x60 + 1 switch numbits { case 1: bits.set1(pc) pc += 1 } } return bits } ``` analysis_test.go: ```go package main import ( ""fmt"" ""testing"" ) const analysisCodeSize = 1200 * 1024 func BenchmarkJumpdestOpAnalysis(bench *testing.B) { var op byte bencher := func(b *testing.B) { code := make([]byte, analysisCodeSize) b.SetBytes(analysisCodeSize) for i := range code { code[i] = op } bits := make(bitvec, len(code)/8+1+4) b.ResetTimer() for i := 0; i < b.N; i++ { for j := range bits { bits[j] = 0 } codeBitmapInternal(code, bits) } } op = 0x60 bench.Run(fmt.Sprintf(""%x"", op), bencher) op = 0 bench.Run(fmt.Sprintf(""%x"", op), bencher) } ``` And a script to perform the benchmark, then replace the shift with a `lookup`: test.sh: ```bash sed -i 's/true/false/' analysis.go go test . -bench . --count 5 > 1.txt sed -i 's/false/true/' analysis.go go test . -bench . --count 5 > 2.txt benchstat 1.txt 2.txt ``` Running this yields: ``` bash test.sh name old time/op new time/op delta JumpdestOpAnalysis/60-6 1.06ms ± 2% 0.87ms ± 3% -17.81% (p=0.008 n=5+5) JumpdestOpAnalysis/0-6 1.01ms ± 3% 1.01ms ± 4% ~ (p=0.548 n=5+5) name old speed new speed delta JumpdestOpAnalysis/60-6 1.16GB/s ± 2% 1.41GB/s ± 3% +21.70% (p=0.008 n=5+5) JumpdestOpAnalysis/0-6 1.21GB/s ± 3% 1.22GB/s ± 4% ~ (p=0.548 n=5+5) ``` In other words, the code using: ```go var lookup = [8]byte{ 0x80, 0x40, 0x20, 0x10, 0x8, 0x4, 0x2, 0x1, } ... bits[pos/8] |= lookup[pos%8] ``` Is a lot faster than the code using right shift: ```go bits[pos/8] |= 0x80 >> (pos & 7) ``` ### What did you expect to see? I expected the right shift operation to be at least as fast as the lookup-based variant. ### What did you see instead? The lookup being faster. So, this is maybe not a bug, but it's behaviour that I would be grateful to figure out the underlying reason for. I guess also there is a slight chance that the compiler somehow misses an opportunity to optimize something here. I have studied the `gcflags=""-m -m ""` output to see if the inlining output showed anything: but afaict the inlining behaviour is identical across both variants. ",0,strange performance regression lookup vs rsh please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output goarch gobin gocache home user cache go build goenv home user config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home user go pkg mod gonoproxy gonosumdb goos linux gopath home user go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home user go src github com ethereum go ethereum go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do in we have a an algorithm that iterates over a slice of bytes and fills a bitmap depending on the values of those bytes certain values set a others leave it at while optimizing it we found a behaviour that was very unintuitive and we could not explain it by using a small lookup table instead of a right shift performance increased by this pr attempts to remove the lookup and notes the performance regression i ve made a poc repro analysis go go package main type bitvec byte var lookup byte func bits bitvec pos if true bits lookup else bits pos func codebitmapinternal code byte bits bitvec bitvec for pc pc len code op code pc if op continue numbits op switch numbits case bits pc pc return bits analysis test go go package main import fmt testing const analysiscodesize func benchmarkjumpdestopanalysis bench testing b var op byte bencher func b testing b code make byte analysiscodesize b setbytes analysiscodesize for i range code code op bits make bitvec len code b resettimer for i i b n i for j range bits bits codebitmapinternal code bits op bench run fmt sprintf x op bencher op bench run fmt sprintf x op bencher and a script to perform the benchmark then replace the shift with a lookup test sh bash sed i s true false analysis go go test bench count txt sed i s false true analysis go go test bench count txt benchstat txt txt running this yields bash test sh name old time op new time op delta jumpdestopanalysis ± ± p n jumpdestopanalysis ± ± p n name old speed new speed delta jumpdestopanalysis s ± s ± p n jumpdestopanalysis s ± s ± p n in other words the code using go var lookup byte bits lookup is a lot faster than the code using right shift go bits pos what did you expect to see i expected the right shift operation to be at least as fast as the lookup based variant what did you see instead the lookup being faster so this is maybe not a bug but it s behaviour that i would be grateful to figure out the underlying reason for i guess also there is a slight chance that the compiler somehow misses an opportunity to optimize something here i have studied the gcflags m m output to see if the inlining output showed anything but afaict the inlining behaviour is identical across both variants ,0 433754,30348517251.0,IssuesEvent,2023-07-11 17:06:49,golang/go,https://api.github.com/repos/golang/go,closed,log/slog: don't write nil contexts [freeze exception] ,Testing Documentation NeedsFix,"As #61219 points out, we should not pass nil where a context.Context is expected. https://go.dev/cl/508437 contains the fix, which includes code as well as documentation. /cc @golang/release ",1.0,"log/slog: don't write nil contexts [freeze exception] - As #61219 points out, we should not pass nil where a context.Context is expected. https://go.dev/cl/508437 contains the fix, which includes code as well as documentation. /cc @golang/release ",1,log slog don t write nil contexts as points out we should not pass nil where a context context is expected contains the fix which includes code as well as documentation cc golang release ,1 70950,9462993574.0,IssuesEvent,2019-04-17 16:39:11,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go mod why lies,Documentation NeedsInvestigation WaitingForInfo modules," ### What version of Go are you using (`go version`)? 
go version go1.12.1 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/me/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/me/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/Users/me/sdk/go1.12.1""
GOTMPDIR=""""
GOTOOLDIR=""/Users/me/sdk/go1.12.1/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/me/orbital/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/sp/06p28g2d0vs7gd2vhf26wl9m0000gn/T/go-build849154512=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? 
$ grep bson go.mod 
$ grep labix go.mod
        labix.org/v2/mgo v0.0.0-20140701140051-000000000287 // indirect
$ go mod why labix.org/v2/mgo
# labix.org/v2/mgo
(main module does not need package labix.org/v2/mgo)
$ go mod why labix.org/v2/mgo/bson
# labix.org/v2/mgo/bson
/very/important/package
github.com/nats-io/go-nats-streaming
github.com/nats-io/go-nats-streaming.test
github.com/nats-io/nats-streaming-server/server
github.com/hashicorp/go-msgpack/codec
github.com/hashicorp/go-msgpack/codec.test
labix.org/v2/mgo/bson
$ go mod vendor
$ find vendor -name bson
$
### What did you expect to see? At least some mention of the package ""bson"" anywhere in go mod's output. ### What did you see instead? Zero mention of the package ""bson"" anywhere in go mod's output.",1.0,"cmd/go: go mod why lies - ### What version of Go are you using (`go version`)? 
go version go1.12.1 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/me/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/me/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/Users/me/sdk/go1.12.1""
GOTMPDIR=""""
GOTOOLDIR=""/Users/me/sdk/go1.12.1/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/me/orbital/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/sp/06p28g2d0vs7gd2vhf26wl9m0000gn/T/go-build849154512=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? 
$ grep bson go.mod 
$ grep labix go.mod
        labix.org/v2/mgo v0.0.0-20140701140051-000000000287 // indirect
$ go mod why labix.org/v2/mgo
# labix.org/v2/mgo
(main module does not need package labix.org/v2/mgo)
$ go mod why labix.org/v2/mgo/bson
# labix.org/v2/mgo/bson
/very/important/package
github.com/nats-io/go-nats-streaming
github.com/nats-io/go-nats-streaming.test
github.com/nats-io/nats-streaming-server/server
github.com/hashicorp/go-msgpack/codec
github.com/hashicorp/go-msgpack/codec.test
labix.org/v2/mgo/bson
$ go mod vendor
$ find vendor -name bson
$
### What did you expect to see? At least some mention of the package ""bson"" anywhere in go mod's output. ### What did you see instead? Zero mention of the package ""bson"" anywhere in go mod's output.",1,cmd go go mod why lies what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users me library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users me go goproxy gorace goroot users me sdk gotmpdir gotooldir users me sdk pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod users me orbital go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders sp t go tmp go build gno record gcc switches fno common what did you do grep bson go mod grep labix go mod labix org mgo indirect go mod why labix org mgo labix org mgo main module does not need package labix org mgo go mod why labix org mgo bson labix org mgo bson very important package github com nats io go nats streaming github com nats io go nats streaming test github com nats io nats streaming server server github com hashicorp go msgpack codec github com hashicorp go msgpack codec test labix org mgo bson go mod vendor find vendor name bson what did you expect to see at least some mention of the package bson anywhere in go mod s output what did you see instead zero mention of the package bson anywhere in go mod s output ,1 139070,11242837453.0,IssuesEvent,2020-01-10 00:43:50,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go/internal/modload: e0cf3de987e6 no longer is the latest commit on the master branch,GoCommand NeedsInvestigation Testing modules,"Both on `master` and `release-branch.go1.13`, there is a comment in query_test.go: https://github.com/golang/go/blob/56d6b87972c9852570fe017ac5fa153314c21992/src/cmd/go/internal/modload/query_test.go#L166-L170 It says that ""e0cf3de987e6 is the latest commit on the master branch"". This is no longer true, there are now three newer commits on master branch of https://vcs-test.golang.org/git/querytest repo: ``` querytest $ git log --oneline origin/master ed5ffda (HEAD -> master, origin/master, origin/HEAD) after v1.9.10-pre2+metadata 42abcb6 (tag: v1.9.10-pre2+metadata) at v1.9.10-pre2+metadata 66f8cbe before v1.9.10-pre2+metadata e0cf3de (tag: v1.9.10-pre1) at v1.9.10-pre1 ``` Other than the comment being wrong, this is harmless and the tests are still passing on `master` and `release-branch.go1.13`. However, `release-branch.go1.12` does not have [CL 186237](https://golang.org/cl/186237) applied: https://github.com/golang/go/blob/56d6b87972c9852570fe017ac5fa153314c21992/src/cmd/go/internal/modload/query_test.go#L166-L170 Which is causing the `TestQuery` test to fail on `release-branch.go1.12`:

``` $ go test cmd/go/internal/modload go: finding golang.org/x/net/context latest go: finding golang.org/x/net latest go: downloading golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 go: extracting golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 go: finding golang.org/x/text v0.3.2 go: downloading golang.org/x/text v0.3.2 go: extracting golang.org/x/text v0.3.2 go: finding github.com/rsc/quote/buggy latest go: finding github.com/rsc/quote v1.5.2 go: downloading github.com/rsc/quote v1.5.2 go: extracting github.com/rsc/quote v1.5.2 go: finding vcs-test.golang.org/git/querytest.git v0.0.0-pre1 go: finding vcs-test.golang.org/git/querytest.git v0.0.0 go: finding vcs-test.golang.org/git/querytest.git v0.0.1 go: finding vcs-test.golang.org/git/querytest.git v0.0.99 go: finding vcs-test.golang.org/git/querytest.git v0.3.0 go: finding vcs-test.golang.org/git/querytest.git v0.1.2 go: finding vcs-test.golang.org/git/querytest.git v0.0.3 go: finding vcs-test.golang.org/git/querytest.git v1.9.9 go: finding vcs-test.golang.org/git/querytest.git latest go: finding vcs-test.golang.org/git/querytest.git v1.9.10-pre1 go: finding vcs-test.golang.org/git/querytest.git 6cf84eb go: finding vcs-test.golang.org/git/querytest.git start go: finding vcs-test.golang.org/git/querytest.git 7a1b6bf go: finding vcs-test.golang.org/git/querytest.git/v2 v2.0.0 go: finding vcs-test.golang.org/git/querytest.git/v2 v0.0.1 go: finding vcs-test.golang.org/git/querytest.git/v2 v2.5.5 go: finding vcs-test.golang.org/git/querytest.git/v3 latest go: finding vcs-test.golang.org/git/emptytest.git latest --- FAIL: TestQuery (5.70s) --- FAIL: TestQuery/vcs-test.golang.org_git_querytest.git_v3/latest/* (0.17s) query_test.go:153: Query(""vcs-test.golang.org/git/querytest.git/v3"", ""latest"", *) = v3.0.0-20191220134614-ed5ffdaa1f5e, want v3.0.0-20180704024501-e0cf3de987e6 FAIL FAIL cmd/go/internal/modload 14.080s ```
We should fix this to help with #29252. /cc @bcmills @jayconrod @matloob @cagedmantis",1.0,"cmd/go/internal/modload: e0cf3de987e6 no longer is the latest commit on the master branch - Both on `master` and `release-branch.go1.13`, there is a comment in query_test.go: https://github.com/golang/go/blob/56d6b87972c9852570fe017ac5fa153314c21992/src/cmd/go/internal/modload/query_test.go#L166-L170 It says that ""e0cf3de987e6 is the latest commit on the master branch"". This is no longer true, there are now three newer commits on master branch of https://vcs-test.golang.org/git/querytest repo: ``` querytest $ git log --oneline origin/master ed5ffda (HEAD -> master, origin/master, origin/HEAD) after v1.9.10-pre2+metadata 42abcb6 (tag: v1.9.10-pre2+metadata) at v1.9.10-pre2+metadata 66f8cbe before v1.9.10-pre2+metadata e0cf3de (tag: v1.9.10-pre1) at v1.9.10-pre1 ``` Other than the comment being wrong, this is harmless and the tests are still passing on `master` and `release-branch.go1.13`. However, `release-branch.go1.12` does not have [CL 186237](https://golang.org/cl/186237) applied: https://github.com/golang/go/blob/56d6b87972c9852570fe017ac5fa153314c21992/src/cmd/go/internal/modload/query_test.go#L166-L170 Which is causing the `TestQuery` test to fail on `release-branch.go1.12`:

``` $ go test cmd/go/internal/modload go: finding golang.org/x/net/context latest go: finding golang.org/x/net latest go: downloading golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 go: extracting golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 go: finding golang.org/x/text v0.3.2 go: downloading golang.org/x/text v0.3.2 go: extracting golang.org/x/text v0.3.2 go: finding github.com/rsc/quote/buggy latest go: finding github.com/rsc/quote v1.5.2 go: downloading github.com/rsc/quote v1.5.2 go: extracting github.com/rsc/quote v1.5.2 go: finding vcs-test.golang.org/git/querytest.git v0.0.0-pre1 go: finding vcs-test.golang.org/git/querytest.git v0.0.0 go: finding vcs-test.golang.org/git/querytest.git v0.0.1 go: finding vcs-test.golang.org/git/querytest.git v0.0.99 go: finding vcs-test.golang.org/git/querytest.git v0.3.0 go: finding vcs-test.golang.org/git/querytest.git v0.1.2 go: finding vcs-test.golang.org/git/querytest.git v0.0.3 go: finding vcs-test.golang.org/git/querytest.git v1.9.9 go: finding vcs-test.golang.org/git/querytest.git latest go: finding vcs-test.golang.org/git/querytest.git v1.9.10-pre1 go: finding vcs-test.golang.org/git/querytest.git 6cf84eb go: finding vcs-test.golang.org/git/querytest.git start go: finding vcs-test.golang.org/git/querytest.git 7a1b6bf go: finding vcs-test.golang.org/git/querytest.git/v2 v2.0.0 go: finding vcs-test.golang.org/git/querytest.git/v2 v0.0.1 go: finding vcs-test.golang.org/git/querytest.git/v2 v2.5.5 go: finding vcs-test.golang.org/git/querytest.git/v3 latest go: finding vcs-test.golang.org/git/emptytest.git latest --- FAIL: TestQuery (5.70s) --- FAIL: TestQuery/vcs-test.golang.org_git_querytest.git_v3/latest/* (0.17s) query_test.go:153: Query(""vcs-test.golang.org/git/querytest.git/v3"", ""latest"", *) = v3.0.0-20191220134614-ed5ffdaa1f5e, want v3.0.0-20180704024501-e0cf3de987e6 FAIL FAIL cmd/go/internal/modload 14.080s ```
We should fix this to help with #29252. /cc @bcmills @jayconrod @matloob @cagedmantis",0,cmd go internal modload no longer is the latest commit on the master branch both on master and release branch there is a comment in query test go it says that is the latest commit on the master branch this is no longer true there are now three newer commits on master branch of repo querytest git log oneline origin master head master origin master origin head after metadata tag metadata at metadata before metadata tag at other than the comment being wrong this is harmless and the tests are still passing on master and release branch however release branch does not have applied which is causing the testquery test to fail on release branch go test cmd go internal modload go finding golang org x net context latest go finding golang org x net latest go downloading golang org x net go extracting golang org x net go finding golang org x text go downloading golang org x text go extracting golang org x text go finding github com rsc quote buggy latest go finding github com rsc quote go downloading github com rsc quote go extracting github com rsc quote go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git latest go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git start go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git go finding vcs test golang org git querytest git latest go finding vcs test golang org git emptytest git latest fail testquery fail testquery vcs test golang org git querytest git latest query test go query vcs test golang org git querytest git latest want fail fail cmd go internal modload we should fix this to help with cc bcmills jayconrod matloob cagedmantis,0 399443,27241224725.0,IssuesEvent,2023-02-21 20:38:56,golang/go,https://api.github.com/repos/golang/go,closed,path/filepath: Clean changed in Go 1.20,Documentation NeedsFix,"I have some GitHub action tests that started to fail on Windows after I bumped the build matrix to Go 1.20. I have distilled the issue into this small repo: https://github.com/bep/go120winpathregression ``` --- FAIL: TestTo (0.00s) lib_test.go:12: error: values are not equal got: ""\\\\\\\\post"" want: ""\\post"" stack: D:/a/go[12](https://github.com/bep/go120winpathregression/actions/runs/4102512994/jobs/7075566395#step:11:13)0winpathregression/go120winpathregression/lib_test.go:12 c.Assert(Clean(""////post/////""), qt.Equals, filepath.FromSlash(""/post"")) ``` I have looked closely in the release notes for Go 1.20 about this, but that does not mention this change. Also, the GoDoc for `filepath.Clean` is pretty clear about what happens to ""multiple Separator elements"": > 1. Replace multiple Separator elements with a single one.",1.0,"path/filepath: Clean changed in Go 1.20 - I have some GitHub action tests that started to fail on Windows after I bumped the build matrix to Go 1.20. I have distilled the issue into this small repo: https://github.com/bep/go120winpathregression ``` --- FAIL: TestTo (0.00s) lib_test.go:12: error: values are not equal got: ""\\\\\\\\post"" want: ""\\post"" stack: D:/a/go[12](https://github.com/bep/go120winpathregression/actions/runs/4102512994/jobs/7075566395#step:11:13)0winpathregression/go120winpathregression/lib_test.go:12 c.Assert(Clean(""////post/////""), qt.Equals, filepath.FromSlash(""/post"")) ``` I have looked closely in the release notes for Go 1.20 about this, but that does not mention this change. Also, the GoDoc for `filepath.Clean` is pretty clear about what happens to ""multiple Separator elements"": > 1. Replace multiple Separator elements with a single one.",1,path filepath clean changed in go i have some github action tests that started to fail on windows after i bumped the build matrix to go i have distilled the issue into this small repo fail testto lib test go error values are not equal got post want post stack d a go c assert clean post qt equals filepath fromslash post i have looked closely in the release notes for go about this but that does not mention this change also the godoc for filepath clean is pretty clear about what happens to multiple separator elements replace multiple separator elements with a single one ,1 83763,10338182641.0,IssuesEvent,2019-09-03 16:19:15,golang/go,https://api.github.com/repos/golang/go,opened,Proposal: move mature wiki content behind Gerrit,Documentation Proposal,"### Summary The [Go Wiki](https://github.com/golang/go/wiki) has over 160 pages, and a set of rules that aren't being followed. There also isn't an effective review process in place, as we explain further below. I propose that we move the mature content behind Gerrit, to better ensure its quality and maintainability, and so that it can be blessed without fear of uncontrolled edits. This proposal does not cover what to do with the rest of the wiki content, or what to do with the existing wiki itself. That is left for another proposal to tackle. ### Problem statement It's only possible to have Go's wiki [readable or writable by everyone](https://help.github.com/en/articles/changing-access-permissions-for-wikis). The Go project opted for anyone to edit them. This has the advantage that the barrier to entry is low. However, this also means that there's no review process involved, and anyone can create a new wiki page at any time. The main wiki page reads: > * This wiki is open to editing by any member of the Go community with a GitHub account. > * If you would like to add a new page, please first open an issue in the [Go issue tracker](https://github.com/golang/go/issues) [...]. > * [...] please open an issue before renaming or removing any wiki page. However, it doesn't look like the process to add new pages works. With 160 pages, I could only find about a dozen issues requesting the addition of a new wiki page after a five minute search, with queries like `is:issue wiki page in:title`. The quality of the pages also varies greatly. Some of them were written or maintained by the Go team, such as [CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments), [Modules](https://github.com/golang/go/wiki/Modules), and [AssemblyPolicy](https://github.com/golang/go/wiki/AssemblyPolicy). These are well reviewed, and are often considered ""blessed"" by the Go project. On the other hand, many others have never been approved by a Go issue and have gone through no proper reviews anywhere public. Note that I'm not attaching any examples here to not point any fingers at any wiki authors. The other side of the problem is that, while the wiki is often cited as being ""maintained by the Go community"", many Go users treat anything under the `golang/go` repository as being blessed by the Go team. This is an understandable misconception, as the repository is otherwise under the team's supervision. Finally, there is https://groups.google.com/forum/#!forum/golang-wikichanges, but that's a system that requires lots of active attention and ultimately isn't as effective as code review. As an example, the Modules page was deleted on August 26th, so the page was gone until someone noticed and reverted the edit. ### Proposed solution Important documentation should go through the review process, just like code and godoc changes do. There's currently no way to do that with GitHub Wikis. I propose the following steps: 1) Announce the plan below to golang-dev and golang-nuts, and update the main wiki page 2) Gradually move relevant wiki pages somewhere under Gerrit, such as an `x/doc` or `x/wiki` repository 3) Start making these pages available somewhere official, such as under golang.org/doc or golang.org/wiki 4) Modify the moved Wiki pages to link or redirect to their new locations",1.0,"Proposal: move mature wiki content behind Gerrit - ### Summary The [Go Wiki](https://github.com/golang/go/wiki) has over 160 pages, and a set of rules that aren't being followed. There also isn't an effective review process in place, as we explain further below. I propose that we move the mature content behind Gerrit, to better ensure its quality and maintainability, and so that it can be blessed without fear of uncontrolled edits. This proposal does not cover what to do with the rest of the wiki content, or what to do with the existing wiki itself. That is left for another proposal to tackle. ### Problem statement It's only possible to have Go's wiki [readable or writable by everyone](https://help.github.com/en/articles/changing-access-permissions-for-wikis). The Go project opted for anyone to edit them. This has the advantage that the barrier to entry is low. However, this also means that there's no review process involved, and anyone can create a new wiki page at any time. The main wiki page reads: > * This wiki is open to editing by any member of the Go community with a GitHub account. > * If you would like to add a new page, please first open an issue in the [Go issue tracker](https://github.com/golang/go/issues) [...]. > * [...] please open an issue before renaming or removing any wiki page. However, it doesn't look like the process to add new pages works. With 160 pages, I could only find about a dozen issues requesting the addition of a new wiki page after a five minute search, with queries like `is:issue wiki page in:title`. The quality of the pages also varies greatly. Some of them were written or maintained by the Go team, such as [CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments), [Modules](https://github.com/golang/go/wiki/Modules), and [AssemblyPolicy](https://github.com/golang/go/wiki/AssemblyPolicy). These are well reviewed, and are often considered ""blessed"" by the Go project. On the other hand, many others have never been approved by a Go issue and have gone through no proper reviews anywhere public. Note that I'm not attaching any examples here to not point any fingers at any wiki authors. The other side of the problem is that, while the wiki is often cited as being ""maintained by the Go community"", many Go users treat anything under the `golang/go` repository as being blessed by the Go team. This is an understandable misconception, as the repository is otherwise under the team's supervision. Finally, there is https://groups.google.com/forum/#!forum/golang-wikichanges, but that's a system that requires lots of active attention and ultimately isn't as effective as code review. As an example, the Modules page was deleted on August 26th, so the page was gone until someone noticed and reverted the edit. ### Proposed solution Important documentation should go through the review process, just like code and godoc changes do. There's currently no way to do that with GitHub Wikis. I propose the following steps: 1) Announce the plan below to golang-dev and golang-nuts, and update the main wiki page 2) Gradually move relevant wiki pages somewhere under Gerrit, such as an `x/doc` or `x/wiki` repository 3) Start making these pages available somewhere official, such as under golang.org/doc or golang.org/wiki 4) Modify the moved Wiki pages to link or redirect to their new locations",1,proposal move mature wiki content behind gerrit summary the has over pages and a set of rules that aren t being followed there also isn t an effective review process in place as we explain further below i propose that we move the mature content behind gerrit to better ensure its quality and maintainability and so that it can be blessed without fear of uncontrolled edits this proposal does not cover what to do with the rest of the wiki content or what to do with the existing wiki itself that is left for another proposal to tackle problem statement it s only possible to have go s wiki the go project opted for anyone to edit them this has the advantage that the barrier to entry is low however this also means that there s no review process involved and anyone can create a new wiki page at any time the main wiki page reads this wiki is open to editing by any member of the go community with a github account if you would like to add a new page please first open an issue in the please open an issue before renaming or removing any wiki page however it doesn t look like the process to add new pages works with pages i could only find about a dozen issues requesting the addition of a new wiki page after a five minute search with queries like is issue wiki page in title the quality of the pages also varies greatly some of them were written or maintained by the go team such as and these are well reviewed and are often considered blessed by the go project on the other hand many others have never been approved by a go issue and have gone through no proper reviews anywhere public note that i m not attaching any examples here to not point any fingers at any wiki authors the other side of the problem is that while the wiki is often cited as being maintained by the go community many go users treat anything under the golang go repository as being blessed by the go team this is an understandable misconception as the repository is otherwise under the team s supervision finally there is but that s a system that requires lots of active attention and ultimately isn t as effective as code review as an example the modules page was deleted on august so the page was gone until someone noticed and reverted the edit proposed solution important documentation should go through the review process just like code and godoc changes do there s currently no way to do that with github wikis i propose the following steps announce the plan below to golang dev and golang nuts and update the main wiki page gradually move relevant wiki pages somewhere under gerrit such as an x doc or x wiki repository start making these pages available somewhere official such as under golang org doc or golang org wiki modify the moved wiki pages to link or redirect to their new locations,1 196894,15613232927.0,IssuesEvent,2021-03-19 16:12:29,golang/go,https://api.github.com/repos/golang/go,closed,"net/http: mention Context and Client.Do in docs for Get, Head, Post, PostForm",Documentation Proposal Proposal-Accepted,"The documentation for `Client.Do` says ""Generally Get, Post, or PostForm will be used instead of Do."" However, there is no way to pass a `context.Context` into those methods, so we cannot, for example, set a per-request timeout without resorting to `Do`. I propose adding the following new methods to `http.Client`. - `GetContext(ctx context.Context, url string) (resp *Response, err error)` - `HeadContext(ctx context.Context, url string) (resp *Response, err error)` - `PostContext(ctx context.Context, url, contentType string, body io.Reader) (resp *Response, err error)` - `PostFormContext(ctx context.Context, url string, data url.Values) (resp *Response, err error)` This would effectively deprecate the existing `Get`, `Head`, `Post`, and `PostForm` methods. We should also make a corresponding global function for each of these, and deprecate the existing `http.Get`, `http.Head`, `http.Post`, and `http.PostForm` functions.",1.0,"net/http: mention Context and Client.Do in docs for Get, Head, Post, PostForm - The documentation for `Client.Do` says ""Generally Get, Post, or PostForm will be used instead of Do."" However, there is no way to pass a `context.Context` into those methods, so we cannot, for example, set a per-request timeout without resorting to `Do`. I propose adding the following new methods to `http.Client`. - `GetContext(ctx context.Context, url string) (resp *Response, err error)` - `HeadContext(ctx context.Context, url string) (resp *Response, err error)` - `PostContext(ctx context.Context, url, contentType string, body io.Reader) (resp *Response, err error)` - `PostFormContext(ctx context.Context, url string, data url.Values) (resp *Response, err error)` This would effectively deprecate the existing `Get`, `Head`, `Post`, and `PostForm` methods. We should also make a corresponding global function for each of these, and deprecate the existing `http.Get`, `http.Head`, `http.Post`, and `http.PostForm` functions.",1,net http mention context and client do in docs for get head post postform the documentation for client do says generally get post or postform will be used instead of do however there is no way to pass a context context into those methods so we cannot for example set a per request timeout without resorting to do i propose adding the following new methods to http client getcontext ctx context context url string resp response err error headcontext ctx context context url string resp response err error postcontext ctx context context url contenttype string body io reader resp response err error postformcontext ctx context context url string data url values resp response err error this would effectively deprecate the existing get head post and postform methods we should also make a corresponding global function for each of these and deprecate the existing http get http head http post and http postform functions ,1 52639,7778063040.0,IssuesEvent,2018-06-05 13:13:03,golang/go,https://api.github.com/repos/golang/go,closed,"doc: non-standard ""usage"" in flag package",Documentation NeedsFix help wanted,"flag is the only non-main package in the standard library whose documentation begins with: > Usage:",1.0,"doc: non-standard ""usage"" in flag package - flag is the only non-main package in the standard library whose documentation begins with: > Usage:",1,doc non standard usage in flag package flag is the only non main package in the standard library whose documentation begins with usage ,1 57503,14138028571.0,IssuesEvent,2020-11-10 07:45:13,golang/go,https://api.github.com/repos/golang/go,closed,x/build: aix/ppc64 maintenance on 9 November,Builders NeedsFix,"The aix/ppc64 builder will have a maintenance starting at 0070 GMT on 9 November. It should be down for the whole day. Thanks",1.0,"x/build: aix/ppc64 maintenance on 9 November - The aix/ppc64 builder will have a maintenance starting at 0070 GMT on 9 November. It should be down for the whole day. Thanks",0,x build aix maintenance on november the aix builder will have a maintenance starting at gmt on november it should be down for the whole day thanks,0 220015,16869414132.0,IssuesEvent,2021-06-22 00:51:19,golang/go,https://api.github.com/repos/golang/go,closed,"text/template: doc: `define` action is not listed and described in ""Actions"" section",Documentation NeedsDecision," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you expect to see? In text/template [doc page](https://golang.org/pkg/text/template/), `define` action should be officially listed in 'Actions' section. ### What did you see instead? In text/template [doc page](https://golang.org/pkg/text/template/), `define` action is described in a separate section, named [""Nested template definitions""](https://golang.org/pkg/text/template/#hdr-Nested_template_definitions), however, as an action, it's not listed in the [""Actions""](https://golang.org/pkg/text/template/#hdr-Actions) section as other actions do. It should also be there. ",1.0,"text/template: doc: `define` action is not listed and described in ""Actions"" section - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you expect to see? In text/template [doc page](https://golang.org/pkg/text/template/), `define` action should be officially listed in 'Actions' section. ### What did you see instead? In text/template [doc page](https://golang.org/pkg/text/template/), `define` action is described in a separate section, named [""Nested template definitions""](https://golang.org/pkg/text/template/#hdr-Nested_template_definitions), however, as an action, it's not listed in the [""Actions""](https://golang.org/pkg/text/template/#hdr-Actions) section as other actions do. It should also be there. ",1,text template doc define action is not listed and described in actions section please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what did you expect to see in text template define action should be officially listed in actions section what did you see instead in text template define action is described in a separate section named however as an action it s not listed in the section as other actions do it should also be there ,1 70967,18358511454.0,IssuesEvent,2021-10-08 22:28:45,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/coordinator: some subrepos want to run tests in both module and GOPATH modes,Testing Builders NeedsDecision FeatureRequest,"coordinator already had support for running tests (at least trybots) in module mode, it's used for `oauth2` and `build` subrepos: https://github.com/golang/build/blob/34b995b40b0d31f2760a2f57b9ce74e17925702c/cmd/coordinator/coordinator.go#L2506-L2507 Some subrepos, such as x/tools, may want to soon start running their tests in both `GO111MODULE=on` and `GO111MODULE=off` modes, in order to make sure there are no regressions in either mode. We should add support for this to the coordinator. /cc @bradfitz @matloob",1.0,"x/build/cmd/coordinator: some subrepos want to run tests in both module and GOPATH modes - coordinator already had support for running tests (at least trybots) in module mode, it's used for `oauth2` and `build` subrepos: https://github.com/golang/build/blob/34b995b40b0d31f2760a2f57b9ce74e17925702c/cmd/coordinator/coordinator.go#L2506-L2507 Some subrepos, such as x/tools, may want to soon start running their tests in both `GO111MODULE=on` and `GO111MODULE=off` modes, in order to make sure there are no regressions in either mode. We should add support for this to the coordinator. /cc @bradfitz @matloob",0,x build cmd coordinator some subrepos want to run tests in both module and gopath modes coordinator already had support for running tests at least trybots in module mode it s used for and build subrepos some subrepos such as x tools may want to soon start running their tests in both on and off modes in order to make sure there are no regressions in either mode we should add support for this to the coordinator cc bradfitz matloob,0 140322,12891489221.0,IssuesEvent,2020-07-13 17:49:45,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: include GOMODCACHE in documented list of environment variables,Documentation NeedsFix release-blocker,"Go 1.15 adds the `GOMODCACHE` environment variable (#34527). It's mentioned in the release notes ([CL 230537](https://golang.org/cl/230537)). Should it also be included in the list at https://tip.golang.org/cmd/go/#hdr-Environment_variables? /cc @jayconrod @matloob @bcmills",1.0,"cmd/go: include GOMODCACHE in documented list of environment variables - Go 1.15 adds the `GOMODCACHE` environment variable (#34527). It's mentioned in the release notes ([CL 230537](https://golang.org/cl/230537)). Should it also be included in the list at https://tip.golang.org/cmd/go/#hdr-Environment_variables? /cc @jayconrod @matloob @bcmills",1,cmd go include gomodcache in documented list of environment variables go adds the gomodcache environment variable it s mentioned in the release notes should it also be included in the list at cc jayconrod matloob bcmills,1 47630,7334666905.0,IssuesEvent,2018-03-05 23:48:40,golang/go,https://api.github.com/repos/golang/go,closed,os/exec: document that you must call Wait before accessing copied output,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? go version go1.10 linux/amd64 ### Does this issue reproduce with the latest release? The bug does not appear in 1.9.4, therefore it seems to be a regression in 1.10. ### What operating system and processor architecture are you using (`go env`)? 
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/howard/.cache/go-build""
GOEXE=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/howard/gopath""
GORACE=""""
GOROOT=""/home/howard/go""
GOTMPDIR=""""
GOTOOLDIR=""/home/howard/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
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-build479455967=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Run the following piece of code: 
package main

import (
	""os/exec""
	""bytes""
	""time""
	""fmt""
)

func main() {
	c := exec.Command(""/bin/bash"", ""-c"", ""echo abc && sleep 10"")
	var outBuf bytes.Buffer
	c.Stdout = &outBuf

	if err := c.Start(); err != nil {
		panic(err)
	}

	time.Sleep(3 * time.Second)
	if err := c.Process.Kill(); err != nil {
		panic(err)
	}

	fmt.Println(outBuf.Bytes())
}
Using previous go 1.9.4, the output correctly shows individual bytes in string `abc\n`: [97 98 99 10] However, using go 1.10, the output shows: [97 98 99 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] Oddly, if the bash command does not say `&& sleep 10`, which means the bash program exits normally before it is killed, both 1.10 and 1.9.4 will collect the correct output `[97 98 99 10]`. This is potentially a regression in 1.10. ",1.0,"os/exec: document that you must call Wait before accessing copied output - ### What version of Go are you using (`go version`)? go version go1.10 linux/amd64 ### Does this issue reproduce with the latest release? The bug does not appear in 1.9.4, therefore it seems to be a regression in 1.10. ### What operating system and processor architecture are you using (`go env`)? 
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/howard/.cache/go-build""
GOEXE=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/howard/gopath""
GORACE=""""
GOROOT=""/home/howard/go""
GOTMPDIR=""""
GOTOOLDIR=""/home/howard/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
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-build479455967=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Run the following piece of code: 
package main

import (
	""os/exec""
	""bytes""
	""time""
	""fmt""
)

func main() {
	c := exec.Command(""/bin/bash"", ""-c"", ""echo abc && sleep 10"")
	var outBuf bytes.Buffer
	c.Stdout = &outBuf

	if err := c.Start(); err != nil {
		panic(err)
	}

	time.Sleep(3 * time.Second)
	if err := c.Process.Kill(); err != nil {
		panic(err)
	}

	fmt.Println(outBuf.Bytes())
}
Using previous go 1.9.4, the output correctly shows individual bytes in string `abc\n`: [97 98 99 10] However, using go 1.10, the output shows: [97 98 99 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] Oddly, if the bash command does not say `&& sleep 10`, which means the bash program exits normally before it is killed, both 1.10 and 1.9.4 will collect the correct output `[97 98 99 10]`. This is potentially a regression in 1.10. ",1,os exec document that you must call wait before accessing copied output what version of go are you using go version go version linux does this issue reproduce with the latest release the bug does not appear in therefore it seems to be a regression in what operating system and processor architecture are you using go env goarch gobin gocache home howard cache go build goexe gohostarch gohostos linux goos linux gopath home howard gopath gorace goroot home howard go gotmpdir gotooldir home howard go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do run the following piece of code package main import os exec bytes time fmt func main c exec command bin bash c echo abc sleep var outbuf bytes buffer c stdout outbuf if err c start err nil panic err time sleep time second if err c process kill err nil panic err fmt println outbuf bytes using previous go the output correctly shows individual bytes in string abc n however using go the output shows oddly if the bash command does not say sleep which means the bash program exits normally before it is killed both and will collect the correct output this is potentially a regression in ,1 250420,27086629169.0,IssuesEvent,2023-02-14 17:27:22,golang/go,https://api.github.com/repos/golang/go,closed,security: fix CVE-2022-41722 [1.19 backport],Security CherryPickApproved,"@neild requested issue #57274 to be considered for backport to the next 1.19 minor release. > @gopherbot please open backport issues. This is a security fix. ",True,"security: fix CVE-2022-41722 [1.19 backport] - @neild requested issue #57274 to be considered for backport to the next 1.19 minor release. > @gopherbot please open backport issues. This is a security fix. ",0,security fix cve neild requested issue to be considered for backport to the next minor release gopherbot please open backport issues this is a security fix ,0 102258,11278105354.0,IssuesEvent,2020-01-15 05:33:39,golang/go,https://api.github.com/repos/golang/go,closed,"doc: go-spec.html missing space before . on line 2416, OperandName = identifier | QualifiedIdent.",Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
go 1.13.5

(line 2416 is as of current master)
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/user2/Library/Caches/go-build""
GOENV=""/Users/user2/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/user2/A/AL3/code/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=""""
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/8v/vpckwgfs4_547sb94qr9f4d40000gq/T/go-build564981435=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? ### What did you expect to see? ""OperandName = identifier | QualifiedIdent ."" ### What did you see instead? ""OperandName = identifier | QualifiedIdent."" ",1.0,"doc: go-spec.html missing space before . on line 2416, OperandName = identifier | QualifiedIdent. - ### What version of Go are you using (`go version`)? 
go 1.13.5

(line 2416 is as of current master)
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env

GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/user2/Library/Caches/go-build""
GOENV=""/Users/user2/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/user2/A/AL3/code/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=""""
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/8v/vpckwgfs4_547sb94qr9f4d40000gq/T/go-build564981435=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? ### What did you expect to see? ""OperandName = identifier | QualifiedIdent ."" ### What did you see instead? ""OperandName = identifier | QualifiedIdent."" ",1,doc go spec html missing space before on line operandname identifier qualifiedident please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go line is as of current master does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users library caches go build goenv users library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users a code go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do extracted grammar production rules from go spec html to find erroneous line search for operandname identifier qualifiedident what did you expect to see operandname identifier qualifiedident what did you see instead operandname identifier qualifiedident ,1 21949,4759722823.0,IssuesEvent,2016-10-24 23:44:23,golang/go,https://api.github.com/repos/golang/go,closed,proposal: freeze more packages,Documentation Proposal,"I'd like to freeze some packages for Go 1.7: * net/rpc (#16844) * log/syslog (done in ddc25081d24d62ebf37e737b73b8bad8fd4b50ec) * testing/quick * net/smtp (done in 883e128f4571a59842e1156b5ebe25d8420162d9) * text/tabwriter I want to place a line at the end of their package docs saying ""This package is frozen. It is retained for compatibility with the Go 1 API promise. See https://golang.org/s/frozen-package for details."" And then at that URL we can spell out the rules more. (e.g. maybe we'll accept actual bug fixes if they're obviously wrong and don't change buggy behavior that people might depend on) /cc @adg @rsc @ianlancetaylor ",1.0,"proposal: freeze more packages - I'd like to freeze some packages for Go 1.7: * net/rpc (#16844) * log/syslog (done in ddc25081d24d62ebf37e737b73b8bad8fd4b50ec) * testing/quick * net/smtp (done in 883e128f4571a59842e1156b5ebe25d8420162d9) * text/tabwriter I want to place a line at the end of their package docs saying ""This package is frozen. It is retained for compatibility with the Go 1 API promise. See https://golang.org/s/frozen-package for details."" And then at that URL we can spell out the rules more. (e.g. maybe we'll accept actual bug fixes if they're obviously wrong and don't change buggy behavior that people might depend on) /cc @adg @rsc @ianlancetaylor ",1,proposal freeze more packages i d like to freeze some packages for go net rpc log syslog done in testing quick net smtp done in text tabwriter i want to place a line at the end of their package docs saying this package is frozen it is retained for compatibility with the go api promise see for details and then at that url we can spell out the rules more e g maybe we ll accept actual bug fixes if they re obviously wrong and don t change buggy behavior that people might depend on cc adg rsc ianlancetaylor ,1 34193,9304219524.0,IssuesEvent,2019-03-24 23:26:22,golang/go,https://api.github.com/repos/golang/go,closed,x/build: Dragonfly builder is failing to remove workdir,Builders NeedsFix OS-Dragonfly," ### What version of Go are you using (`go version`)? 
go version go1.11.4 dragonfly/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
amd64
When the builder tries to remove the existing /tmp workdir, this happens: 2019/03/14 20:05:58 buildlet starting. 2019/03/14 20:05:58 remove /tmp/workdir-host-dragonfly-amd64-tdfbsd/tmp/TestSimpleCases_import_grouping_not_path_dependent_no_groups_Modules_GoPackages625130825/modcache/pkg/mod/github.com/local@v1.0.0/go.mod: permission denied ^C % ls -l /tmp/workdir-host-dragonfly-amd64-tdfbsd/tmp/TestSimpleCases_import_grouping_not_path_dependent_no_groups_Modules_GoPackages625130825/modcache/pkg/mod/github.com/local@v1.0.0/ total 16 dr-xr-xr-x 2 tim wheel 88 Mar 14 16:04 bar -r--r--r-- 1 tim wheel 24 Mar 14 16:04 go.mod So, the direct cause is that go.mod is being created with read-only permissions. I have no idea when this started happening though, or why. ",1.0,"x/build: Dragonfly builder is failing to remove workdir - ### What version of Go are you using (`go version`)? 
go version go1.11.4 dragonfly/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
amd64
When the builder tries to remove the existing /tmp workdir, this happens: 2019/03/14 20:05:58 buildlet starting. 2019/03/14 20:05:58 remove /tmp/workdir-host-dragonfly-amd64-tdfbsd/tmp/TestSimpleCases_import_grouping_not_path_dependent_no_groups_Modules_GoPackages625130825/modcache/pkg/mod/github.com/local@v1.0.0/go.mod: permission denied ^C % ls -l /tmp/workdir-host-dragonfly-amd64-tdfbsd/tmp/TestSimpleCases_import_grouping_not_path_dependent_no_groups_Modules_GoPackages625130825/modcache/pkg/mod/github.com/local@v1.0.0/ total 16 dr-xr-xr-x 2 tim wheel 88 Mar 14 16:04 bar -r--r--r-- 1 tim wheel 24 Mar 14 16:04 go.mod So, the direct cause is that go.mod is being created with read-only permissions. I have no idea when this started happening though, or why. ",0,x build dragonfly builder is failing to remove workdir what version of go are you using go version go version dragonfly does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output when the builder tries to remove the existing tmp workdir this happens buildlet starting remove tmp workdir host dragonfly tdfbsd tmp testsimplecases import grouping not path dependent no groups modules modcache pkg mod github com local go mod permission denied c ls l tmp workdir host dragonfly tdfbsd tmp testsimplecases import grouping not path dependent no groups modules modcache pkg mod github com local total dr xr xr x tim wheel mar bar r r r tim wheel mar go mod so the direct cause is that go mod is being created with read only permissions i have no idea when this started happening though or why ,0 15940,9178859996.0,IssuesEvent,2019-03-05 00:42:48,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: teach prove about min,NeedsFix Performance,"```go package p func f(x, y []int) { n := len(x) if len(y) < n { n = len(y) } for i := 0; i < n; i++ { _ = x[i] _ = y[i] } } ``` Ideally there would be no bounds checks in the loop. Right now there are. This grew out of a conversation in CL 164966. cc @rasky @aclements @zdjones ",True,"cmd/compile: teach prove about min - ```go package p func f(x, y []int) { n := len(x) if len(y) < n { n = len(y) } for i := 0; i < n; i++ { _ = x[i] _ = y[i] } } ``` Ideally there would be no bounds checks in the loop. Right now there are. This grew out of a conversation in CL 164966. cc @rasky @aclements @zdjones ",0,cmd compile teach prove about min go package p func f x y int n len x if len y n n len y for i i n i x y ideally there would be no bounds checks in the loop right now there are this grew out of a conversation in cl cc rasky aclements zdjones ,0 32478,6066472957.0,IssuesEvent,2017-06-14 18:34:04,golang/go,https://api.github.com/repos/golang/go,closed,sync: confusing documentation for RWMutex,Documentation NeedsFix,"[sync#RWMutex](https://golang.org/pkg/sync/#RWMutex) > An RWMutex is a reader/writer mutual exclusion lock. The lock can be held by an arbitrary number of readers or a single writer. RWMutexes can be created as part of other structures; the zero value for a RWMutex is an unlocked mutex. > >An RWMutex must not be copied after first use. > >If a goroutine holds a RWMutex for reading, it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock. The third paragraph ""_If a goroutine holds a RWMutex for reading, it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released._"" appears to contradict the first paragraph ""_The lock can be held by an arbitrary number of readers or a single writer._"" After reading #7576 I think I understand this to mean that subsequent calls to `RWMutex.RLock()` will block if a call to `RWMutex.Lock()` has taken place (even if the write lock is currently not held), however that is not apparent from the rest of the documentation. If this is the case can the forward for `RWLock` and the documentation for `RWLock.RLock` be updated to match please?",1.0,"sync: confusing documentation for RWMutex - [sync#RWMutex](https://golang.org/pkg/sync/#RWMutex) > An RWMutex is a reader/writer mutual exclusion lock. The lock can be held by an arbitrary number of readers or a single writer. RWMutexes can be created as part of other structures; the zero value for a RWMutex is an unlocked mutex. > >An RWMutex must not be copied after first use. > >If a goroutine holds a RWMutex for reading, it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock. The third paragraph ""_If a goroutine holds a RWMutex for reading, it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released._"" appears to contradict the first paragraph ""_The lock can be held by an arbitrary number of readers or a single writer._"" After reading #7576 I think I understand this to mean that subsequent calls to `RWMutex.RLock()` will block if a call to `RWMutex.Lock()` has taken place (even if the write lock is currently not held), however that is not apparent from the rest of the documentation. If this is the case can the forward for `RWLock` and the documentation for `RWLock.RLock` be updated to match please?",1,sync confusing documentation for rwmutex an rwmutex is a reader writer mutual exclusion lock the lock can be held by an arbitrary number of readers or a single writer rwmutexes can be created as part of other structures the zero value for a rwmutex is an unlocked mutex an rwmutex must not be copied after first use if a goroutine holds a rwmutex for reading it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released in particular this prohibits recursive read locking this is to ensure that the lock eventually becomes available a blocked lock call excludes new readers from acquiring the lock the third paragraph if a goroutine holds a rwmutex for reading it must not expect this or any other goroutine to be able to also take the read lock until the first read lock is released appears to contradict the first paragraph the lock can be held by an arbitrary number of readers or a single writer after reading i think i understand this to mean that subsequent calls to rwmutex rlock will block if a call to rwmutex lock has taken place even if the write lock is currently not held however that is not apparent from the rest of the documentation if this is the case can the forward for rwlock and the documentation for rwlock rlock be updated to match please ,1 79149,7697414068.0,IssuesEvent,2018-05-18 18:41:21,golang/go,https://api.github.com/repos/golang/go,opened,dev.boringcrypto: failing cmd/link/internal/ld test,NeedsFix Testing,"``` 0xe6f2: Subprogram at=AbstractOrigin val=0x1273d4 at=Lowpc val=0x618bc0 at=Highpc val=0x618c27 at=FrameBase val=0x9c --- FAIL: TestAbstractOriginSanity (10.00s) dwarf_test.go:770: unresolved abstract origin ref in DIE at offset 135569 0xe6f2: Subprogram at=AbstractOrigin val=0x1273d4 at=Lowpc val=0x618bc0 at=Highpc val=0x618c27 at=FrameBase val=0x9c --- FAIL: TestAbstractOriginSanityWithLocationLists (11.76s) dwarf_test.go:770: unresolved abstract origin ref in DIE at offset 135569 FAIL FAIL cmd/link/internal/ld 27.909s ``` https://storage.googleapis.com/go-build-log/99c11019/linux-amd64_3ca200f0.log The test has been failing on the BoringCrypto branch since it was introduced in fdecaa837cf94f6679a7683c1929e3b22ab1e07d by @thanm, supposedly due to the BoringSSL syso object.",1.0,"dev.boringcrypto: failing cmd/link/internal/ld test - ``` 0xe6f2: Subprogram at=AbstractOrigin val=0x1273d4 at=Lowpc val=0x618bc0 at=Highpc val=0x618c27 at=FrameBase val=0x9c --- FAIL: TestAbstractOriginSanity (10.00s) dwarf_test.go:770: unresolved abstract origin ref in DIE at offset 135569 0xe6f2: Subprogram at=AbstractOrigin val=0x1273d4 at=Lowpc val=0x618bc0 at=Highpc val=0x618c27 at=FrameBase val=0x9c --- FAIL: TestAbstractOriginSanityWithLocationLists (11.76s) dwarf_test.go:770: unresolved abstract origin ref in DIE at offset 135569 FAIL FAIL cmd/link/internal/ld 27.909s ``` https://storage.googleapis.com/go-build-log/99c11019/linux-amd64_3ca200f0.log The test has been failing on the BoringCrypto branch since it was introduced in fdecaa837cf94f6679a7683c1929e3b22ab1e07d by @thanm, supposedly due to the BoringSSL syso object.",0,dev boringcrypto failing cmd link internal ld test subprogram at abstractorigin val at lowpc val at highpc val at framebase val fail testabstractoriginsanity dwarf test go unresolved abstract origin ref in die at offset subprogram at abstractorigin val at lowpc val at highpc val at framebase val fail testabstractoriginsanitywithlocationlists dwarf test go unresolved abstract origin ref in die at offset fail fail cmd link internal ld the test has been failing on the boringcrypto branch since it was introduced in by thanm supposedly due to the boringssl syso object ,0 21749,4744533323.0,IssuesEvent,2016-10-21 01:36:27,golang/go,https://api.github.com/repos/golang/go,closed,"unsafe: clarify what ""equivalent memory layout"" means",Documentation NeedsDecision,"One of package unsafe's valid patterns is: > (1) Conversion of a *T1 to Pointer to *T2. > > Provided that T2 is no larger than T1 and that the two share an equivalent memory layout, this conversion allows reinterpreting data of one type as data of another type. There have been arguments about what ""equivalent memory layout"" means (e.g., #16769, and the [""Guarantees for package unsafe""](https://groups.google.com/forum/#!topic/golang-dev/uCP4P12xS9Y) thread on golang-dev). E.g., in C/C++, it's valid to cast from a pointer to a struct to a pointer to another struct containing a prefix of the fields to support things like casting from `struct sockaddr_in *` to `struct sockaddr *`. But package unsafe gives an example of converting from `*float64` to `*uint64`, which wouldn't be valid in C/C++. In [crypto/md5](https://github.com/golang/go/blob/master/src/crypto/md5/md5block.go#L41), there's code that converts `&p[0]` (of type `*byte`) to `*[16]uint32`, after verifying `len(p) >= 48`. Assuming we think this should remain valid, that seems to suggest it's okay to convert `*[4]byte` to `*uint32`; i.e., that primitive data types need not exactly match in size either. * Aside: Technically this conversion isn't protected by rule 1 anyway, because T2 (`[16]uint32`) is larger than T1 (`byte`), but I think it's arguably within the spirit of the rule because of the length check. My understanding of the phrase's intent was to disallow accessing pointer slots as non-pointer types. E.g., you can't convert from `**int` to `*uintptr`, even though sizeof(`*int`) == sizeof(`uintptr`). @dr2chase suggested that it could be interpreted to imply sensitivity to the machine's endianness, which may disallow converting `*uint64` to `*uint16`. In https://go-review.googlesource.com/#/c/18640/ this wording was discussed: > @alandonovan: Is ""equivalent memory layout"" defined anywhere? > @rsc: No, but I'd rather not. I'm trying to write useful text without writing a legal document. I hope people can at least understand memory layouts and whether the conversion they want makes sense. If not they probably shouldn't be using unsafe. Unfortunately it seems even within the Go compiler team there's disagreement/uncertainty on what ""equivalent memory layout"" means, even for concrete examples like converting `*uint64` to `*uint16`. /cc @ianlancetaylor @randall77 ",1.0,"unsafe: clarify what ""equivalent memory layout"" means - One of package unsafe's valid patterns is: > (1) Conversion of a *T1 to Pointer to *T2. > > Provided that T2 is no larger than T1 and that the two share an equivalent memory layout, this conversion allows reinterpreting data of one type as data of another type. There have been arguments about what ""equivalent memory layout"" means (e.g., #16769, and the [""Guarantees for package unsafe""](https://groups.google.com/forum/#!topic/golang-dev/uCP4P12xS9Y) thread on golang-dev). E.g., in C/C++, it's valid to cast from a pointer to a struct to a pointer to another struct containing a prefix of the fields to support things like casting from `struct sockaddr_in *` to `struct sockaddr *`. But package unsafe gives an example of converting from `*float64` to `*uint64`, which wouldn't be valid in C/C++. In [crypto/md5](https://github.com/golang/go/blob/master/src/crypto/md5/md5block.go#L41), there's code that converts `&p[0]` (of type `*byte`) to `*[16]uint32`, after verifying `len(p) >= 48`. Assuming we think this should remain valid, that seems to suggest it's okay to convert `*[4]byte` to `*uint32`; i.e., that primitive data types need not exactly match in size either. * Aside: Technically this conversion isn't protected by rule 1 anyway, because T2 (`[16]uint32`) is larger than T1 (`byte`), but I think it's arguably within the spirit of the rule because of the length check. My understanding of the phrase's intent was to disallow accessing pointer slots as non-pointer types. E.g., you can't convert from `**int` to `*uintptr`, even though sizeof(`*int`) == sizeof(`uintptr`). @dr2chase suggested that it could be interpreted to imply sensitivity to the machine's endianness, which may disallow converting `*uint64` to `*uint16`. In https://go-review.googlesource.com/#/c/18640/ this wording was discussed: > @alandonovan: Is ""equivalent memory layout"" defined anywhere? > @rsc: No, but I'd rather not. I'm trying to write useful text without writing a legal document. I hope people can at least understand memory layouts and whether the conversion they want makes sense. If not they probably shouldn't be using unsafe. Unfortunately it seems even within the Go compiler team there's disagreement/uncertainty on what ""equivalent memory layout"" means, even for concrete examples like converting `*uint64` to `*uint16`. /cc @ianlancetaylor @randall77 ",1,unsafe clarify what equivalent memory layout means one of package unsafe s valid patterns is conversion of a to pointer to provided that is no larger than and that the two share an equivalent memory layout this conversion allows reinterpreting data of one type as data of another type there have been arguments about what equivalent memory layout means e g and the thread on golang dev e g in c c it s valid to cast from a pointer to a struct to a pointer to another struct containing a prefix of the fields to support things like casting from struct sockaddr in to struct sockaddr but package unsafe gives an example of converting from to which wouldn t be valid in c c in there s code that converts p of type byte to after verifying len p assuming we think this should remain valid that seems to suggest it s okay to convert byte to i e that primitive data types need not exactly match in size either aside technically this conversion isn t protected by rule anyway because is larger than byte but i think it s arguably within the spirit of the rule because of the length check my understanding of the phrase s intent was to disallow accessing pointer slots as non pointer types e g you can t convert from int to uintptr even though sizeof int sizeof uintptr suggested that it could be interpreted to imply sensitivity to the machine s endianness which may disallow converting to in this wording was discussed alandonovan is equivalent memory layout defined anywhere rsc no but i d rather not i m trying to write useful text without writing a legal document i hope people can at least understand memory layouts and whether the conversion they want makes sense if not they probably shouldn t be using unsafe unfortunately it seems even within the go compiler team there s disagreement uncertainty on what equivalent memory layout means even for concrete examples like converting to cc ianlancetaylor ,1 57626,14175062501.0,IssuesEvent,2020-11-12 20:56:43,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: arbitrary code can be injected into cgo generated files [Go 1.15],CherryPickApproved Security,"The go command may execute arbitrary code at build time when cgo is in use. This may occur when running go get on a malicious package, or any other command that builds untrusted code. This can be caused by malicious unquoted symbol names. This has been fixed by rejecting invalid symbols which may add a //go:cgo_ldflag directive to the generated file, and by ensuring that the go tool follows existing LDFLAG restrictions. Thanks to Chris Brown and Tempus Ex for reporting this issue. This issue is CVE-2020-28366.",True,"cmd/go: arbitrary code can be injected into cgo generated files [Go 1.15] - The go command may execute arbitrary code at build time when cgo is in use. This may occur when running go get on a malicious package, or any other command that builds untrusted code. This can be caused by malicious unquoted symbol names. This has been fixed by rejecting invalid symbols which may add a //go:cgo_ldflag directive to the generated file, and by ensuring that the go tool follows existing LDFLAG restrictions. Thanks to Chris Brown and Tempus Ex for reporting this issue. This issue is CVE-2020-28366.",0,cmd go arbitrary code can be injected into cgo generated files the go command may execute arbitrary code at build time when cgo is in use this may occur when running go get on a malicious package or any other command that builds untrusted code this can be caused by malicious unquoted symbol names this has been fixed by rejecting invalid symbols which may add a go cgo ldflag directive to the generated file and by ensuring that the go tool follows existing ldflag restrictions thanks to chris brown and tempus ex for reporting this issue this issue is cve ,0 56236,8058588986.0,IssuesEvent,2018-08-02 18:58:19,golang/go,https://api.github.com/repos/golang/go,closed,doc: Contribution guidelines should specify git origin,Documentation,"I'm creating a duplicate of issue #10130, which was IMHO wrongly closed and then frozen. The contributing guide as it stands leaves out a key piece of information about how to contribute. Hunting around for it on the web isn't better than having it in the guide, even if including it makes the guide slightly more verbose. Here is the text of the original issue, as valid now as when it was originally reported: ""The contribution guidelines don't mention that git origin should be https://go.googlesource.com/go. git-codereview: git origin must be a Gerrit host, not GitHub: https://github.com/golang/go.git"" ",1.0,"doc: Contribution guidelines should specify git origin - I'm creating a duplicate of issue #10130, which was IMHO wrongly closed and then frozen. The contributing guide as it stands leaves out a key piece of information about how to contribute. Hunting around for it on the web isn't better than having it in the guide, even if including it makes the guide slightly more verbose. Here is the text of the original issue, as valid now as when it was originally reported: ""The contribution guidelines don't mention that git origin should be https://go.googlesource.com/go. git-codereview: git origin must be a Gerrit host, not GitHub: https://github.com/golang/go.git"" ",1,doc contribution guidelines should specify git origin i m creating a duplicate of issue which was imho wrongly closed and then frozen the contributing guide as it stands leaves out a key piece of information about how to contribute hunting around for it on the web isn t better than having it in the guide even if including it makes the guide slightly more verbose here is the text of the original issue as valid now as when it was originally reported the contribution guidelines don t mention that git origin should be git codereview git origin must be a gerrit host not github ,1 39259,10320509961.0,IssuesEvent,2019-08-30 20:45:21,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/coordinator: TestForeachLineAllocs fails after builders deployed,Builders NeedsFix,"While testing if #33928 was resolved, the `cmd/coordinator/status_test.go:TestForEachLineAllocs` test started failing with significantly more allocs than the threshold. From: https://go-review.googlesource.com/c/build/+/192103/1#message-cfc755e443676448b10e0301816edb916bd386ac > 5 of 9 TryBots failed: > Failed on linux-amd64: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-amd64_b554d822.log > Failed on linux-386: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-386_bdf42483.log > Failed on linux-amd64 (Go 1.11.x): https://storage.googleapis.com/go-build-log/83bd8812/linux-amd64_551b9063.log > Failed on linux-amd64 (Go 1.12.x): https://storage.googleapis.com/go-build-log/61a5d114/linux-amd64_e60c908d.log > Failed on linux-amd64-race: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-amd64-race_e318c3fa.log ``` 2019/08/29 17:09:48 Starting new trybot set for {build master I6f05da2186b38dc8056081252563a82c50f0ce05 a62e6a3ab11cc9cc2d9e22a50025dd33fc35d22f} --- FAIL: TestForeachLineAllocs (0.21s) status_test.go:118: allocs = 220 FAIL ``` Failing test: ```go func TestForeachLineAllocs(t *testing.T) { v := bytes.Repeat([]byte(`line 1 line 2 line 3 after two blank lines last line`), 1000) allocs := testing.AllocsPerRun(1000, func() { foreachLine(v, func([]byte) error { return nil }) }) if allocs > 0.1 { t.Errorf(""allocs = %v"", allocs) } } ``` The test in question was introduced in https://go-review.googlesource.com/c/build/+/185981. It looks like it is mistakenly expecting a non-integral value from `testing.AllocsPerRun`, which returns a `float64` that is actually always an integral value. It's still surprising that allocs would be as high as 220, as locally testing.AllocsPerRun returns 0 when I run this test on linux-amd64 go1.13rc2. I also tested on older releases of Go, and cannot reproduce this failure localy.",1.0,"x/build/cmd/coordinator: TestForeachLineAllocs fails after builders deployed - While testing if #33928 was resolved, the `cmd/coordinator/status_test.go:TestForEachLineAllocs` test started failing with significantly more allocs than the threshold. From: https://go-review.googlesource.com/c/build/+/192103/1#message-cfc755e443676448b10e0301816edb916bd386ac > 5 of 9 TryBots failed: > Failed on linux-amd64: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-amd64_b554d822.log > Failed on linux-386: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-386_bdf42483.log > Failed on linux-amd64 (Go 1.11.x): https://storage.googleapis.com/go-build-log/83bd8812/linux-amd64_551b9063.log > Failed on linux-amd64 (Go 1.12.x): https://storage.googleapis.com/go-build-log/61a5d114/linux-amd64_e60c908d.log > Failed on linux-amd64-race: https://storage.googleapis.com/go-build-log/e87fe0f1/linux-amd64-race_e318c3fa.log ``` 2019/08/29 17:09:48 Starting new trybot set for {build master I6f05da2186b38dc8056081252563a82c50f0ce05 a62e6a3ab11cc9cc2d9e22a50025dd33fc35d22f} --- FAIL: TestForeachLineAllocs (0.21s) status_test.go:118: allocs = 220 FAIL ``` Failing test: ```go func TestForeachLineAllocs(t *testing.T) { v := bytes.Repeat([]byte(`line 1 line 2 line 3 after two blank lines last line`), 1000) allocs := testing.AllocsPerRun(1000, func() { foreachLine(v, func([]byte) error { return nil }) }) if allocs > 0.1 { t.Errorf(""allocs = %v"", allocs) } } ``` The test in question was introduced in https://go-review.googlesource.com/c/build/+/185981. It looks like it is mistakenly expecting a non-integral value from `testing.AllocsPerRun`, which returns a `float64` that is actually always an integral value. It's still surprising that allocs would be as high as 220, as locally testing.AllocsPerRun returns 0 when I run this test on linux-amd64 go1.13rc2. I also tested on older releases of Go, and cannot reproduce this failure localy.",0,x build cmd coordinator testforeachlineallocs fails after builders deployed while testing if was resolved the cmd coordinator status test go testforeachlineallocs test started failing with significantly more allocs than the threshold from of trybots failed failed on linux failed on linux failed on linux go x failed on linux go x failed on linux race starting new trybot set for build master fail testforeachlineallocs status test go allocs fail failing test go func testforeachlineallocs t testing t v bytes repeat byte line line line after two blank lines last line allocs testing allocsperrun func foreachline v func byte error return nil if allocs t errorf allocs v allocs the test in question was introduced in it looks like it is mistakenly expecting a non integral value from testing allocsperrun which returns a that is actually always an integral value it s still surprising that allocs would be as high as as locally testing allocsperrun returns when i run this test on linux i also tested on older releases of go and cannot reproduce this failure localy ,0 318062,23702188462.0,IssuesEvent,2022-08-29 20:08:49,golang/go,https://api.github.com/repos/golang/go,closed,testing: mention the “_test” package idiom,Documentation NeedsFix,"https://tip.golang.org/cmd/go/#hdr-Test_packages says: > Test files that declare a package with the suffix ""_test"" will be compiled as a separate package, and then linked and run with the main test binary. However, https://tip.golang.org/pkg/testing/ omits that detail (emphasis mine): > To write a new test suite, create a file whose name ends _test.go that contains the TestXxx functions as described here. **Put the file in the same package as the one being tested.** Tests in a separate `_test` package provide more realistic examples (and are better for catching awkward [package names](https://blog.golang.org/package-names)), so it's important that users be aware of that option. The `testing` package is an important entry point for users who are new to Go: its documentation should mention both package options or neither.",1.0,"testing: mention the “_test” package idiom - https://tip.golang.org/cmd/go/#hdr-Test_packages says: > Test files that declare a package with the suffix ""_test"" will be compiled as a separate package, and then linked and run with the main test binary. However, https://tip.golang.org/pkg/testing/ omits that detail (emphasis mine): > To write a new test suite, create a file whose name ends _test.go that contains the TestXxx functions as described here. **Put the file in the same package as the one being tested.** Tests in a separate `_test` package provide more realistic examples (and are better for catching awkward [package names](https://blog.golang.org/package-names)), so it's important that users be aware of that option. The `testing` package is an important entry point for users who are new to Go: its documentation should mention both package options or neither.",1,testing mention the “ test” package idiom says test files that declare a package with the suffix test will be compiled as a separate package and then linked and run with the main test binary however omits that detail emphasis mine to write a new test suite create a file whose name ends test go that contains the testxxx functions as described here put the file in the same package as the one being tested tests in a separate test package provide more realistic examples and are better for catching awkward so it s important that users be aware of that option  the testing package is an important entry point for users who are new to go its documentation should mention both package options or neither ,1 49620,7523867906.0,IssuesEvent,2018-04-13 03:41:06,golang/go,https://api.github.com/repos/golang/go,closed,doc: go doc -c flag description unclear,Documentation,"### What version of Go are you using (`go version`)? ``` go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/will.faught/Developer/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.1/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/jt/c0hjffqj6gxbhy00gm0btzkr79h225/T/go-build727032531=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ```sh $ go doc -h ``` ### What did you see? ```output Usage of [go] doc: go doc go doc go doc [.] go doc [].[.] go doc [.] For more information run go help doc Flags: -c symbol matching honors case (paths not affected) -cmd show symbols with package docs even if package is a command -u show unexported symbols as well as exported exit status 2 ``` It isn't clear what ""symbol matching honors case (paths not affected)"" means. Go doc should be fixed to print a clearer description.",1.0,"doc: go doc -c flag description unclear - ### What version of Go are you using (`go version`)? ``` go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/will.faught/Developer/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.1/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.1/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/jt/c0hjffqj6gxbhy00gm0btzkr79h225/T/go-build727032531=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ```sh $ go doc -h ``` ### What did you see? ```output Usage of [go] doc: go doc go doc go doc [.] go doc [].[.] go doc [.] For more information run go help doc Flags: -c symbol matching honors case (paths not affected) -cmd show symbols with package docs even if package is a command -u show unexported symbols as well as exported exit status 2 ``` It isn't clear what ""symbol matching honors case (paths not affected)"" means. Go doc should be fixed to print a clearer description.",1,doc go doc c flag description unclear what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users will faught developer go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders jt t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do sh go doc h what did you see output usage of doc go doc go doc go doc go doc go doc for more information run go help doc flags c symbol matching honors case paths not affected cmd show symbols with package docs even if package is a command u show unexported symbols as well as exported exit status it isn t clear what symbol matching honors case paths not affected means go doc should be fixed to print a clearer description ,1 73037,9637101154.0,IssuesEvent,2019-05-16 07:59:48,golang/go,https://api.github.com/repos/golang/go,opened,crypto/tls: make it clear that implementation is compliant with RFC 5246,Documentation,"In #31933, @swanandt pointed out that the following note at the top of the [crypto/tls package](https://golang.org/pkg/crypto/tls/): > Package tls **partially implements** TLS 1.2, as specified in RFC 5246 may be misinterpreted as a warning about non-compliance with the RFC 5246. This is not the case, as @FiloSottile explained: > As far as I know, we implement everything that is REQUIRED by RFC 5246, so we are in full compliance with it. It may be useful to slightly change the wording of the doc to make it completely clear the only *optional* features (like DHE, topic of the discussion at #31933) are currently not implemented, and so the package is fully compliant with RFC 5246. ",1.0,"crypto/tls: make it clear that implementation is compliant with RFC 5246 - In #31933, @swanandt pointed out that the following note at the top of the [crypto/tls package](https://golang.org/pkg/crypto/tls/): > Package tls **partially implements** TLS 1.2, as specified in RFC 5246 may be misinterpreted as a warning about non-compliance with the RFC 5246. This is not the case, as @FiloSottile explained: > As far as I know, we implement everything that is REQUIRED by RFC 5246, so we are in full compliance with it. It may be useful to slightly change the wording of the doc to make it completely clear the only *optional* features (like DHE, topic of the discussion at #31933) are currently not implemented, and so the package is fully compliant with RFC 5246. ",1,crypto tls make it clear that implementation is compliant with rfc in swanandt pointed out that the following note at the top of the package tls partially implements tls as specified in rfc may be misinterpreted as a warning about non compliance with the rfc this is not the case as filosottile explained as far as i know we implement everything that is required by rfc so we are in full compliance with it it may be useful to slightly change the wording of the doc to make it completely clear the only optional features like dhe topic of the discussion at are currently not implemented and so the package is fully compliant with rfc ,1 41731,6933100544.0,IssuesEvent,2017-12-02 02:11:35,golang/go,https://api.github.com/repos/golang/go,closed,os: SetDeadline doesn't work after an Fd() call,Documentation,"### What version of Go are you using (`go version`)? go version devel +ed8b7dedd3 Thu Nov 30 01:46:50 2017 +0000 linux/amd64 ### What did you do? ``` package main import ( ""os"" ""time"" ) func main() { r, w, err := os.Pipe() if err != nil { panic(err) } println(r.Fd()) go func() { time.Sleep(time.Second*2) _, err := w.Write([]byte(""Hello, world!"")) if err != nil { panic(err) } }() err = r.SetDeadline(time.Now().Add(time.Second)) // expect an error at this line if err != nil { panic(err) } buffer := make([]byte, 16) n, err := r.Read(buffer) // or this line if err != nil { panic(err) } println(string(buffer[:n])) } ``` ### What did you expect to see? A timeout error. Or an error when `SetDeadline`. The `Fd()` can also be called after `SetDeadline()`, so a timeout error is better. ### What did you see instead? A successful Read and ""Hello, world!"". The method `Fd()` put the file descriptor into blocking mode and the deadline doesn't work after it. https://github.com/golang/go/blob/8064f82a158e4416e9f32ed7017642ace4280b4f/src/os/file_unix.go#L68 There is a similar issue with package `net`. https://github.com/golang/go/issues/21862",1.0,"os: SetDeadline doesn't work after an Fd() call - ### What version of Go are you using (`go version`)? go version devel +ed8b7dedd3 Thu Nov 30 01:46:50 2017 +0000 linux/amd64 ### What did you do? ``` package main import ( ""os"" ""time"" ) func main() { r, w, err := os.Pipe() if err != nil { panic(err) } println(r.Fd()) go func() { time.Sleep(time.Second*2) _, err := w.Write([]byte(""Hello, world!"")) if err != nil { panic(err) } }() err = r.SetDeadline(time.Now().Add(time.Second)) // expect an error at this line if err != nil { panic(err) } buffer := make([]byte, 16) n, err := r.Read(buffer) // or this line if err != nil { panic(err) } println(string(buffer[:n])) } ``` ### What did you expect to see? A timeout error. Or an error when `SetDeadline`. The `Fd()` can also be called after `SetDeadline()`, so a timeout error is better. ### What did you see instead? A successful Read and ""Hello, world!"". The method `Fd()` put the file descriptor into blocking mode and the deadline doesn't work after it. https://github.com/golang/go/blob/8064f82a158e4416e9f32ed7017642ace4280b4f/src/os/file_unix.go#L68 There is a similar issue with package `net`. https://github.com/golang/go/issues/21862",1,os setdeadline doesn t work after an fd call what version of go are you using go version go version devel thu nov linux what did you do package main import os time func main r w err os pipe if err nil panic err println r fd go func time sleep time second err w write byte hello world if err nil panic err err r setdeadline time now add time second expect an error at this line if err nil panic err buffer make byte n err r read buffer or this line if err nil panic err println string buffer what did you expect to see a timeout error or an error when setdeadline the fd can also be called after setdeadline so a timeout error is better what did you see instead a successful read and hello world the method fd put the file descriptor into blocking mode and the deadline doesn t work after it there is a similar issue with package net ,1 33834,6264055948.0,IssuesEvent,2017-07-16 03:10:42,golang/go,https://api.github.com/repos/golang/go,opened,all: add a few READMEs to help new people navigate the source tree,Documentation,"The api directory has a friendly README file in it explaining what's in it. We should add short READMEs to some of the other top-level directories, particularly doc, lib, misc, and test. ",1.0,"all: add a few READMEs to help new people navigate the source tree - The api directory has a friendly README file in it explaining what's in it. We should add short READMEs to some of the other top-level directories, particularly doc, lib, misc, and test. ",1,all add a few readmes to help new people navigate the source tree the api directory has a friendly readme file in it explaining what s in it we should add short readmes to some of the other top level directories particularly doc lib misc and test ,1 24406,5060710608.0,IssuesEvent,2016-12-22 13:05:56,golang/go,https://api.github.com/repos/golang/go,opened,wiki: document Github Issue labels,Documentation,"People don't understand the Github issue labels we use, or our general issue lifecycle. Document it. ",1.0,"wiki: document Github Issue labels - People don't understand the Github issue labels we use, or our general issue lifecycle. Document it. ",1,wiki document github issue labels people don t understand the github issue labels we use or our general issue lifecycle document it ,1 6644,3038103590.0,IssuesEvent,2015-08-06 20:37:58,golang/go,https://api.github.com/repos/golang/go,closed,"sync: docs say WaitGroup is a function, and that it panics",Documentation,"From https://tip.golang.org/doc/go1.5 -- > The WaitGroup function in package sync now diagnoses code that races a call to Add against a return from Wait. If it detects this condition, WaitGroup panics. `WaitGroup` is a type, not a function. In looking at the race-related code in the `WaitGroup.Add()` and `WaitGroup.Wait()` methods, I think this line in the docs is supposed to read more like: > sync.WaitGroup's Add method now diagnoses code that races a call to Add against a return from Wait. If it detects this condition, Add panics.",1.0,"sync: docs say WaitGroup is a function, and that it panics - From https://tip.golang.org/doc/go1.5 -- > The WaitGroup function in package sync now diagnoses code that races a call to Add against a return from Wait. If it detects this condition, WaitGroup panics. `WaitGroup` is a type, not a function. In looking at the race-related code in the `WaitGroup.Add()` and `WaitGroup.Wait()` methods, I think this line in the docs is supposed to read more like: > sync.WaitGroup's Add method now diagnoses code that races a call to Add against a return from Wait. If it detects this condition, Add panics.",1,sync docs say waitgroup is a function and that it panics from the waitgroup function in package sync now diagnoses code that races a call to add against a return from wait if it detects this condition waitgroup panics waitgroup is a type not a function in looking at the race related code in the waitgroup add and waitgroup wait methods i think this line in the docs is supposed to read more like sync waitgroup s add method now diagnoses code that races a call to add against a return from wait if it detects this condition add panics ,1 59281,8355975310.0,IssuesEvent,2018-10-02 17:08:19,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that Header.Set canonicalizes the header key,Documentation NeedsFix help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.10.3 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin, amd64 ### What did you do? https://play.golang.org/p/l-3GJBY-vWA ### What did you expect to see? Expected key to be the same string HeyHey when adding it to the http header rather then Heyhey. ### What did you see instead? Saw that after adding or setting a string to a header it does not keep the n+1 capital letter causing a check for the same key to fail. ",1.0,"net/http: document that Header.Set canonicalizes the header key - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.10.3 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? darwin, amd64 ### What did you do? https://play.golang.org/p/l-3GJBY-vWA ### What did you expect to see? Expected key to be the same string HeyHey when adding it to the http header rather then Heyhey. ### What did you see instead? Saw that after adding or setting a string to a header it does not keep the n+1 capital letter causing a check for the same key to fail. ",1,net http document that header set canonicalizes the header key please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env darwin what did you do what did you expect to see expected key to be the same string heyhey when adding it to the http header rather then heyhey what did you see instead saw that after adding or setting a string to a header it does not keep the n capital letter causing a check for the same key to fail ,1 114610,11852049517.0,IssuesEvent,2020-03-24 19:11:54,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document using 'go list' to download modules needed to build packages,Documentation NeedsFix modules,"`go list -test ./...` can be used to download the modules needed to build tests of the packages matched by `./...`. This is usually a smaller set of modules than `go mod download all` (or equivalent `go mod download`) would select, so it's a useful command when building small Docker images. This should be documented as a FAQ on https://github.com/golang/go/wiki/Modules. Related #36460: fewer modules will be downloaded by `go mod download all` when lazy module loading is implemented.",1.0,"cmd/go: document using 'go list' to download modules needed to build packages - `go list -test ./...` can be used to download the modules needed to build tests of the packages matched by `./...`. This is usually a smaller set of modules than `go mod download all` (or equivalent `go mod download`) would select, so it's a useful command when building small Docker images. This should be documented as a FAQ on https://github.com/golang/go/wiki/Modules. Related #36460: fewer modules will be downloaded by `go mod download all` when lazy module loading is implemented.",1,cmd go document using go list to download modules needed to build packages go list test can be used to download the modules needed to build tests of the packages matched by this is usually a smaller set of modules than go mod download all or equivalent go mod download would select so it s a useful command when building small docker images this should be documented as a faq on related fewer modules will be downloaded by go mod download all when lazy module loading is implemented ,1 311867,23408042280.0,IssuesEvent,2022-08-12 14:38:29,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: Update compiler phases information in README,Documentation NeedsFix,"In the latest releases of go, it seems like step 2 `Type-checking and AST transformations` is nolonger happening in `cmd/compile/internal/gc` but instead starts from `cmd/compile/internal/noder` coupled with `cmd/compile/internal/types2` I am proposing that the README is updated if necessary. ",1.0,"cmd/compile: Update compiler phases information in README - In the latest releases of go, it seems like step 2 `Type-checking and AST transformations` is nolonger happening in `cmd/compile/internal/gc` but instead starts from `cmd/compile/internal/noder` coupled with `cmd/compile/internal/types2` I am proposing that the README is updated if necessary. ",1,cmd compile update compiler phases information in readme in the latest releases of go it seems like step type checking and ast transformations is nolonger happening in cmd compile internal gc but instead starts from cmd compile internal noder coupled with cmd compile internal i am proposing that the readme is updated if necessary ,1 55324,30694332708.0,IssuesEvent,2023-07-26 17:22:00,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: regression: unnecessary spilling to the stack,Performance NeedsInvestigation compiler/runtime,"### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.21-c30faf9c54 Fri Jul 14 12:49:10 2023 +0000 linux/amd64
### Does this issue reproduce with the latest release? No. ### What operating system and processor architecture are you using (`go env`)? Linux, amd64 ### What did you do? Compile ``` func pack20(in *[20]uint64) uint64 { var out uint64 out |= 4 out |= in[0] << 4 out |= in[1] << 7 out |= in[2] << 10 out |= in[3] << 13 out |= in[4] << 16 out |= in[5] << 19 out |= in[6] << 22 out |= in[7] << 25 out |= in[8] << 28 out |= in[9] << 31 out |= in[10] << 34 out |= in[11] << 37 out |= in[12] << 40 out |= in[13] << 43 out |= in[14] << 46 out |= in[15] << 49 out |= in[16] << 52 out |= in[17] << 55 out |= in[18] << 58 out |= in[19] << 61 return out } ``` ### What did you expect to see? Output similar to that of Go 1.20.6: ``` command-line-arguments.pack20 STEXT nosplit size=233 args=0x8 locals=0x0 funcid=0x0 align=0x0 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) TEXT command-line-arguments.pack20(SB), NOSPLIT|ABIInternal, $0-8 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $0, gclocals·wgcWObbY2HYnK2SU/U22lA==(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $1, gclocals·J5F+7Qw7O7ve2QcWC7DpeQ==(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $5, command-line-arguments.pack20.arginfo1(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $6, command-line-arguments.pack20.argliveinfo(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) PCDATA $3, $1 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ (AX), CX 0x0003 00003 (/home/dominikh/prj/src/example.com/foo.go:6) SHLQ $4, CX 0x0007 00007 (/home/dominikh/prj/src/example.com/foo.go:7) MOVQ 8(AX), DX 0x000b 00011 (/home/dominikh/prj/src/example.com/foo.go:7) SHLQ $7, DX 0x000f 00015 (/home/dominikh/prj/src/example.com/foo.go:7) ORQ DX, CX 0x0012 00018 (/home/dominikh/prj/src/example.com/foo.go:8) MOVQ 16(AX), DX 0x0016 00022 (/home/dominikh/prj/src/example.com/foo.go:8) SHLQ $10, DX 0x001a 00026 (/home/dominikh/prj/src/example.com/foo.go:8) ORQ CX, DX 0x001d 00029 (/home/dominikh/prj/src/example.com/foo.go:9) MOVQ 24(AX), CX 0x0021 00033 (/home/dominikh/prj/src/example.com/foo.go:9) SHLQ $13, CX 0x0025 00037 (/home/dominikh/prj/src/example.com/foo.go:9) ORQ DX, CX 0x0028 00040 (/home/dominikh/prj/src/example.com/foo.go:10) MOVQ 32(AX), DX 0x002c 00044 (/home/dominikh/prj/src/example.com/foo.go:10) SHLQ $16, DX 0x0030 00048 (/home/dominikh/prj/src/example.com/foo.go:10) ORQ CX, DX 0x0033 00051 (/home/dominikh/prj/src/example.com/foo.go:11) MOVQ 40(AX), CX 0x0037 00055 (/home/dominikh/prj/src/example.com/foo.go:11) SHLQ $19, CX 0x003b 00059 (/home/dominikh/prj/src/example.com/foo.go:11) ORQ DX, CX 0x003e 00062 (/home/dominikh/prj/src/example.com/foo.go:12) MOVQ 48(AX), DX 0x0042 00066 (/home/dominikh/prj/src/example.com/foo.go:12) SHLQ $22, DX 0x0046 00070 (/home/dominikh/prj/src/example.com/foo.go:12) ORQ CX, DX 0x0049 00073 (/home/dominikh/prj/src/example.com/foo.go:13) MOVQ 56(AX), CX 0x004d 00077 (/home/dominikh/prj/src/example.com/foo.go:13) SHLQ $25, CX 0x0051 00081 (/home/dominikh/prj/src/example.com/foo.go:13) ORQ DX, CX 0x0054 00084 (/home/dominikh/prj/src/example.com/foo.go:14) MOVQ 64(AX), DX 0x0058 00088 (/home/dominikh/prj/src/example.com/foo.go:14) SHLQ $28, DX 0x005c 00092 (/home/dominikh/prj/src/example.com/foo.go:14) ORQ CX, DX 0x005f 00095 (/home/dominikh/prj/src/example.com/foo.go:15) MOVQ 72(AX), CX 0x0063 00099 (/home/dominikh/prj/src/example.com/foo.go:15) SHLQ $31, CX 0x0067 00103 (/home/dominikh/prj/src/example.com/foo.go:15) ORQ DX, CX 0x006a 00106 (/home/dominikh/prj/src/example.com/foo.go:16) MOVQ 80(AX), DX 0x006e 00110 (/home/dominikh/prj/src/example.com/foo.go:16) SHLQ $34, DX 0x0072 00114 (/home/dominikh/prj/src/example.com/foo.go:16) ORQ CX, DX 0x0075 00117 (/home/dominikh/prj/src/example.com/foo.go:17) MOVQ 88(AX), CX 0x0079 00121 (/home/dominikh/prj/src/example.com/foo.go:17) SHLQ $37, CX 0x007d 00125 (/home/dominikh/prj/src/example.com/foo.go:17) ORQ DX, CX 0x0080 00128 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ 96(AX), DX 0x0084 00132 (/home/dominikh/prj/src/example.com/foo.go:18) SHLQ $40, DX 0x0088 00136 (/home/dominikh/prj/src/example.com/foo.go:18) ORQ CX, DX 0x008b 00139 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ 104(AX), CX 0x008f 00143 (/home/dominikh/prj/src/example.com/foo.go:19) SHLQ $43, CX 0x0093 00147 (/home/dominikh/prj/src/example.com/foo.go:19) ORQ DX, CX 0x0096 00150 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ 112(AX), DX 0x009a 00154 (/home/dominikh/prj/src/example.com/foo.go:20) SHLQ $46, DX 0x009e 00158 (/home/dominikh/prj/src/example.com/foo.go:20) ORQ CX, DX 0x00a1 00161 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ 120(AX), CX 0x00a5 00165 (/home/dominikh/prj/src/example.com/foo.go:21) SHLQ $49, CX 0x00a9 00169 (/home/dominikh/prj/src/example.com/foo.go:21) ORQ DX, CX 0x00ac 00172 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ 128(AX), DX 0x00b3 00179 (/home/dominikh/prj/src/example.com/foo.go:22) SHLQ $52, DX 0x00b7 00183 (/home/dominikh/prj/src/example.com/foo.go:22) ORQ CX, DX 0x00ba 00186 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ 136(AX), CX 0x00c1 00193 (/home/dominikh/prj/src/example.com/foo.go:23) SHLQ $55, CX 0x00c5 00197 (/home/dominikh/prj/src/example.com/foo.go:23) ORQ DX, CX 0x00c8 00200 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ 144(AX), DX 0x00cf 00207 (/home/dominikh/prj/src/example.com/foo.go:24) SHLQ $58, DX 0x00d3 00211 (/home/dominikh/prj/src/example.com/foo.go:24) ORQ CX, DX 0x00d6 00214 (/home/dominikh/prj/src/example.com/foo.go:25) MOVQ 152(AX), AX 0x00dd 00221 (/home/dominikh/prj/src/example.com/foo.go:25) SHLQ $61, AX 0x00e1 00225 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ DX, AX 0x00e4 00228 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ $4, AX 0x00e8 00232 (/home/dominikh/prj/src/example.com/foo.go:26) RET ``` ### What did you see instead? ``` command-line-arguments.pack20 STEXT nosplit size=314 args=0x8 locals=0x40 funcid=0x0 align=0x0 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) TEXT command-line-arguments.pack20(SB), NOSPLIT|ABIInternal, $64-8 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) PUSHQ BP 0x0001 00001 (/home/dominikh/prj/src/example.com/foo.go:3) MOVQ SP, BP 0x0004 00004 (/home/dominikh/prj/src/example.com/foo.go:3) SUBQ $56, SP 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $0, gclocals·wgcWObbY2HYnK2SU/U22lA==(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $1, gclocals·J5F+7Qw7O7ve2QcWC7DpeQ==(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $5, command-line-arguments.pack20.arginfo1(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $6, command-line-arguments.pack20.argliveinfo(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) PCDATA $3, $1 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ 8(AX), CX 0x000c 00012 (/home/dominikh/prj/src/example.com/foo.go:8) MOVQ 16(AX), DX 0x0010 00016 (/home/dominikh/prj/src/example.com/foo.go:9) MOVQ 24(AX), BX 0x0014 00020 (/home/dominikh/prj/src/example.com/foo.go:10) MOVQ 32(AX), SI 0x0018 00024 (/home/dominikh/prj/src/example.com/foo.go:11) MOVQ 40(AX), DI 0x001c 00028 (/home/dominikh/prj/src/example.com/foo.go:12) MOVQ 48(AX), R8 0x0020 00032 (/home/dominikh/prj/src/example.com/foo.go:13) MOVQ 56(AX), R9 0x0024 00036 (/home/dominikh/prj/src/example.com/foo.go:14) MOVQ 64(AX), R10 0x0028 00040 (/home/dominikh/prj/src/example.com/foo.go:15) MOVQ 72(AX), R11 0x002c 00044 (/home/dominikh/prj/src/example.com/foo.go:16) MOVQ 80(AX), R12 0x0030 00048 (/home/dominikh/prj/src/example.com/foo.go:17) MOVQ 88(AX), R13 0x0034 00052 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ 96(AX), R15 0x0038 00056 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ R15, command-line-arguments..autotmp_3+48(SP) 0x003d 00061 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ 104(AX), R15 0x0041 00065 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ R15, command-line-arguments..autotmp_4+40(SP) 0x0046 00070 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ 112(AX), R15 0x004a 00074 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ R15, command-line-arguments..autotmp_5+32(SP) 0x004f 00079 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ 120(AX), R15 0x0053 00083 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ R15, command-line-arguments..autotmp_6+24(SP) 0x0058 00088 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ 128(AX), R15 0x005f 00095 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ R15, command-line-arguments..autotmp_7+16(SP) 0x0064 00100 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ 136(AX), R15 0x006b 00107 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ R15, command-line-arguments..autotmp_8+8(SP) 0x0070 00112 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ 144(AX), R15 0x0077 00119 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ R15, command-line-arguments..autotmp_9(SP) 0x007b 00123 (/home/dominikh/prj/src/example.com/foo.go:25) MOVQ 152(AX), R15 0x0082 00130 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ (AX), AX 0x0085 00133 (/home/dominikh/prj/src/example.com/foo.go:6) SHLQ $4, AX 0x0089 00137 (/home/dominikh/prj/src/example.com/foo.go:7) SHLQ $7, CX 0x008d 00141 (/home/dominikh/prj/src/example.com/foo.go:7) ORQ CX, AX 0x0090 00144 (/home/dominikh/prj/src/example.com/foo.go:8) SHLQ $10, DX 0x0094 00148 (/home/dominikh/prj/src/example.com/foo.go:8) ORQ DX, AX 0x0097 00151 (/home/dominikh/prj/src/example.com/foo.go:9) SHLQ $13, BX 0x009b 00155 (/home/dominikh/prj/src/example.com/foo.go:9) ORQ BX, AX 0x009e 00158 (/home/dominikh/prj/src/example.com/foo.go:10) SHLQ $16, SI 0x00a2 00162 (/home/dominikh/prj/src/example.com/foo.go:10) ORQ SI, AX 0x00a5 00165 (/home/dominikh/prj/src/example.com/foo.go:11) SHLQ $19, DI 0x00a9 00169 (/home/dominikh/prj/src/example.com/foo.go:11) ORQ DI, AX 0x00ac 00172 (/home/dominikh/prj/src/example.com/foo.go:12) SHLQ $22, R8 0x00b0 00176 (/home/dominikh/prj/src/example.com/foo.go:12) ORQ R8, AX 0x00b3 00179 (/home/dominikh/prj/src/example.com/foo.go:13) SHLQ $25, R9 0x00b7 00183 (/home/dominikh/prj/src/example.com/foo.go:13) ORQ R9, AX 0x00ba 00186 (/home/dominikh/prj/src/example.com/foo.go:14) SHLQ $28, R10 0x00be 00190 (/home/dominikh/prj/src/example.com/foo.go:14) ORQ R10, AX 0x00c1 00193 (/home/dominikh/prj/src/example.com/foo.go:15) SHLQ $31, R11 0x00c5 00197 (/home/dominikh/prj/src/example.com/foo.go:15) ORQ R11, AX 0x00c8 00200 (/home/dominikh/prj/src/example.com/foo.go:16) SHLQ $34, R12 0x00cc 00204 (/home/dominikh/prj/src/example.com/foo.go:16) ORQ R12, AX 0x00cf 00207 (/home/dominikh/prj/src/example.com/foo.go:17) SHLQ $37, R13 0x00d3 00211 (/home/dominikh/prj/src/example.com/foo.go:17) ORQ R13, AX 0x00d6 00214 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ command-line-arguments..autotmp_3+48(SP), CX 0x00db 00219 (/home/dominikh/prj/src/example.com/foo.go:18) SHLQ $40, CX 0x00df 00223 (/home/dominikh/prj/src/example.com/foo.go:18) ORQ CX, AX 0x00e2 00226 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ command-line-arguments..autotmp_4+40(SP), CX 0x00e7 00231 (/home/dominikh/prj/src/example.com/foo.go:19) SHLQ $43, CX 0x00eb 00235 (/home/dominikh/prj/src/example.com/foo.go:19) ORQ CX, AX 0x00ee 00238 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ command-line-arguments..autotmp_5+32(SP), CX 0x00f3 00243 (/home/dominikh/prj/src/example.com/foo.go:20) SHLQ $46, CX 0x00f7 00247 (/home/dominikh/prj/src/example.com/foo.go:20) ORQ CX, AX 0x00fa 00250 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ command-line-arguments..autotmp_6+24(SP), CX 0x00ff 00255 (/home/dominikh/prj/src/example.com/foo.go:21) SHLQ $49, CX 0x0103 00259 (/home/dominikh/prj/src/example.com/foo.go:21) ORQ CX, AX 0x0106 00262 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ command-line-arguments..autotmp_7+16(SP), CX 0x010b 00267 (/home/dominikh/prj/src/example.com/foo.go:22) SHLQ $52, CX 0x010f 00271 (/home/dominikh/prj/src/example.com/foo.go:22) ORQ CX, AX 0x0112 00274 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ command-line-arguments..autotmp_8+8(SP), CX 0x0117 00279 (/home/dominikh/prj/src/example.com/foo.go:23) SHLQ $55, CX 0x011b 00283 (/home/dominikh/prj/src/example.com/foo.go:23) ORQ CX, AX 0x011e 00286 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ command-line-arguments..autotmp_9(SP), CX 0x0122 00290 (/home/dominikh/prj/src/example.com/foo.go:24) SHLQ $58, CX 0x0126 00294 (/home/dominikh/prj/src/example.com/foo.go:24) ORQ CX, AX 0x0129 00297 (/home/dominikh/prj/src/example.com/foo.go:25) SHLQ $61, R15 0x012d 00301 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ R15, AX 0x0130 00304 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ $4, AX 0x0134 00308 (/home/dominikh/prj/src/example.com/foo.go:26) ADDQ $56, SP 0x0138 00312 (/home/dominikh/prj/src/example.com/foo.go:26) POPQ BP 0x0139 00313 (/home/dominikh/prj/src/example.com/foo.go:26) RET ``` Go 1.21 seems to be loading all of the values up front, only to spill some of them to the stack. This seems strictly worse than the old output. /cc @prattmic ",True,"cmd/compile: regression: unnecessary spilling to the stack - ### What version of Go are you using (`go version`)? 
$ go version
go version devel go1.21-c30faf9c54 Fri Jul 14 12:49:10 2023 +0000 linux/amd64
### Does this issue reproduce with the latest release? No. ### What operating system and processor architecture are you using (`go env`)? Linux, amd64 ### What did you do? Compile ``` func pack20(in *[20]uint64) uint64 { var out uint64 out |= 4 out |= in[0] << 4 out |= in[1] << 7 out |= in[2] << 10 out |= in[3] << 13 out |= in[4] << 16 out |= in[5] << 19 out |= in[6] << 22 out |= in[7] << 25 out |= in[8] << 28 out |= in[9] << 31 out |= in[10] << 34 out |= in[11] << 37 out |= in[12] << 40 out |= in[13] << 43 out |= in[14] << 46 out |= in[15] << 49 out |= in[16] << 52 out |= in[17] << 55 out |= in[18] << 58 out |= in[19] << 61 return out } ``` ### What did you expect to see? Output similar to that of Go 1.20.6: ``` command-line-arguments.pack20 STEXT nosplit size=233 args=0x8 locals=0x0 funcid=0x0 align=0x0 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) TEXT command-line-arguments.pack20(SB), NOSPLIT|ABIInternal, $0-8 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $0, gclocals·wgcWObbY2HYnK2SU/U22lA==(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $1, gclocals·J5F+7Qw7O7ve2QcWC7DpeQ==(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $5, command-line-arguments.pack20.arginfo1(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $6, command-line-arguments.pack20.argliveinfo(SB) 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) PCDATA $3, $1 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ (AX), CX 0x0003 00003 (/home/dominikh/prj/src/example.com/foo.go:6) SHLQ $4, CX 0x0007 00007 (/home/dominikh/prj/src/example.com/foo.go:7) MOVQ 8(AX), DX 0x000b 00011 (/home/dominikh/prj/src/example.com/foo.go:7) SHLQ $7, DX 0x000f 00015 (/home/dominikh/prj/src/example.com/foo.go:7) ORQ DX, CX 0x0012 00018 (/home/dominikh/prj/src/example.com/foo.go:8) MOVQ 16(AX), DX 0x0016 00022 (/home/dominikh/prj/src/example.com/foo.go:8) SHLQ $10, DX 0x001a 00026 (/home/dominikh/prj/src/example.com/foo.go:8) ORQ CX, DX 0x001d 00029 (/home/dominikh/prj/src/example.com/foo.go:9) MOVQ 24(AX), CX 0x0021 00033 (/home/dominikh/prj/src/example.com/foo.go:9) SHLQ $13, CX 0x0025 00037 (/home/dominikh/prj/src/example.com/foo.go:9) ORQ DX, CX 0x0028 00040 (/home/dominikh/prj/src/example.com/foo.go:10) MOVQ 32(AX), DX 0x002c 00044 (/home/dominikh/prj/src/example.com/foo.go:10) SHLQ $16, DX 0x0030 00048 (/home/dominikh/prj/src/example.com/foo.go:10) ORQ CX, DX 0x0033 00051 (/home/dominikh/prj/src/example.com/foo.go:11) MOVQ 40(AX), CX 0x0037 00055 (/home/dominikh/prj/src/example.com/foo.go:11) SHLQ $19, CX 0x003b 00059 (/home/dominikh/prj/src/example.com/foo.go:11) ORQ DX, CX 0x003e 00062 (/home/dominikh/prj/src/example.com/foo.go:12) MOVQ 48(AX), DX 0x0042 00066 (/home/dominikh/prj/src/example.com/foo.go:12) SHLQ $22, DX 0x0046 00070 (/home/dominikh/prj/src/example.com/foo.go:12) ORQ CX, DX 0x0049 00073 (/home/dominikh/prj/src/example.com/foo.go:13) MOVQ 56(AX), CX 0x004d 00077 (/home/dominikh/prj/src/example.com/foo.go:13) SHLQ $25, CX 0x0051 00081 (/home/dominikh/prj/src/example.com/foo.go:13) ORQ DX, CX 0x0054 00084 (/home/dominikh/prj/src/example.com/foo.go:14) MOVQ 64(AX), DX 0x0058 00088 (/home/dominikh/prj/src/example.com/foo.go:14) SHLQ $28, DX 0x005c 00092 (/home/dominikh/prj/src/example.com/foo.go:14) ORQ CX, DX 0x005f 00095 (/home/dominikh/prj/src/example.com/foo.go:15) MOVQ 72(AX), CX 0x0063 00099 (/home/dominikh/prj/src/example.com/foo.go:15) SHLQ $31, CX 0x0067 00103 (/home/dominikh/prj/src/example.com/foo.go:15) ORQ DX, CX 0x006a 00106 (/home/dominikh/prj/src/example.com/foo.go:16) MOVQ 80(AX), DX 0x006e 00110 (/home/dominikh/prj/src/example.com/foo.go:16) SHLQ $34, DX 0x0072 00114 (/home/dominikh/prj/src/example.com/foo.go:16) ORQ CX, DX 0x0075 00117 (/home/dominikh/prj/src/example.com/foo.go:17) MOVQ 88(AX), CX 0x0079 00121 (/home/dominikh/prj/src/example.com/foo.go:17) SHLQ $37, CX 0x007d 00125 (/home/dominikh/prj/src/example.com/foo.go:17) ORQ DX, CX 0x0080 00128 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ 96(AX), DX 0x0084 00132 (/home/dominikh/prj/src/example.com/foo.go:18) SHLQ $40, DX 0x0088 00136 (/home/dominikh/prj/src/example.com/foo.go:18) ORQ CX, DX 0x008b 00139 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ 104(AX), CX 0x008f 00143 (/home/dominikh/prj/src/example.com/foo.go:19) SHLQ $43, CX 0x0093 00147 (/home/dominikh/prj/src/example.com/foo.go:19) ORQ DX, CX 0x0096 00150 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ 112(AX), DX 0x009a 00154 (/home/dominikh/prj/src/example.com/foo.go:20) SHLQ $46, DX 0x009e 00158 (/home/dominikh/prj/src/example.com/foo.go:20) ORQ CX, DX 0x00a1 00161 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ 120(AX), CX 0x00a5 00165 (/home/dominikh/prj/src/example.com/foo.go:21) SHLQ $49, CX 0x00a9 00169 (/home/dominikh/prj/src/example.com/foo.go:21) ORQ DX, CX 0x00ac 00172 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ 128(AX), DX 0x00b3 00179 (/home/dominikh/prj/src/example.com/foo.go:22) SHLQ $52, DX 0x00b7 00183 (/home/dominikh/prj/src/example.com/foo.go:22) ORQ CX, DX 0x00ba 00186 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ 136(AX), CX 0x00c1 00193 (/home/dominikh/prj/src/example.com/foo.go:23) SHLQ $55, CX 0x00c5 00197 (/home/dominikh/prj/src/example.com/foo.go:23) ORQ DX, CX 0x00c8 00200 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ 144(AX), DX 0x00cf 00207 (/home/dominikh/prj/src/example.com/foo.go:24) SHLQ $58, DX 0x00d3 00211 (/home/dominikh/prj/src/example.com/foo.go:24) ORQ CX, DX 0x00d6 00214 (/home/dominikh/prj/src/example.com/foo.go:25) MOVQ 152(AX), AX 0x00dd 00221 (/home/dominikh/prj/src/example.com/foo.go:25) SHLQ $61, AX 0x00e1 00225 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ DX, AX 0x00e4 00228 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ $4, AX 0x00e8 00232 (/home/dominikh/prj/src/example.com/foo.go:26) RET ``` ### What did you see instead? ``` command-line-arguments.pack20 STEXT nosplit size=314 args=0x8 locals=0x40 funcid=0x0 align=0x0 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) TEXT command-line-arguments.pack20(SB), NOSPLIT|ABIInternal, $64-8 0x0000 00000 (/home/dominikh/prj/src/example.com/foo.go:3) PUSHQ BP 0x0001 00001 (/home/dominikh/prj/src/example.com/foo.go:3) MOVQ SP, BP 0x0004 00004 (/home/dominikh/prj/src/example.com/foo.go:3) SUBQ $56, SP 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $0, gclocals·wgcWObbY2HYnK2SU/U22lA==(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $1, gclocals·J5F+7Qw7O7ve2QcWC7DpeQ==(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $5, command-line-arguments.pack20.arginfo1(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) FUNCDATA $6, command-line-arguments.pack20.argliveinfo(SB) 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:3) PCDATA $3, $1 0x0008 00008 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ 8(AX), CX 0x000c 00012 (/home/dominikh/prj/src/example.com/foo.go:8) MOVQ 16(AX), DX 0x0010 00016 (/home/dominikh/prj/src/example.com/foo.go:9) MOVQ 24(AX), BX 0x0014 00020 (/home/dominikh/prj/src/example.com/foo.go:10) MOVQ 32(AX), SI 0x0018 00024 (/home/dominikh/prj/src/example.com/foo.go:11) MOVQ 40(AX), DI 0x001c 00028 (/home/dominikh/prj/src/example.com/foo.go:12) MOVQ 48(AX), R8 0x0020 00032 (/home/dominikh/prj/src/example.com/foo.go:13) MOVQ 56(AX), R9 0x0024 00036 (/home/dominikh/prj/src/example.com/foo.go:14) MOVQ 64(AX), R10 0x0028 00040 (/home/dominikh/prj/src/example.com/foo.go:15) MOVQ 72(AX), R11 0x002c 00044 (/home/dominikh/prj/src/example.com/foo.go:16) MOVQ 80(AX), R12 0x0030 00048 (/home/dominikh/prj/src/example.com/foo.go:17) MOVQ 88(AX), R13 0x0034 00052 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ 96(AX), R15 0x0038 00056 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ R15, command-line-arguments..autotmp_3+48(SP) 0x003d 00061 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ 104(AX), R15 0x0041 00065 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ R15, command-line-arguments..autotmp_4+40(SP) 0x0046 00070 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ 112(AX), R15 0x004a 00074 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ R15, command-line-arguments..autotmp_5+32(SP) 0x004f 00079 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ 120(AX), R15 0x0053 00083 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ R15, command-line-arguments..autotmp_6+24(SP) 0x0058 00088 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ 128(AX), R15 0x005f 00095 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ R15, command-line-arguments..autotmp_7+16(SP) 0x0064 00100 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ 136(AX), R15 0x006b 00107 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ R15, command-line-arguments..autotmp_8+8(SP) 0x0070 00112 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ 144(AX), R15 0x0077 00119 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ R15, command-line-arguments..autotmp_9(SP) 0x007b 00123 (/home/dominikh/prj/src/example.com/foo.go:25) MOVQ 152(AX), R15 0x0082 00130 (/home/dominikh/prj/src/example.com/foo.go:6) MOVQ (AX), AX 0x0085 00133 (/home/dominikh/prj/src/example.com/foo.go:6) SHLQ $4, AX 0x0089 00137 (/home/dominikh/prj/src/example.com/foo.go:7) SHLQ $7, CX 0x008d 00141 (/home/dominikh/prj/src/example.com/foo.go:7) ORQ CX, AX 0x0090 00144 (/home/dominikh/prj/src/example.com/foo.go:8) SHLQ $10, DX 0x0094 00148 (/home/dominikh/prj/src/example.com/foo.go:8) ORQ DX, AX 0x0097 00151 (/home/dominikh/prj/src/example.com/foo.go:9) SHLQ $13, BX 0x009b 00155 (/home/dominikh/prj/src/example.com/foo.go:9) ORQ BX, AX 0x009e 00158 (/home/dominikh/prj/src/example.com/foo.go:10) SHLQ $16, SI 0x00a2 00162 (/home/dominikh/prj/src/example.com/foo.go:10) ORQ SI, AX 0x00a5 00165 (/home/dominikh/prj/src/example.com/foo.go:11) SHLQ $19, DI 0x00a9 00169 (/home/dominikh/prj/src/example.com/foo.go:11) ORQ DI, AX 0x00ac 00172 (/home/dominikh/prj/src/example.com/foo.go:12) SHLQ $22, R8 0x00b0 00176 (/home/dominikh/prj/src/example.com/foo.go:12) ORQ R8, AX 0x00b3 00179 (/home/dominikh/prj/src/example.com/foo.go:13) SHLQ $25, R9 0x00b7 00183 (/home/dominikh/prj/src/example.com/foo.go:13) ORQ R9, AX 0x00ba 00186 (/home/dominikh/prj/src/example.com/foo.go:14) SHLQ $28, R10 0x00be 00190 (/home/dominikh/prj/src/example.com/foo.go:14) ORQ R10, AX 0x00c1 00193 (/home/dominikh/prj/src/example.com/foo.go:15) SHLQ $31, R11 0x00c5 00197 (/home/dominikh/prj/src/example.com/foo.go:15) ORQ R11, AX 0x00c8 00200 (/home/dominikh/prj/src/example.com/foo.go:16) SHLQ $34, R12 0x00cc 00204 (/home/dominikh/prj/src/example.com/foo.go:16) ORQ R12, AX 0x00cf 00207 (/home/dominikh/prj/src/example.com/foo.go:17) SHLQ $37, R13 0x00d3 00211 (/home/dominikh/prj/src/example.com/foo.go:17) ORQ R13, AX 0x00d6 00214 (/home/dominikh/prj/src/example.com/foo.go:18) MOVQ command-line-arguments..autotmp_3+48(SP), CX 0x00db 00219 (/home/dominikh/prj/src/example.com/foo.go:18) SHLQ $40, CX 0x00df 00223 (/home/dominikh/prj/src/example.com/foo.go:18) ORQ CX, AX 0x00e2 00226 (/home/dominikh/prj/src/example.com/foo.go:19) MOVQ command-line-arguments..autotmp_4+40(SP), CX 0x00e7 00231 (/home/dominikh/prj/src/example.com/foo.go:19) SHLQ $43, CX 0x00eb 00235 (/home/dominikh/prj/src/example.com/foo.go:19) ORQ CX, AX 0x00ee 00238 (/home/dominikh/prj/src/example.com/foo.go:20) MOVQ command-line-arguments..autotmp_5+32(SP), CX 0x00f3 00243 (/home/dominikh/prj/src/example.com/foo.go:20) SHLQ $46, CX 0x00f7 00247 (/home/dominikh/prj/src/example.com/foo.go:20) ORQ CX, AX 0x00fa 00250 (/home/dominikh/prj/src/example.com/foo.go:21) MOVQ command-line-arguments..autotmp_6+24(SP), CX 0x00ff 00255 (/home/dominikh/prj/src/example.com/foo.go:21) SHLQ $49, CX 0x0103 00259 (/home/dominikh/prj/src/example.com/foo.go:21) ORQ CX, AX 0x0106 00262 (/home/dominikh/prj/src/example.com/foo.go:22) MOVQ command-line-arguments..autotmp_7+16(SP), CX 0x010b 00267 (/home/dominikh/prj/src/example.com/foo.go:22) SHLQ $52, CX 0x010f 00271 (/home/dominikh/prj/src/example.com/foo.go:22) ORQ CX, AX 0x0112 00274 (/home/dominikh/prj/src/example.com/foo.go:23) MOVQ command-line-arguments..autotmp_8+8(SP), CX 0x0117 00279 (/home/dominikh/prj/src/example.com/foo.go:23) SHLQ $55, CX 0x011b 00283 (/home/dominikh/prj/src/example.com/foo.go:23) ORQ CX, AX 0x011e 00286 (/home/dominikh/prj/src/example.com/foo.go:24) MOVQ command-line-arguments..autotmp_9(SP), CX 0x0122 00290 (/home/dominikh/prj/src/example.com/foo.go:24) SHLQ $58, CX 0x0126 00294 (/home/dominikh/prj/src/example.com/foo.go:24) ORQ CX, AX 0x0129 00297 (/home/dominikh/prj/src/example.com/foo.go:25) SHLQ $61, R15 0x012d 00301 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ R15, AX 0x0130 00304 (/home/dominikh/prj/src/example.com/foo.go:25) ORQ $4, AX 0x0134 00308 (/home/dominikh/prj/src/example.com/foo.go:26) ADDQ $56, SP 0x0138 00312 (/home/dominikh/prj/src/example.com/foo.go:26) POPQ BP 0x0139 00313 (/home/dominikh/prj/src/example.com/foo.go:26) RET ``` Go 1.21 seems to be loading all of the values up front, only to spill some of them to the stack. This seems strictly worse than the old output. /cc @prattmic ",0,cmd compile regression unnecessary spilling to the stack what version of go are you using go version go version go version devel fri jul linux does this issue reproduce with the latest release no what operating system and processor architecture are you using go env linux what did you do compile func in var out out out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in out in return out what did you expect to see output similar to that of go command line arguments stext nosplit size args locals funcid align home dominikh prj src example com foo go text command line arguments sb nosplit abiinternal home dominikh prj src example com foo go funcdata gclocals· sb home dominikh prj src example com foo go funcdata gclocals· sb home dominikh prj src example com foo go funcdata command line arguments sb home dominikh prj src example com foo go funcdata command line arguments argliveinfo sb home dominikh prj src example com foo go pcdata home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq dx cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq cx dx home dominikh prj src example com foo go movq ax ax home dominikh prj src example com foo go shlq ax home dominikh prj src example com foo go orq dx ax home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go ret what did you see instead command line arguments stext nosplit size args locals funcid align home dominikh prj src example com foo go text command line arguments sb nosplit abiinternal home dominikh prj src example com foo go pushq bp home dominikh prj src example com foo go movq sp bp home dominikh prj src example com foo go subq sp home dominikh prj src example com foo go funcdata gclocals· sb home dominikh prj src example com foo go funcdata gclocals· sb home dominikh prj src example com foo go funcdata command line arguments sb home dominikh prj src example com foo go funcdata command line arguments argliveinfo sb home dominikh prj src example com foo go pcdata home dominikh prj src example com foo go movq ax cx home dominikh prj src example com foo go movq ax dx home dominikh prj src example com foo go movq ax bx home dominikh prj src example com foo go movq ax si home dominikh prj src example com foo go movq ax di home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq command line arguments autotmp sp home dominikh prj src example com foo go movq ax home dominikh prj src example com foo go movq ax ax home dominikh prj src example com foo go shlq ax home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go shlq dx home dominikh prj src example com foo go orq dx ax home dominikh prj src example com foo go shlq bx home dominikh prj src example com foo go orq bx ax home dominikh prj src example com foo go shlq si home dominikh prj src example com foo go orq si ax home dominikh prj src example com foo go shlq di home dominikh prj src example com foo go orq di ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go movq command line arguments autotmp sp cx home dominikh prj src example com foo go shlq cx home dominikh prj src example com foo go orq cx ax home dominikh prj src example com foo go shlq home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go orq ax home dominikh prj src example com foo go addq sp home dominikh prj src example com foo go popq bp home dominikh prj src example com foo go ret go seems to be loading all of the values up front only to spill some of them to the stack this seems strictly worse than the old output cc prattmic ,0 313243,23464649324.0,IssuesEvent,2022-08-16 15:41:46,golang/go,https://api.github.com/repos/golang/go,closed,go install OR docs inconsistent to install multiple versions,Documentation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.15 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/user/.cache/go-build""
GOENV=""/home/user/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/user/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/user/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/1.18""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/1.18/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build482777503=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. cd to a go module. 2. execute install as instructed in https://go.dev/doc/manage-install ```sh $ go install golang.org/dl/go1.17.0@latest ``` ### What did you expect to see? ``` $ go1.17.0 version > return a value ``` ### What did you see instead? ``` > go install golang.org/dl/go1.17.0@latest > package golang.org/dl/go1.17.0@latest: can only use path@version syntax with 'go get' $ go1.17.0 version > ``` ",1.0,"go install OR docs inconsistent to install multiple versions - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.15 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/user/.cache/go-build""
GOENV=""/home/user/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/user/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/user/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/1.18""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/1.18/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build482777503=/tmp/go-build -gno-record-gcc-switches""
### What did you do? 1. cd to a go module. 2. execute install as instructed in https://go.dev/doc/manage-install ```sh $ go install golang.org/dl/go1.17.0@latest ``` ### What did you expect to see? ``` $ go1.17.0 version > return a value ``` ### What did you see instead? ``` > go install golang.org/dl/go1.17.0@latest > package golang.org/dl/go1.17.0@latest: can only use path@version syntax with 'go get' $ go1.17.0 version > ``` ",1,go install or docs inconsistent to install multiple versions what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home user cache go build goenv home user config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home user go pkg mod gonoproxy gonosumdb goos linux gopath home user go goprivate goproxy goroot opt go gosumdb sum golang org gotmpdir gotooldir opt go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do cd to a go module execute install as instructed in sh go install golang org dl latest what did you expect to see version return a value what did you see instead go install golang org dl latest package golang org dl latest can only use path version syntax with go get version ,1 242012,18509320577.0,IssuesEvent,2021-10-19 23:23:39,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that ProxyFromEnvironment also ignores loopback addresses,Documentation help wanted NeedsFix," ### What version of Go are you using (`go version`)? go version go1.11.12 linux/amd64 (but the code seems to indicate that this also happens on master). This also seems to be affecting all platforms. ### What did you do? I set the local proxy to some address. The address does not really matter, because the client never connects to it (unexpected). http.Get to the loopback ip: 127.0.0.1 or [::1]. ### What did you expect to see? Since the docs [1](https://golang.org/pkg/net/http/#ProxyFromEnvironment), [2](https://godoc.org/golang.org/x/net/http/httpproxy#Config.ProxyFunc) specifically mention that only requests who's req.URL.Host is `localhost` get ignored (not proxied), it is to be expected that the loopback would still work (e.g. `127.0.0.1` or `[::1]`). Instead, [the code](https://github.com/golang/net/blob/master/http/httpproxy/proxy.go#L188) ensures that the Host is neither localhost nor any loopback ip. ### What did you see instead? The request never made it to the proxy, it went to the website directly. (I expected to see something along those lines: cannot connect to proxy example.org:12345) but got: Get http://127.0.0.1: dial tcp 127.0.0.1:80: connect: connection refused. --- The documentation should be updated to point out that any loopback ip address will also get ignored. It would also be helpful to post the workaround mentioned [here](https://github.com/golang/go/issues/7256#issuecomment-66090979) where it was discussed why localhost is ignored and how to ""disable"" that (using localhost.localdomain or localhost4, which is available on every linux machine works fine). That would have saved me quit a bit of time since the thread was hard to find. It would probably be also worth discussing why this was implemented in the first place. If you don't want to use a proxy, there are several ways to do it (set `Transport.Proxy = nil` or set the environment variable `noproxy`). This makes debugging client requests harder then it needs to be (I find it easiest to use mitm-proxy to verify that all headers, etc are set correctly).",1.0,"net/http: document that ProxyFromEnvironment also ignores loopback addresses - ### What version of Go are you using (`go version`)? go version go1.11.12 linux/amd64 (but the code seems to indicate that this also happens on master). This also seems to be affecting all platforms. ### What did you do? I set the local proxy to some address. The address does not really matter, because the client never connects to it (unexpected). http.Get to the loopback ip: 127.0.0.1 or [::1]. ### What did you expect to see? Since the docs [1](https://golang.org/pkg/net/http/#ProxyFromEnvironment), [2](https://godoc.org/golang.org/x/net/http/httpproxy#Config.ProxyFunc) specifically mention that only requests who's req.URL.Host is `localhost` get ignored (not proxied), it is to be expected that the loopback would still work (e.g. `127.0.0.1` or `[::1]`). Instead, [the code](https://github.com/golang/net/blob/master/http/httpproxy/proxy.go#L188) ensures that the Host is neither localhost nor any loopback ip. ### What did you see instead? The request never made it to the proxy, it went to the website directly. (I expected to see something along those lines: cannot connect to proxy example.org:12345) but got: Get http://127.0.0.1: dial tcp 127.0.0.1:80: connect: connection refused. --- The documentation should be updated to point out that any loopback ip address will also get ignored. It would also be helpful to post the workaround mentioned [here](https://github.com/golang/go/issues/7256#issuecomment-66090979) where it was discussed why localhost is ignored and how to ""disable"" that (using localhost.localdomain or localhost4, which is available on every linux machine works fine). That would have saved me quit a bit of time since the thread was hard to find. It would probably be also worth discussing why this was implemented in the first place. If you don't want to use a proxy, there are several ways to do it (set `Transport.Proxy = nil` or set the environment variable `noproxy`). This makes debugging client requests harder then it needs to be (I find it easiest to use mitm-proxy to verify that all headers, etc are set correctly).",1,net http document that proxyfromenvironment also ignores loopback addresses what version of go are you using go version go version linux but the code seems to indicate that this also happens on master this also seems to be affecting all platforms what did you do i set the local proxy to some address the address does not really matter because the client never connects to it unexpected http get to the loopback ip or export http client go run what did you expect to see since the docs specifically mention that only requests who s req url host is localhost get ignored not proxied it is to be expected that the loopback would still work e g or instead ensures that the host is neither localhost nor any loopback ip what did you see instead the request never made it to the proxy it went to the website directly i expected to see something along those lines cannot connect to proxy example org but got get dial tcp connect connection refused the documentation should be updated to point out that any loopback ip address will also get ignored it would also be helpful to post the workaround mentioned where it was discussed why localhost is ignored and how to disable that using localhost localdomain or which is available on every linux machine works fine that would have saved me quit a bit of time since the thread was hard to find it would probably be also worth discussing why this was implemented in the first place if you don t want to use a proxy there are several ways to do it set transport proxy nil or set the environment variable noproxy this makes debugging client requests harder then it needs to be i find it easiest to use mitm proxy to verify that all headers etc are set correctly ,1 117155,9914837923.0,IssuesEvent,2019-06-28 15:17:34,golang/go,https://api.github.com/repos/golang/go,opened,x/crypto/ssh: test consistently runs out of memory on js-wasm builder,Arch-Wasm NeedsInvestigation Soon Testing,"The `golang.org/x/crypto/ssh` test consistently fails on the `js-wasm` builder with the error message `runtime: out of memory: cannot allocate 8192-byte block`. Can the test be made to fit within the runtime on that architecture? If not, it should be skipped, instead of continuing to fail and potentially masking more serious problems. CC @hanwen @neelance @FiloSottile ",1.0,"x/crypto/ssh: test consistently runs out of memory on js-wasm builder - The `golang.org/x/crypto/ssh` test consistently fails on the `js-wasm` builder with the error message `runtime: out of memory: cannot allocate 8192-byte block`. Can the test be made to fit within the runtime on that architecture? If not, it should be skipped, instead of continuing to fail and potentially masking more serious problems. CC @hanwen @neelance @FiloSottile ",0,x crypto ssh test consistently runs out of memory on js wasm builder the golang org x crypto ssh test consistently fails on the js wasm builder with the error message runtime out of memory cannot allocate byte block can the test be made to fit within the runtime on that architecture if not it should be skipped instead of continuing to fail and potentially masking more serious problems cc hanwen neelance filosottile ,0 239714,19910835580.0,IssuesEvent,2022-01-25 17:00:01,golang/go,https://api.github.com/repos/golang/go,closed,"crypto/tls: ""use of closed network connection"" in TestDialTimeout",Testing NeedsInvestigation,"Seen on the `linux-amd64-longtest` builder (https://build.golang.org/log/9fbd6f6c2639b72e2d147e1d16d45784fdc2e069): ``` --- FAIL: TestDialTimeout (0.01s) tls_test.go:183: accept tcp 127.0.0.1:38709: use of closed network connection FAIL FAIL crypto/tls 0.702s ``` CC @FiloSottile ",1.0,"crypto/tls: ""use of closed network connection"" in TestDialTimeout - Seen on the `linux-amd64-longtest` builder (https://build.golang.org/log/9fbd6f6c2639b72e2d147e1d16d45784fdc2e069): ``` --- FAIL: TestDialTimeout (0.01s) tls_test.go:183: accept tcp 127.0.0.1:38709: use of closed network connection FAIL FAIL crypto/tls 0.702s ``` CC @FiloSottile ",0,crypto tls use of closed network connection in testdialtimeout seen on the linux longtest builder fail testdialtimeout tls test go accept tcp use of closed network connection fail fail crypto tls cc filosottile ,0 69698,9321575950.0,IssuesEvent,2019-03-27 04:38:31,golang/go,https://api.github.com/repos/golang/go,closed,os: Document Exit() behavior with code outside 0 - 255,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/cuonglm/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/cuonglm/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/stow/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/stow/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/cuonglm/sources/go/src/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-build303772017=/tmp/go-build -gno-record-gcc-switches""
### What did you do? ``` package main import ""os"" func main() { os.Exit(256) } ``` Compile program then run: ``` ./main || echo ./main should return failure code ``` ### What did you expect to see? `./main should return failure code` is printed in terminal. ### What did you see instead? No output. The number `256` is passed as-is to `_exit()`, or in my case `exit_group()` on Linux. But on Linux, and other systems which use traditional `wait*()` system call, only the lower 8 bits of that number are available to the parent. it means the program above appears as success. If the parent uses `waitid()`, the number won't be truncated and return as-is to the parent (Though not on Linux, which still truncate the number even `waitid()` was used. The behavior maybe change in the future). So the behavior of `os.Exit(code)` where code > 255 or code < 0 can not be consistent. I propose one of these changes: - Always transform the code like `wait*()` does, mean a value between 0-255 always returns to parent. - Limit the code to value between 0 - 255, do something in case the code out of range: + warning message that value outside of 0 - 255 can be truncated + warning message that value outside of 0 - 255 is bad number (like dash, yash does) + panic, so user knows the problem, and get a standard error code from panic. It also does not break any program. (like m4 does) - Document that only value between 0 - 255 is consistent and should be used. Value greater than 255 may or may not be truncated, so the exit code is unspecified.",1.0,"os: Document Exit() behavior with code outside 0 - 255 - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/cuonglm/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/cuonglm/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/stow/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/stow/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/cuonglm/sources/go/src/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-build303772017=/tmp/go-build -gno-record-gcc-switches""
### What did you do? ``` package main import ""os"" func main() { os.Exit(256) } ``` Compile program then run: ``` ./main || echo ./main should return failure code ``` ### What did you expect to see? `./main should return failure code` is printed in terminal. ### What did you see instead? No output. The number `256` is passed as-is to `_exit()`, or in my case `exit_group()` on Linux. But on Linux, and other systems which use traditional `wait*()` system call, only the lower 8 bits of that number are available to the parent. it means the program above appears as success. If the parent uses `waitid()`, the number won't be truncated and return as-is to the parent (Though not on Linux, which still truncate the number even `waitid()` was used. The behavior maybe change in the future). So the behavior of `os.Exit(code)` where code > 255 or code < 0 can not be consistent. I propose one of these changes: - Always transform the code like `wait*()` does, mean a value between 0-255 always returns to parent. - Limit the code to value between 0 - 255, do something in case the code out of range: + warning message that value outside of 0 - 255 can be truncated + warning message that value outside of 0 - 255 is bad number (like dash, yash does) + panic, so user knows the problem, and get a standard error code from panic. It also does not break any program. (like m4 does) - Document that only value between 0 - 255 is consistent and should be used. Value greater than 255 may or may not be truncated, so the exit code is unspecified.",1,os document exit behavior with code outside what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home cuonglm cache go build goexe goflags gohostarch gohostos linux goos linux gopath home cuonglm go goproxy gorace goroot usr local stow go gotmpdir gotooldir usr local stow go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod home cuonglm sources go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do package main import os func main os exit compile program then run main echo main should return failure code what did you expect to see main should return failure code is printed in terminal what did you see instead no output the number is passed as is to exit or in my case exit group on linux but on linux and other systems which use traditional wait system call only the lower bits of that number are available to the parent it means the program above appears as success if the parent uses waitid the number won t be truncated and return as is to the parent though not on linux which still truncate the number even waitid was used the behavior maybe change in the future so the behavior of os exit code where code or code can not be consistent i propose one of these changes always transform the code like wait does mean a value between always returns to parent limit the code to value between do something in case the code out of range warning message that value outside of can be truncated warning message that value outside of is bad number like dash yash does panic so user knows the problem and get a standard error code from panic it also does not break any program like does document that only value between is consistent and should be used value greater than may or may not be truncated so the exit code is unspecified ,1 5803,2974785975.0,IssuesEvent,2015-07-15 04:31:56,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: Document that prepared statements must be Close()' ,Documentation,"
Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What does 'go version' print?

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1.
2.
3.

What happened?

What should have happened instead?

Please provide any additional information below.
",1.0,"database/sql: Document that prepared statements must be Close()' - 
Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What does 'go version' print?

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1.
2.
3.

What happened?

What should have happened instead?

Please provide any additional information below.
",1,database sql document that prepared statements must be close before filing a bug please check whether it has been fixed since the latest release search the issue tracker and check that you re running the latest version of go run quot go version quot and compare against a href if a newer version of go exists install it and retry what you did to reproduce the problem thanks what does go version print what steps reproduce the problem if possible include a link to a program on play golang org what happened what should have happened instead please provide any additional information below ,1 4589,4467319806.0,IssuesEvent,2016-08-25 03:51:02,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/compile: recognize and optimize ""in range"" booleans",Performance,"```go package p func inrange(x int) bool { return 5 <= x && x < 10 } func inrange2(x int) bool { return uint(x-5) < 5 } ``` These two functions are equivalent, but the second is more efficient (it trades a subtraction for a compare-and-branch). We do this already for index-in-bounds checks. We should generally recognize integer-in-range patterns and convert them. We should probably do this in the SSA backend, since it'll be more general and powerful there than a limited front-end rewrite like rotation recognition. (I'm open to being convinced otherwise, though.) This will be helpful for #15780. It'll also help a bit with a hot line in scanobject (`arena_start <= obj && obj < arena_used`). /cc @brtzsnr @randall77 ",True,"cmd/compile: recognize and optimize ""in range"" booleans - ```go package p func inrange(x int) bool { return 5 <= x && x < 10 } func inrange2(x int) bool { return uint(x-5) < 5 } ``` These two functions are equivalent, but the second is more efficient (it trades a subtraction for a compare-and-branch). We do this already for index-in-bounds checks. We should generally recognize integer-in-range patterns and convert them. We should probably do this in the SSA backend, since it'll be more general and powerful there than a limited front-end rewrite like rotation recognition. (I'm open to being convinced otherwise, though.) This will be helpful for #15780. It'll also help a bit with a hot line in scanobject (`arena_start <= obj && obj < arena_used`). /cc @brtzsnr @randall77 ",0,cmd compile recognize and optimize in range booleans go package p func inrange x int bool return x x func x int bool return uint x these two functions are equivalent but the second is more efficient it trades a subtraction for a compare and branch we do this already for index in bounds checks we should generally recognize integer in range patterns and convert them we should probably do this in the ssa backend since it ll be more general and powerful there than a limited front end rewrite like rotation recognition i m open to being convinced otherwise though this will be helpful for it ll also help a bit with a hot line in scanobject arena start obj obj arena used cc brtzsnr ,0 15771,6037439856.0,IssuesEvent,2017-06-09 18:40:53,golang/go,https://api.github.com/repos/golang/go,closed,x/build: trybot's benchmark work doesn't chdir to package dir?,Builders HelpWanted NeedsFix,"I just say this trybot failure: https://storage.googleapis.com/go-build-log/f57a1818/linux-amd64_f9af06de.log ... during benchmarking. I suspect that the benchmark code isn't setting the working directory appropriately. /cc @quentinmit ",1.0,"x/build: trybot's benchmark work doesn't chdir to package dir? - I just say this trybot failure: https://storage.googleapis.com/go-build-log/f57a1818/linux-amd64_f9af06de.log ... during benchmarking. I suspect that the benchmark code isn't setting the working directory appropriately. /cc @quentinmit ",0,x build trybot s benchmark work doesn t chdir to package dir i just say this trybot failure during benchmarking i suspect that the benchmark code isn t setting the working directory appropriately cc quentinmit ,0 79219,10114077046.0,IssuesEvent,2019-07-30 18:18:08,golang/go,https://api.github.com/repos/golang/go,closed,wiki: PerfDashboard links broken,Documentation NeedsFix,"### Wiki link https://github.com/golang/go/wiki/PerfDashboard ### Which broken links * [in detail](https://build.golang.org/perfdetail?commit=fb3d6c1631c3f3141f33a01afb4c0a23ef0ea2cf&commit0=82f48826c6c79a3d5697d5e06cac8451f3dc3c7f&kind=builder&builder=linux-amd64-perf&benchmark=http) * [perf detail](https://build.golang.org/perfdetail?commit=fb3d6c1631c3f3141f33a01afb4c0a23ef0ea2cf&commit0=82f48826c6c79a3d5697d5e06cac8451f3dc3c7f&kind=builder&builder=linux-amd64-perf&benchmark=http) ### Using the perf dashboard When I click to the perf dashboard on https://build.golang.org/perf?page=6, I see many empty HTML rows and links that go to the code review. I am unable to find performance differences. It appears the perf dashboard may not be working as intended.",1.0,"wiki: PerfDashboard links broken - ### Wiki link https://github.com/golang/go/wiki/PerfDashboard ### Which broken links * [in detail](https://build.golang.org/perfdetail?commit=fb3d6c1631c3f3141f33a01afb4c0a23ef0ea2cf&commit0=82f48826c6c79a3d5697d5e06cac8451f3dc3c7f&kind=builder&builder=linux-amd64-perf&benchmark=http) * [perf detail](https://build.golang.org/perfdetail?commit=fb3d6c1631c3f3141f33a01afb4c0a23ef0ea2cf&commit0=82f48826c6c79a3d5697d5e06cac8451f3dc3c7f&kind=builder&builder=linux-amd64-perf&benchmark=http) ### Using the perf dashboard When I click to the perf dashboard on https://build.golang.org/perf?page=6, I see many empty HTML rows and links that go to the code review. I am unable to find performance differences. It appears the perf dashboard may not be working as intended.",1,wiki perfdashboard links broken wiki link which broken links using the perf dashboard when i click to the perf dashboard on i see many empty html rows and links that go to the code review i am unable to find performance differences it appears the perf dashboard may not be working as intended ,1 36305,6524965302.0,IssuesEvent,2017-08-29 14:26:27,golang/go,https://api.github.com/repos/golang/go,closed,spec: similar sounding nomenclature is confusing,Documentation,"
In the spec we use the following phrases:

1) integer value
2) value of integer type
3) value of type int (or int8, int16, etc)
4) representable as a value of type int (or int8, int16, etc)

They are very similar in English but mean different things in the spec:

1) -> a (typed or untyped) constant value that is integer (1, 2.0, -4.0 + 0i)
2) -> a typed value that has one of the signed/unsigned integer types (byte, int,
uint8, etc.)
3) -> a value of a concrete type int, int8, etc.
4) -> a value that can be represented w/o loss of accuracy as a value of a specific
type

We should clean this up, and/or introduce a section explaining the nomenclature. As is,
the English differences are small, but the spec implications are large.
",1.0,"spec: similar sounding nomenclature is confusing - 
In the spec we use the following phrases:

1) integer value
2) value of integer type
3) value of type int (or int8, int16, etc)
4) representable as a value of type int (or int8, int16, etc)

They are very similar in English but mean different things in the spec:

1) -> a (typed or untyped) constant value that is integer (1, 2.0, -4.0 + 0i)
2) -> a typed value that has one of the signed/unsigned integer types (byte, int,
uint8, etc.)
3) -> a value of a concrete type int, int8, etc.
4) -> a value that can be represented w/o loss of accuracy as a value of a specific
type

We should clean this up, and/or introduce a section explaining the nomenclature. As is,
the English differences are small, but the spec implications are large.
",1,spec similar sounding nomenclature is confusing in the spec we use the following phrases integer value value of integer type value of type int or etc representable as a value of type int or etc they are very similar in english but mean different things in the spec gt a typed or untyped constant value that is integer gt a typed value that has one of the signed unsigned integer types byte int etc gt a value of a concrete type int etc gt a value that can be represented w o loss of accuracy as a value of a specific type we should clean this up and or introduce a section explaining the nomenclature as is the english differences are small but the spec implications are large ,1 8156,6437818266.0,IssuesEvent,2017-08-11 00:52:37,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: improve codegen for nested if statements,Performance,"As observed in CL 54651, these two semantically equivalent bits of code do not always compile equivalently: ```go if a { if b { // ... } } ``` ```go if a && b { // ... } ``` This issue is to investigate why, and if the latter is systematically better, consider improving the former. Note that 'if a && b' gets special handling at Node -> SSA time; phiopt.go does some further related cleanup, but perhaps not enough. cc @randall77 ",True,"cmd/compile: improve codegen for nested if statements - As observed in CL 54651, these two semantically equivalent bits of code do not always compile equivalently: ```go if a { if b { // ... } } ``` ```go if a && b { // ... } ``` This issue is to investigate why, and if the latter is systematically better, consider improving the former. Note that 'if a && b' gets special handling at Node -> SSA time; phiopt.go does some further related cleanup, but perhaps not enough. cc @randall77 ",0,cmd compile improve codegen for nested if statements as observed in cl these two semantically equivalent bits of code do not always compile equivalently go if a if b go if a b this issue is to investigate why and if the latter is systematically better consider improving the former note that if a b gets special handling at node ssa time phiopt go does some further related cleanup but perhaps not enough cc ,0 35613,6485394162.0,IssuesEvent,2017-08-19 09:51:17,golang/go,https://api.github.com/repos/golang/go,opened,doc: Install from source doc at golang.org/doc inconsistent with install output,Documentation,"### What version of Go are you using (`go version`)? go version go1.8.3 darwin/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ### What did you do? Installed Go from source after a `git clone` (in addition to a system Go). ```bash $ cd ~/dev/go/src $ ./make.bash ``` ### What did you expect to see? The docs at https://golang.org/doc/install/source#install says: > If all goes well, it will finish by printing output like: ``` ALL TESTS PASSED --- Installed Go for linux/amd64 in /home/you/go. Installed commands in /home/you/go/bin. *** You need to add /home/you/go/bin to your $PATH. *** ``` ### What did you see instead? It's really minor, but after a source install I don't see the `*** You need to add /home/you/go/bin to your $PATH. ***` line. Either there is a bug printing the line or the doc is outdated? I was making some standard library changes and building the source, but using my system go `/usr/local/bin/go` to test changes instead of the newly-built binary and wondering why the changes weren't applied :) The line helps to avoid this sort of beginner mistake, especially when you have multiple Go versions installed. Thanks! ",1.0,"doc: Install from source doc at golang.org/doc inconsistent with install output - ### What version of Go are you using (`go version`)? go version go1.8.3 darwin/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" ### What did you do? Installed Go from source after a `git clone` (in addition to a system Go). ```bash $ cd ~/dev/go/src $ ./make.bash ``` ### What did you expect to see? The docs at https://golang.org/doc/install/source#install says: > If all goes well, it will finish by printing output like: ``` ALL TESTS PASSED --- Installed Go for linux/amd64 in /home/you/go. Installed commands in /home/you/go/bin. *** You need to add /home/you/go/bin to your $PATH. *** ``` ### What did you see instead? It's really minor, but after a source install I don't see the `*** You need to add /home/you/go/bin to your $PATH. ***` line. Either there is a bug printing the line or the doc is outdated? I was making some standard library changes and building the source, but using my system go `/usr/local/bin/go` to test changes instead of the newly-built binary and wondering why the changes weren't applied :) The line helps to avoid this sort of beginner mistake, especially when you have multiple Go versions installed. Thanks! ",1,doc install from source doc at golang org doc inconsistent with install output what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env gohostarch gohostos darwin goos darwin what did you do installed go from source after a git clone in addition to a system go bash cd dev go src make bash what did you expect to see the docs at says if all goes well it will finish by printing output like all tests passed installed go for linux in home you go installed commands in home you go bin you need to add home you go bin to your path what did you see instead it s really minor but after a source install i don t see the you need to add home you go bin to your path line either there is a bug printing the line or the doc is outdated i was making some standard library changes and building the source but using my system go usr local bin go to test changes instead of the newly built binary and wondering why the changes weren t applied the line helps to avoid this sort of beginner mistake especially when you have multiple go versions installed thanks ,1 302670,22837704247.0,IssuesEvent,2022-07-12 18:20:55,golang/go,https://api.github.com/repos/golang/go,closed,x/website: add a Go GC guide,Documentation NeedsFix release-blocker okay-after-beta1 website,As part of #48409 I proposed adding a new guide for the Go GC. This is an issue to track that work.,1.0,x/website: add a Go GC guide - As part of #48409 I proposed adding a new guide for the Go GC. This is an issue to track that work.,1,x website add a go gc guide as part of i proposed adding a new guide for the go gc this is an issue to track that work ,1 65092,8787521746.0,IssuesEvent,2018-12-20 18:57:26,golang/go,https://api.github.com/repos/golang/go,closed,"os, os/signal: inconsistent documentation",Documentation NeedsFix OS-Windows,"I'm trying to define cleanup behavior in a Windows program, so I want to catch a signal, do some cleanup, and then exit the program. I don't have a Windows machine though so testing this is sort of tricky. The docs for `os.Interrupt` state: > The only signal values guaranteed to be present in the os package on all systems are Interrupt (send the process an interrupt) and Kill (force the process to exit). Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error. However, the docs for `os/signal` state, under the Windows section: > On Windows a ^C (Control-C) or ^BREAK (Control-Break) normally cause the program to exit. If Notify is called for os.Interrupt, ^C or ^BREAK will cause os.Interrupt to be sent on the channel, and the program will not exit. I'm confused how Interrupt can be all of: - guaranteed to be present - not implemented - calling Notify() can cause it to be sent on the channel when a user hits ^BREAK Searching the `os` package source code for Interrupt seems to show it's only defined for unix/posix GOOS's and not for Windows. It might be nice to add a short doc to the `os` package explaining how it gets sent (if I am reading correctly, from `runtime/os_windows.go:ctrlhandler1` and `runtime/sigqueue.go:sigsend`).",1.0,"os, os/signal: inconsistent documentation - I'm trying to define cleanup behavior in a Windows program, so I want to catch a signal, do some cleanup, and then exit the program. I don't have a Windows machine though so testing this is sort of tricky. The docs for `os.Interrupt` state: > The only signal values guaranteed to be present in the os package on all systems are Interrupt (send the process an interrupt) and Kill (force the process to exit). Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error. However, the docs for `os/signal` state, under the Windows section: > On Windows a ^C (Control-C) or ^BREAK (Control-Break) normally cause the program to exit. If Notify is called for os.Interrupt, ^C or ^BREAK will cause os.Interrupt to be sent on the channel, and the program will not exit. I'm confused how Interrupt can be all of: - guaranteed to be present - not implemented - calling Notify() can cause it to be sent on the channel when a user hits ^BREAK Searching the `os` package source code for Interrupt seems to show it's only defined for unix/posix GOOS's and not for Windows. It might be nice to add a short doc to the `os` package explaining how it gets sent (if I am reading correctly, from `runtime/os_windows.go:ctrlhandler1` and `runtime/sigqueue.go:sigsend`).",1,os os signal inconsistent documentation i m trying to define cleanup behavior in a windows program so i want to catch a signal do some cleanup and then exit the program i don t have a windows machine though so testing this is sort of tricky the docs for os interrupt state the only signal values guaranteed to be present in the os package on all systems are interrupt send the process an interrupt and kill force the process to exit interrupt is not implemented on windows using it with os process signal will return an error however the docs for os signal state under the windows section on windows a c control c or break control break normally cause the program to exit if notify is called for os interrupt c or break will cause os interrupt to be sent on the channel and the program will not exit i m confused how interrupt can be all of guaranteed to be present not implemented calling notify can cause it to be sent on the channel when a user hits break searching the os package source code for interrupt seems to show it s only defined for unix posix goos s and not for windows it might be nice to add a short doc to the os package explaining how it gets sent if i am reading correctly from runtime os windows go and runtime sigqueue go sigsend ,1 4069,2814167590.0,IssuesEvent,2015-05-18 18:30:28,golang/go,https://api.github.com/repos/golang/go,closed,"spec: ""TO"" != ""T0"" in spec",Documentation,"In [this example](https://github.com/golang/go/blob/master/doc/go_spec.html#L2608): ````go t.x // (*t.TO).x ```` I think it is supposed to read: ````go t.x // (*t.T0).x ```` ",1.0,"spec: ""TO"" != ""T0"" in spec - In [this example](https://github.com/golang/go/blob/master/doc/go_spec.html#L2608): ````go t.x // (*t.TO).x ```` I think it is supposed to read: ````go t.x // (*t.T0).x ```` ",1,spec to in spec in go t x t to x i think it is supposed to read go t x t x ,1 31246,5920374818.0,IssuesEvent,2017-05-22 20:07:23,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/cmd/callgraph: usage text suggests invalid code,Documentation,"The [usage](https://github.com/golang/tools/blob/bf4b54dc687c73b6ef63de8b8abf0ad3951e3edc/cmd/callgraph/main.go#L117) text of `x/tools/cmd/callgraph` command mentions: > e.g. Caller.Pkg.Object.Path yields the import path of the enclosing package. > Consult the go/ssa API documentation for details. > Examples: > > callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' \ > $GOROOT/src/net/http/triv.go | sort | uniq `Caller` is [`*ssa.Function`](https://godoc.org/golang.org/x/tools/go/ssa#Function). Its `Pkg` field is [`*ssa.Package`](https://godoc.org/golang.org/x/tools/go/ssa#Package). But `ssa.Package` struct doesn't contain either field or method named `Object`. So one gets the following error: ``` $ callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' $(go env GOROOT)/src/net/http/triv.go | sort | uniq callgraph: template: -format:1:9: executing ""-format"" at <.Caller.Pkg.Object.P...>: can't evaluate field Object in type *ssa.Package ``` I'm guessing that instead of `Caller.Pkg.Object.Path`, it should be `Caller.Pkg.Pkg.Path`: https://godoc.org/golang.org/x/tools/go/ssa#Package.Pkg That works as expected in my testing.",1.0,"x/tools/cmd/callgraph: usage text suggests invalid code - The [usage](https://github.com/golang/tools/blob/bf4b54dc687c73b6ef63de8b8abf0ad3951e3edc/cmd/callgraph/main.go#L117) text of `x/tools/cmd/callgraph` command mentions: > e.g. Caller.Pkg.Object.Path yields the import path of the enclosing package. > Consult the go/ssa API documentation for details. > Examples: > > callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' \ > $GOROOT/src/net/http/triv.go | sort | uniq `Caller` is [`*ssa.Function`](https://godoc.org/golang.org/x/tools/go/ssa#Function). Its `Pkg` field is [`*ssa.Package`](https://godoc.org/golang.org/x/tools/go/ssa#Package). But `ssa.Package` struct doesn't contain either field or method named `Object`. So one gets the following error: ``` $ callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' $(go env GOROOT)/src/net/http/triv.go | sort | uniq callgraph: template: -format:1:9: executing ""-format"" at <.Caller.Pkg.Object.P...>: can't evaluate field Object in type *ssa.Package ``` I'm guessing that instead of `Caller.Pkg.Object.Path`, it should be `Caller.Pkg.Pkg.Path`: https://godoc.org/golang.org/x/tools/go/ssa#Package.Pkg That works as expected in my testing.",1,x tools cmd callgraph usage text suggests invalid code the text of x tools cmd callgraph command mentions e g caller pkg object path yields the import path of the enclosing package consult the go ssa api documentation for details examples callgraph format caller pkg object path callee pkg object path goroot src net http triv go sort uniq caller is its pkg field is but ssa package struct doesn t contain either field or method named object so one gets the following error callgraph format caller pkg object path callee pkg object path go env goroot src net http triv go sort uniq callgraph template format executing format at can t evaluate field object in type ssa package i m guessing that instead of caller pkg object path it should be caller pkg pkg path that works as expected in my testing ,1 429278,30033557566.0,IssuesEvent,2023-06-27 11:14:00,golang/go,https://api.github.com/repos/golang/go,opened,doc: incomplete documentation for vanity import paths in combination with Go modules,Documentation,"https://go.dev/ref/mod#vcs documents the `` tag that needs to be hosted at the module path, with the concrete example of `golang.org/x/mod`. However, it doesn't document how the module path is determined, and which pages need to exist for that process. For example, a user can do `go get golang.org/x/mod/zip` in module mode. The documentation doesn't state whether `https://golang.org/x/mod/zip?go-get=1` needs to serve the meta tag or not. Some vanity paths, like `gioui.org` suggest that these subpages don't have to exist, and that `go get` walks up the path until it gets a successful response that specifies the module path. For example, `GOPROXY=direct go get gioui.org/widget/material` sends requests to the following URLs: ``` # get https://gioui.org/widget/material?go-get=1 # get https://gioui.org/widget?go-get=1 # get https://gioui.org/?go-get=1 # get https://gioui.org/widget?go-get=1: 404 Not Found (0.198s) # get https://gioui.org/widget/material?go-get=1: 404 Not Found (0.200s) # get https://gioui.org/?go-get=1: 200 OK (0.201s) ``` Out of these, only `https://gioui.org/?go-get=1` responds with a meta tag. https://pkg.go.dev/cmd/go@go1.21rc2#hdr-Remote_import_paths also contains documentation on vanity import paths, but doesn't discuss module paths. It does suggest, however, that only one request — to the full import path — is being made: > If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a tag in the document's HTML . This doesn't match the actual behavior of `go get` in module mode, but it does match `go get` in GOPATH mode. In fact, the previous example using gioui.org doesn't work in GOPATH mode, because gioui.org only serves the required meta tags for module paths, not for all possible import paths. ``` # get https://gioui.org/widget/material?go-get=1 # get https://gioui.org/widget/material?go-get=1: 404 Not Found (0.192s) package gioui.org/widget/material: unrecognized import path ""gioui.org/widget/material"": reading https://gioui.org/widget/material?go-get=1: 404 Not Found server response: no such package ``` It would be nice to clarify, in the documentation, whether one can rely on the fact that `go get` walks up the import path until it finds the module path. Assuming that one can, it would also be interesting to explore whether it's acceptable to do so, as that only works for modules, not GOPATH.",1.0,"doc: incomplete documentation for vanity import paths in combination with Go modules - https://go.dev/ref/mod#vcs documents the `` tag that needs to be hosted at the module path, with the concrete example of `golang.org/x/mod`. However, it doesn't document how the module path is determined, and which pages need to exist for that process. For example, a user can do `go get golang.org/x/mod/zip` in module mode. The documentation doesn't state whether `https://golang.org/x/mod/zip?go-get=1` needs to serve the meta tag or not. Some vanity paths, like `gioui.org` suggest that these subpages don't have to exist, and that `go get` walks up the path until it gets a successful response that specifies the module path. For example, `GOPROXY=direct go get gioui.org/widget/material` sends requests to the following URLs: ``` # get https://gioui.org/widget/material?go-get=1 # get https://gioui.org/widget?go-get=1 # get https://gioui.org/?go-get=1 # get https://gioui.org/widget?go-get=1: 404 Not Found (0.198s) # get https://gioui.org/widget/material?go-get=1: 404 Not Found (0.200s) # get https://gioui.org/?go-get=1: 200 OK (0.201s) ``` Out of these, only `https://gioui.org/?go-get=1` responds with a meta tag. https://pkg.go.dev/cmd/go@go1.21rc2#hdr-Remote_import_paths also contains documentation on vanity import paths, but doesn't discuss module paths. It does suggest, however, that only one request — to the full import path — is being made: > If the import path is not a known code hosting site and also lacks a version control qualifier, the go tool attempts to fetch the import over https/http and looks for a tag in the document's HTML . This doesn't match the actual behavior of `go get` in module mode, but it does match `go get` in GOPATH mode. In fact, the previous example using gioui.org doesn't work in GOPATH mode, because gioui.org only serves the required meta tags for module paths, not for all possible import paths. ``` # get https://gioui.org/widget/material?go-get=1 # get https://gioui.org/widget/material?go-get=1: 404 Not Found (0.192s) package gioui.org/widget/material: unrecognized import path ""gioui.org/widget/material"": reading https://gioui.org/widget/material?go-get=1: 404 Not Found server response: no such package ``` It would be nice to clarify, in the documentation, whether one can rely on the fact that `go get` walks up the import path until it finds the module path. Assuming that one can, it would also be interesting to explore whether it's acceptable to do so, as that only works for modules, not GOPATH.",1,doc incomplete documentation for vanity import paths in combination with go modules documents the tag that needs to be hosted at the module path with the concrete example of golang org x mod however it doesn t document how the module path is determined and which pages need to exist for that process for example a user can do go get golang org x mod zip in module mode the documentation doesn t state whether needs to serve the meta tag or not some vanity paths like gioui org suggest that these subpages don t have to exist and that go get walks up the path until it gets a successful response that specifies the module path for example goproxy direct go get gioui org widget material sends requests to the following urls get get get get not found get not found get ok out of these only responds with a meta tag also contains documentation on vanity import paths but doesn t discuss module paths it does suggest however that only one request — to the full import path — is being made if the import path is not a known code hosting site and also lacks a version control qualifier the go tool attempts to fetch the import over https http and looks for a tag in the document s html this doesn t match the actual behavior of go get in module mode but it does match go get in gopath mode in fact the previous example using gioui org doesn t work in gopath mode because gioui org only serves the required meta tags for module paths not for all possible import paths get get not found package gioui org widget material unrecognized import path gioui org widget material reading not found server response no such package it would be nice to clarify in the documentation whether one can rely on the fact that go get walks up the import path until it finds the module path assuming that one can it would also be interesting to explore whether it s acceptable to do so as that only works for modules not gopath ,1 9921,3337752428.0,IssuesEvent,2015-11-13 01:09:19,golang/go,https://api.github.com/repos/golang/go,closed,os: mention ErrInvalid for nil receivers,Documentation,"Methods on `*os.File` return `ErrInvalid` when the receiver is nil. This is, however, not documented anywhere. Usually this would be fine, if it weren't for a lot of documentation on methods saying `If there is an error, it will be of type *PathError`. Operating on nil `*os.File`s is a programming mistake and shouldn't be a common occurence, so it shouldn't complicate all of the documentation. However, a note in the package-level documentation could be an easy fix for a small inaccuracy in the rest of the documentation.",1.0,"os: mention ErrInvalid for nil receivers - Methods on `*os.File` return `ErrInvalid` when the receiver is nil. This is, however, not documented anywhere. Usually this would be fine, if it weren't for a lot of documentation on methods saying `If there is an error, it will be of type *PathError`. Operating on nil `*os.File`s is a programming mistake and shouldn't be a common occurence, so it shouldn't complicate all of the documentation. However, a note in the package-level documentation could be an easy fix for a small inaccuracy in the rest of the documentation.",1,os mention errinvalid for nil receivers methods on os file return errinvalid when the receiver is nil this is however not documented anywhere usually this would be fine if it weren t for a lot of documentation on methods saying if there is an error it will be of type patherror operating on nil os file s is a programming mistake and shouldn t be a common occurence so it shouldn t complicate all of the documentation however a note in the package level documentation could be an easy fix for a small inaccuracy in the rest of the documentation ,1 54833,7926717247.0,IssuesEvent,2018-07-06 04:00:40,golang/go,https://api.github.com/repos/golang/go,closed,x/vgo: fix installation instructions on README,Documentation WaitingForInfo,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 10.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? OSX 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64 ### What did you do? go get -u golang.org/x/vgo . If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? installation of vgo ### What did you see instead? It hung ### Solution change documentation to go get -u github.com/golang/vgo",1.0,"x/vgo: fix installation instructions on README - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 10.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? OSX 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64 ### What did you do? go get -u golang.org/x/vgo . If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? installation of vgo ### What did you see instead? It hung ### Solution change documentation to go get -u github.com/golang/vgo",1,x vgo fix installation instructions on readme please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env osx darwin kernel version sun dec pst root xnu release what did you do go get u golang org x vgo if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see installation of vgo what did you see instead it hung solution change documentation to go get u github com golang vgo,1 435607,30509701922.0,IssuesEvent,2023-07-18 19:46:38,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/go/packages: document that different package loads lead to different type identities,Documentation NeedsFix,"When loading the same set of package twice, user-defined types are not guaranteed to have the same type identity. This should be explicitly documented. See #61412 for an example where not understanding this property causes problems. cc: @findleyr @alandonovan ",1.0,"x/tools/go/packages: document that different package loads lead to different type identities - When loading the same set of package twice, user-defined types are not guaranteed to have the same type identity. This should be explicitly documented. See #61412 for an example where not understanding this property causes problems. cc: @findleyr @alandonovan ",1,x tools go packages document that different package loads lead to different type identities when loading the same set of package twice user defined types are not guaranteed to have the same type identity this should be explicitly documented see for an example where not understanding this property causes problems cc findleyr alandonovan ,1 65725,8837597166.0,IssuesEvent,2019-01-05 07:04:59,golang/go,https://api.github.com/repos/golang/go,opened,debug/gosym: mark LineTable.LineToPC and LineTable.PCToLine as deprecated,Documentation help wanted,"Both methods appear to be deprecated, according to their comments. We have a standard way of marking methods as deprecated; let's apply it here. This may be a good first issue for someone who wants to try out contributing. ",1.0,"debug/gosym: mark LineTable.LineToPC and LineTable.PCToLine as deprecated - Both methods appear to be deprecated, according to their comments. We have a standard way of marking methods as deprecated; let's apply it here. This may be a good first issue for someone who wants to try out contributing. ",1,debug gosym mark linetable linetopc and linetable pctoline as deprecated both methods appear to be deprecated according to their comments we have a standard way of marking methods as deprecated let s apply it here this may be a good first issue for someone who wants to try out contributing ,1 9538,3292672628.0,IssuesEvent,2015-10-30 15:37:49,golang/go,https://api.github.com/repos/golang/go,opened,testing: document that T and B are safe for concurrent calls,Documentation,"We never documented that t.Errorf and friends are safe to call concurrently from different goroutines. This came up in review, with unnecessary locking around calling methods on t. ",1.0,"testing: document that T and B are safe for concurrent calls - We never documented that t.Errorf and friends are safe to call concurrently from different goroutines. This came up in review, with unnecessary locking around calling methods on t. ",1,testing document that t and b are safe for concurrent calls we never documented that t errorf and friends are safe to call concurrently from different goroutines this came up in review with unnecessary locking around calling methods on t ,1 34246,6306261836.0,IssuesEvent,2017-07-21 20:31:35,golang/go,https://api.github.com/repos/golang/go,opened,unclear docs causing races in sql/driver implementations,Documentation,"### What version of Go are you using (`go version`)? `go version go1.8.3 darwin/amd64` ### What did you do? Unlike `Conn` or `Stmt` there's no guidance on `Tx` indicating how the stdlib uses implementations. This seems to cause bugs in driver implementations, as a `Tx` is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package. This came up as I was debugging [a panic inside of lib/pq](https://github.com/lib/pq/issues/614) and discovered it was a data race due to the authors not assuming that their `Tx` would have to deal with calls from multiple goroutines. Out of curiosity, I looked at `go-sql-driver/mysql` and the lack of a race there seems like a happy accident - the Context expiring occasionally causes [an internal error to bubble up](https://github.com/go-sql-driver/mysql/blob/a825be04c652d01442384e9dcdf2cdc3f1eda67f/packets.go#L441-L443), since the authors appear to aggressively check their invariants. I'm not sure whether this is a documentation problem or if there's something database/sql could do to make life easier for driver implementors. ",1.0,"unclear docs causing races in sql/driver implementations - ### What version of Go are you using (`go version`)? `go version go1.8.3 darwin/amd64` ### What did you do? Unlike `Conn` or `Stmt` there's no guidance on `Tx` indicating how the stdlib uses implementations. This seems to cause bugs in driver implementations, as a `Tx` is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package. This came up as I was debugging [a panic inside of lib/pq](https://github.com/lib/pq/issues/614) and discovered it was a data race due to the authors not assuming that their `Tx` would have to deal with calls from multiple goroutines. Out of curiosity, I looked at `go-sql-driver/mysql` and the lack of a race there seems like a happy accident - the Context expiring occasionally causes [an internal error to bubble up](https://github.com/go-sql-driver/mysql/blob/a825be04c652d01442384e9dcdf2cdc3f1eda67f/packets.go#L441-L443), since the authors appear to aggressively check their invariants. I'm not sure whether this is a documentation problem or if there's something database/sql could do to make life easier for driver implementors. ",1,unclear docs causing races in sql driver implementations what version of go are you using go version go version darwin what did you do unlike conn or stmt there s no guidance on tx indicating how the stdlib uses implementations this seems to cause bugs in driver implementations as a tx is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package this came up as i was debugging and discovered it was a data race due to the authors not assuming that their tx would have to deal with calls from multiple goroutines out of curiosity i looked at go sql driver mysql and the lack of a race there seems like a happy accident the context expiring occasionally causes since the authors appear to aggressively check their invariants i m not sure whether this is a documentation problem or if there s something database sql could do to make life easier for driver implementors ,1 307849,23219560099.0,IssuesEvent,2022-08-02 16:50:37,golang/go,https://api.github.com/repos/golang/go,opened,doc: write Go 1.20 release notes,Documentation NeedsFix release-blocker umbrella,"This is the tracking issue for writing the Go 1.20 Release Notes. When the Go 1.19 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #51400, #47694, #44513, etc.",1.0,"doc: write Go 1.20 release notes - This is the tracking issue for writing the Go 1.20 Release Notes. When the Go 1.19 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #51400, #47694, #44513, etc.",1,doc write go release notes this is the tracking issue for writing the go release notes when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 60541,8443339608.0,IssuesEvent,2018-10-18 15:21:18,golang/go,https://api.github.com/repos/golang/go,closed,syscall/js: unclear what the zero js.Value represents,Arch-Wasm Documentation NeedsDecision,"The godoc of [`js.Value`](https://godoc.org/syscall/js#Value) type currently says: > Value represents a JavaScript value. It's not easy to figure out what the zero value represents, even after reading the rest of `syscall/js` docs. This question came up when I had a function with the return types `(js.Value, error)` and I wanted to figure out what `js.Value` to return when an error happened. Typically, one returns the zero value, but it helps to understand what the zero value of that type represents. From looking at the implementation, I understand that the zero `js.Value` value currently represents the JavaScript number zero, is that right @neelance? I.e.: ```Go js.Value{} == js.ValueOf(int(0)) // true js.Value{}.Type() == js.TypeNumber // true ``` It's also possible that what the zero `js.Value` value represents is considered an internal implementation detail and not meant to be a part of the public API. Hence, users shouldn't rely on it to have any well-defined and stable meaning. I think it would be helpful to document what the zero value represents, so people can answer this question by reading the documentation. Depending on the intention, perhaps one of these: ```Go // Value represents a JavaScript value. // The zero value for a Value represents the JavaScript number 0. type Value ... ``` (See https://godoc.org/math/big#Int documentation for a similar example.) Or (an improved version of): ```Go // Value represents a JavaScript value. // // The zero value for Value is undefined. It is not intended for direct use // by clients, other than to signify that the value is not defined. type Value ... ``` /cc @neelance",1.0,"syscall/js: unclear what the zero js.Value represents - The godoc of [`js.Value`](https://godoc.org/syscall/js#Value) type currently says: > Value represents a JavaScript value. It's not easy to figure out what the zero value represents, even after reading the rest of `syscall/js` docs. This question came up when I had a function with the return types `(js.Value, error)` and I wanted to figure out what `js.Value` to return when an error happened. Typically, one returns the zero value, but it helps to understand what the zero value of that type represents. From looking at the implementation, I understand that the zero `js.Value` value currently represents the JavaScript number zero, is that right @neelance? I.e.: ```Go js.Value{} == js.ValueOf(int(0)) // true js.Value{}.Type() == js.TypeNumber // true ``` It's also possible that what the zero `js.Value` value represents is considered an internal implementation detail and not meant to be a part of the public API. Hence, users shouldn't rely on it to have any well-defined and stable meaning. I think it would be helpful to document what the zero value represents, so people can answer this question by reading the documentation. Depending on the intention, perhaps one of these: ```Go // Value represents a JavaScript value. // The zero value for a Value represents the JavaScript number 0. type Value ... ``` (See https://godoc.org/math/big#Int documentation for a similar example.) Or (an improved version of): ```Go // Value represents a JavaScript value. // // The zero value for Value is undefined. It is not intended for direct use // by clients, other than to signify that the value is not defined. type Value ... ``` /cc @neelance",1,syscall js unclear what the zero js value represents the godoc of type currently says value represents a javascript value it s not easy to figure out what the zero value represents even after reading the rest of syscall js docs this question came up when i had a function with the return types js value error and i wanted to figure out what js value to return when an error happened typically one returns the zero value but it helps to understand what the zero value of that type represents from looking at the implementation i understand that the zero js value value currently represents the javascript number zero is that right neelance i e go js value js valueof int true js value type js typenumber true it s also possible that what the zero js value value represents is considered an internal implementation detail and not meant to be a part of the public api hence users shouldn t rely on it to have any well defined and stable meaning i think it would be helpful to document what the zero value represents so people can answer this question by reading the documentation depending on the intention perhaps one of these go value represents a javascript value the zero value for a value represents the javascript number type value see documentation for a similar example or an improved version of go value represents a javascript value the zero value for value is undefined it is not intended for direct use by clients other than to signify that the value is not defined type value cc neelance,1 19286,6705593849.0,IssuesEvent,2017-10-12 01:20:23,golang/go,https://api.github.com/repos/golang/go,closed,"x/build: build.golang.org should link to Gerrit, not GitHub commits",Builders,"The left column of build.golang.org has Git commit hashes, and it links to https://github.com/golang/go/commit/ But all of us most commonly use Gerrit to view commits. We should probably do the same here. The URL should change to https://go-review.googlesource.com/q/ Not sure who, if anyone, is in charge of build.golang.org these days. /cc @andybons @adams-sarah",1.0,"x/build: build.golang.org should link to Gerrit, not GitHub commits - The left column of build.golang.org has Git commit hashes, and it links to https://github.com/golang/go/commit/ But all of us most commonly use Gerrit to view commits. We should probably do the same here. The URL should change to https://go-review.googlesource.com/q/ Not sure who, if anyone, is in charge of build.golang.org these days. /cc @andybons @adams-sarah",0,x build build golang org should link to gerrit not github commits the left column of build golang org has git commit hashes and it links to but all of us most commonly use gerrit to view commits we should probably do the same here the url should change to not sure who if anyone is in charge of build golang org these days cc andybons adams sarah,0 215143,16652516033.0,IssuesEvent,2021-06-05 00:15:14,golang/go,https://api.github.com/repos/golang/go,opened,syscall: TestStdioAreInheritable fails on windows-arm64-aws because it tries to build a library using an unsupported build mode,NeedsInvestigation Testing,"The new-to-Go 1.17 windows/arm64 port (#36439) at this time doesn't support the c-shared build mode (#46549). `TestStdioAreInheritable` was added in [CL 316269](https://golang.org/cl/316269) and currently makes use of the c-shared build mode. ​The test fails as detected by the `windows-arm64-aws` builder: ``` --- FAIL: TestStdioAreInheritable (0.08s) ​syscall_windows_test.go:110: failed to build go library: exit status 1 ​-buildmode=c-shared not supported on windows/arm64 FAIL FAIL syscall 0.353s ``` Source: https://storage.googleapis.com/go-build-log/78592762/windows-arm64-aws_f90b24c9.log from [CL 323991](https://go-review.googlesource.com/c/go/+/323991/2#message-9fca96040291eda63926f45afdbace7c9b9f101f). The test can be skipped on windows/arm64 since that port doesn't meet the minimum requirements ([CL 323992](https://golang.org/cl/323992) adds this skip). Perhaps the test can be updated not to require c-shared build mode. As another option, the test may stop failing if the c-shared build mode gets enabled for windows/arm64 port. CC @alexbrainman, @ianlancetaylor.",1.0,"syscall: TestStdioAreInheritable fails on windows-arm64-aws because it tries to build a library using an unsupported build mode - The new-to-Go 1.17 windows/arm64 port (#36439) at this time doesn't support the c-shared build mode (#46549). `TestStdioAreInheritable` was added in [CL 316269](https://golang.org/cl/316269) and currently makes use of the c-shared build mode. ​The test fails as detected by the `windows-arm64-aws` builder: ``` --- FAIL: TestStdioAreInheritable (0.08s) ​syscall_windows_test.go:110: failed to build go library: exit status 1 ​-buildmode=c-shared not supported on windows/arm64 FAIL FAIL syscall 0.353s ``` Source: https://storage.googleapis.com/go-build-log/78592762/windows-arm64-aws_f90b24c9.log from [CL 323991](https://go-review.googlesource.com/c/go/+/323991/2#message-9fca96040291eda63926f45afdbace7c9b9f101f). The test can be skipped on windows/arm64 since that port doesn't meet the minimum requirements ([CL 323992](https://golang.org/cl/323992) adds this skip). Perhaps the test can be updated not to require c-shared build mode. As another option, the test may stop failing if the c-shared build mode gets enabled for windows/arm64 port. CC @alexbrainman, @ianlancetaylor.",0,syscall teststdioareinheritable fails on windows aws because it tries to build a library using an unsupported build mode the new to go windows port at this time doesn t support the c shared build mode teststdioareinheritable was added in and currently makes use of the c shared build mode ​the test fails as detected by the windows aws builder fail teststdioareinheritable ​syscall windows test go failed to build go library exit status ​ buildmode c shared not supported on windows fail fail syscall source from the test can be skipped on windows since that port doesn t meet the minimum requirements adds this skip perhaps the test can be updated not to require c shared build mode as another option the test may stop failing if the c shared build mode gets enabled for windows port cc alexbrainman ianlancetaylor ,0 88198,25341248279.0,IssuesEvent,2022-11-18 21:53:14,golang/go,https://api.github.com/repos/golang/go,closed,gerrit: implement CL auto-submit,Builders NeedsFix FeatureRequest,"(similar to #12482, but this issue is intended to track the work of actually implementing and deploying this functionality) Authors should be able to add a ""Auto-Submit"" label to CLs, such that once all submission requirements are met the CL is automatically submitted. The usage ""Auto-Submit"" label should be restricted to the existing 'approvers' Gerrit group. The basic conditions for triggering auto-submit should be (the first two of these can be boiled down to 'submittable' according to Gerrit): * Trusted * Code-Review+2 * TryBot-Result+1 * No unresolved comments The one main open question is what restrictions should be in place around 'unreviewed' changes. Currently once a reviewer has +2'd a CL, if the author is in 'approvers' they can make changes to the CL before it is submitted (this is a common pattern, as reviewers will often +2 with small comments that the author should address before submitting). If we maintain the ""Auto-Submit"" label across patch sets, this behavior would essentially be maintained when using auto-submit functionality (since any comments would still need to be resolved, and a new TryBot-Result+1 would be required), although reviewers may be slightly less vigilante about looking at unreviewed changes which are submitted. Since the author would still need to re-label with ""Run-TryBot"" after pushing a new patch set, it seems reasonable though to explicitly require them to also re-label with ""Auto-Submit"". This wouldn't really provide any extra security, but would make the author explicitly say they want their new patch set auto-submitted. Another approach would be to require there be no new patch set between the last Code-Review+2 and the auto-submit being triggered. This would explicitly require the reviewer to approve any changes since their last review, but doesn't necessarily add any additional security, since the author would still be able to manually submit their patch, and seems likely to just reduce the value of this feature. I'm in favor of not implementing any additional restrictions, and simply saying if the change has Code-Review+2 and there are no unresolved comments (and all other submittability(?) requirements are satisfied), allowing follow-up unreviewed changes to be submitted. This would maintain the status-quo, relying on the assumption that members of the 'approvers' group should be generally trusted not to submit major unreviewed changes and that reviewers should be aware of what unreviewed changes were submitted (i.e. that there weren't changes outside of what they requested in the submitted CL). There are two major components of this change: * Adding the auto-submit functionality to x/build/cmd/gopherbot * Adding the ""Auto-Submit"" label to the gerrit config cc @golang/release @golang/security ",1.0,"gerrit: implement CL auto-submit - (similar to #12482, but this issue is intended to track the work of actually implementing and deploying this functionality) Authors should be able to add a ""Auto-Submit"" label to CLs, such that once all submission requirements are met the CL is automatically submitted. The usage ""Auto-Submit"" label should be restricted to the existing 'approvers' Gerrit group. The basic conditions for triggering auto-submit should be (the first two of these can be boiled down to 'submittable' according to Gerrit): * Trusted * Code-Review+2 * TryBot-Result+1 * No unresolved comments The one main open question is what restrictions should be in place around 'unreviewed' changes. Currently once a reviewer has +2'd a CL, if the author is in 'approvers' they can make changes to the CL before it is submitted (this is a common pattern, as reviewers will often +2 with small comments that the author should address before submitting). If we maintain the ""Auto-Submit"" label across patch sets, this behavior would essentially be maintained when using auto-submit functionality (since any comments would still need to be resolved, and a new TryBot-Result+1 would be required), although reviewers may be slightly less vigilante about looking at unreviewed changes which are submitted. Since the author would still need to re-label with ""Run-TryBot"" after pushing a new patch set, it seems reasonable though to explicitly require them to also re-label with ""Auto-Submit"". This wouldn't really provide any extra security, but would make the author explicitly say they want their new patch set auto-submitted. Another approach would be to require there be no new patch set between the last Code-Review+2 and the auto-submit being triggered. This would explicitly require the reviewer to approve any changes since their last review, but doesn't necessarily add any additional security, since the author would still be able to manually submit their patch, and seems likely to just reduce the value of this feature. I'm in favor of not implementing any additional restrictions, and simply saying if the change has Code-Review+2 and there are no unresolved comments (and all other submittability(?) requirements are satisfied), allowing follow-up unreviewed changes to be submitted. This would maintain the status-quo, relying on the assumption that members of the 'approvers' group should be generally trusted not to submit major unreviewed changes and that reviewers should be aware of what unreviewed changes were submitted (i.e. that there weren't changes outside of what they requested in the submitted CL). There are two major components of this change: * Adding the auto-submit functionality to x/build/cmd/gopherbot * Adding the ""Auto-Submit"" label to the gerrit config cc @golang/release @golang/security ",0,gerrit implement cl auto submit similar to but this issue is intended to track the work of actually implementing and deploying this functionality authors should be able to add a auto submit label to cls such that once all submission requirements are met the cl is automatically submitted the usage auto submit label should be restricted to the existing approvers gerrit group the basic conditions for triggering auto submit should be the first two of these can be boiled down to submittable according to gerrit trusted code review trybot result no unresolved comments the one main open question is what restrictions should be in place around unreviewed changes currently once a reviewer has d a cl if the author is in approvers they can make changes to the cl before it is submitted this is a common pattern as reviewers will often with small comments that the author should address before submitting if we maintain the auto submit label across patch sets this behavior would essentially be maintained when using auto submit functionality since any comments would still need to be resolved and a new trybot result would be required although reviewers may be slightly less vigilante about looking at unreviewed changes which are submitted since the author would still need to re label with run trybot after pushing a new patch set it seems reasonable though to explicitly require them to also re label with auto submit this wouldn t really provide any extra security but would make the author explicitly say they want their new patch set auto submitted another approach would be to require there be no new patch set between the last code review and the auto submit being triggered this would explicitly require the reviewer to approve any changes since their last review but doesn t necessarily add any additional security since the author would still be able to manually submit their patch and seems likely to just reduce the value of this feature i m in favor of not implementing any additional restrictions and simply saying if the change has code review and there are no unresolved comments and all other submittability requirements are satisfied allowing follow up unreviewed changes to be submitted this would maintain the status quo relying on the assumption that members of the approvers group should be generally trusted not to submit major unreviewed changes and that reviewers should be aware of what unreviewed changes were submitted i e that there weren t changes outside of what they requested in the submitted cl there are two major components of this change adding the auto submit functionality to x build cmd gopherbot adding the auto submit label to the gerrit config cc golang release golang security ,0 42015,6961452656.0,IssuesEvent,2017-12-08 09:32:54,golang/go,https://api.github.com/repos/golang/go,closed,doc: editors.html uses Gogland (deprecated),Documentation,"Hi! JetBrains renamed their Go IDE from [Gogland to Goland](https://blog.jetbrains.com/go/2017/11/02/announcing-goland-former-gogland-eap-18-final-product-name-templates-support-and-more/). It's time to update the page [Editor plugins and IDEs](https://golang.org/doc/editors.html) on main site. Thanks.",1.0,"doc: editors.html uses Gogland (deprecated) - Hi! JetBrains renamed their Go IDE from [Gogland to Goland](https://blog.jetbrains.com/go/2017/11/02/announcing-goland-former-gogland-eap-18-final-product-name-templates-support-and-more/). It's time to update the page [Editor plugins and IDEs](https://golang.org/doc/editors.html) on main site. Thanks.",1,doc editors html uses gogland deprecated hi jetbrains renamed their go ide from it s time to update the page on main site thanks ,1 82545,10295314096.0,IssuesEvent,2019-08-27 20:54:09,golang/go,https://api.github.com/repos/golang/go,closed,net: document where service names come from?,Documentation NeedsFix Suggested help wanted,"Found in `net/http/server.go`: ``` type Server struct { Addr string // TCP address to listen on, "":http"" if empty ``` What is this "":http"" exactly? Presumably an alias, but I can't find any concrete documentation to know what it resolves to. https://github.com/golang/go/blob/964fe4b80ff7a9e5490f11de0e216ae34a019ebc/src/net/http/server.go#L2477",1.0,"net: document where service names come from? - Found in `net/http/server.go`: ``` type Server struct { Addr string // TCP address to listen on, "":http"" if empty ``` What is this "":http"" exactly? Presumably an alias, but I can't find any concrete documentation to know what it resolves to. https://github.com/golang/go/blob/964fe4b80ff7a9e5490f11de0e216ae34a019ebc/src/net/http/server.go#L2477",1,net document where service names come from found in net http server go type server struct addr string tcp address to listen on http if empty what is this http exactly presumably an alias but i can t find any concrete documentation to know what it resolves to ,1 97001,28074429014.0,IssuesEvent,2023-03-29 21:51:47,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env: Add builder for GOOS=wasip1 GOARCH=wasm,Builders NeedsFix arch-wasm,"#58141 adds the new GOOS=wasip1 GOARCH=wasm port. This new port will require a new builder that can run the standard library tests. I intend to submit a CL to add this.",1.0,"x/build/env: Add builder for GOOS=wasip1 GOARCH=wasm - #58141 adds the new GOOS=wasip1 GOARCH=wasm port. This new port will require a new builder that can run the standard library tests. I intend to submit a CL to add this.",0,x build env add builder for goos goarch wasm adds the new goos goarch wasm port this new port will require a new builder that can run the standard library tests i intend to submit a cl to add this ,0 36234,6521145108.0,IssuesEvent,2017-08-28 19:22:22,golang/go,https://api.github.com/repos/golang/go,closed,net/http: update docs for LocalAddrContextKey,Documentation,"### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? amd64 ### What did you do? r is a *http.Request r.Context().Value(http.LocalAddrContextKey) ### What did you expect to see? Listener Addr ### What did you see instead? Connection Local Addr I replied to an older closed issue, I'm not sure if it will be seen or not so I am posting again: https://github.com/golang/go/issues/18686 It seems that the functionality of LocalAddrContextKey has changed to what it was possibly intended to do, if so it should be mentioned in the patch notes source change: https://go-review.googlesource.com/c/go/+/35490/10/src/net/http/server.go",1.0,"net/http: update docs for LocalAddrContextKey - ### What version of Go are you using (`go version`)? 1.9 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? amd64 ### What did you do? r is a *http.Request r.Context().Value(http.LocalAddrContextKey) ### What did you expect to see? Listener Addr ### What did you see instead? Connection Local Addr I replied to an older closed issue, I'm not sure if it will be seen or not so I am posting again: https://github.com/golang/go/issues/18686 It seems that the functionality of LocalAddrContextKey has changed to what it was possibly intended to do, if so it should be mentioned in the patch notes source change: https://go-review.googlesource.com/c/go/+/35490/10/src/net/http/server.go",1,net http update docs for localaddrcontextkey what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env what did you do r is a http request r context value http localaddrcontextkey what did you expect to see listener addr what did you see instead connection local addr i replied to an older closed issue i m not sure if it will be seen or not so i am posting again it seems that the functionality of localaddrcontextkey has changed to what it was possibly intended to do if so it should be mentioned in the patch notes source change ,1 58079,8228461086.0,IssuesEvent,2018-09-07 05:27:25,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go test all is under-documented,Documentation,"### What version of Go are you using (`go version`)? ``` $ go version go version go1.11 darwin/amd64 ``` ### Issue How do I get help for `go test all`? `go help test all` doesn't work, ditto `go test help all`, `go help test` doesn't have documentation for it, and docs [1] [2] dont mention it. Perhaps I'm missing something - sorry if so. 1: https://github.com/golang/go/wiki/Modules#installing-and-activating-module-support 2: https://golang.org/pkg/testing/",1.0,"cmd/go: go test all is under-documented - ### What version of Go are you using (`go version`)? ``` $ go version go version go1.11 darwin/amd64 ``` ### Issue How do I get help for `go test all`? `go help test all` doesn't work, ditto `go test help all`, `go help test` doesn't have documentation for it, and docs [1] [2] dont mention it. Perhaps I'm missing something - sorry if so. 1: https://github.com/golang/go/wiki/Modules#installing-and-activating-module-support 2: https://golang.org/pkg/testing/",1,cmd go go test all is under documented what version of go are you using go version go version go version darwin issue how do i get help for go test all go help test all doesn t work ditto go test help all go help test doesn t have documentation for it and docs dont mention it perhaps i m missing something sorry if so ,1 39153,6725161212.0,IssuesEvent,2017-10-17 03:21:45,golang/go,https://api.github.com/repos/golang/go,opened,runtime: GOROOT() docs are confusing,Documentation,"The docs say: ``` GOROOT returns the root of the Go tree. It uses the GOROOT environment variable, if set, or else the root used during the Go build. ``` Thus I expect this would print ""Hi!"": ```go package main import ( ""fmt"" ""log"" ""os"" ""runtime"" ) func main() { err := os.Setenv(""GOROOT"", ""Hi!"") if err != nil { log.Fatal(err) } fmt.Println(runtime.GOROOT()) } ``` However, this prints my real goroot, not ""Hi!"". Either GOROOT() should actually check the environment variable when called, or the docs should be clarified to specify that it returns the GOROOT environment variable set at init() time.",1.0,"runtime: GOROOT() docs are confusing - The docs say: ``` GOROOT returns the root of the Go tree. It uses the GOROOT environment variable, if set, or else the root used during the Go build. ``` Thus I expect this would print ""Hi!"": ```go package main import ( ""fmt"" ""log"" ""os"" ""runtime"" ) func main() { err := os.Setenv(""GOROOT"", ""Hi!"") if err != nil { log.Fatal(err) } fmt.Println(runtime.GOROOT()) } ``` However, this prints my real goroot, not ""Hi!"". Either GOROOT() should actually check the environment variable when called, or the docs should be clarified to specify that it returns the GOROOT environment variable set at init() time.",1,runtime goroot docs are confusing the docs say goroot returns the root of the go tree it uses the goroot environment variable if set or else the root used during the go build thus i expect this would print hi go package main import fmt log os runtime func main err os setenv goroot hi if err nil log fatal err fmt println runtime goroot however this prints my real goroot not hi either goroot should actually check the environment variable when called or the docs should be clarified to specify that it returns the goroot environment variable set at init time ,1 73211,9653282168.0,IssuesEvent,2019-05-19 02:25:26,golang/go,https://api.github.com/repos/golang/go,opened,net/http/httptest: deprecate ResponseRecorder.Header method as well,Documentation NeedsFix,"(This is a continuation of #25763 and #16717.) The `httptest.ResponseRecorder.HeaderMap` struct field was deprecated in [CL 117675](https://golang.org/cl/117675), with the deprecation notice pointing users to the `Response.Header` map as returned by the `Result` method. This was to resolve issue #25763 (which provides rationale for why that was done). However, there's also a `ResponseRecorder.Header` method which does little more than provide direct access to the `HeaderMap` field (it also initializes the map if it's `nil`): ```Go // Header returns the response headers. func (rw *ResponseRecorder) Header() http.Header { m := rw.HeaderMap if m == nil { m = make(http.Header) rw.HeaderMap = m } return m } ``` This puts users in an awkward position. If they read the deprecation notice on the `HeaderMap` field (and understand the rationale for why it was deprecated by reading through issue #25763), and also know the internal implementation details of the `Header` method, they'll know that they shouldn't be using the `Header` method either. If they don't know the internal implementation details of the `Header` method, they won't know how it differs from the `Response.Header` map as returned by the `Result` method and how to decide which one to use. Users shouldn't have to read the internal implementation of methods and make these kind of deductions. If the `HeaderMap` field is deprecated, the current `Header` method should be too: ```diff -// Header returns the response headers. +// Header returns the response headers explicitly set by the Handler. +// It is an internal detail. +// +// Deprecated: Header exists for historical compatibility +// and should not be used. To access the headers returned by a handler, +// use the Response.Header map as returned by the Result method. func (rw *ResponseRecorder) Header() http.Header { ``` /cc @cespare @bradfitz @dominikh",1.0,"net/http/httptest: deprecate ResponseRecorder.Header method as well - (This is a continuation of #25763 and #16717.) The `httptest.ResponseRecorder.HeaderMap` struct field was deprecated in [CL 117675](https://golang.org/cl/117675), with the deprecation notice pointing users to the `Response.Header` map as returned by the `Result` method. This was to resolve issue #25763 (which provides rationale for why that was done). However, there's also a `ResponseRecorder.Header` method which does little more than provide direct access to the `HeaderMap` field (it also initializes the map if it's `nil`): ```Go // Header returns the response headers. func (rw *ResponseRecorder) Header() http.Header { m := rw.HeaderMap if m == nil { m = make(http.Header) rw.HeaderMap = m } return m } ``` This puts users in an awkward position. If they read the deprecation notice on the `HeaderMap` field (and understand the rationale for why it was deprecated by reading through issue #25763), and also know the internal implementation details of the `Header` method, they'll know that they shouldn't be using the `Header` method either. If they don't know the internal implementation details of the `Header` method, they won't know how it differs from the `Response.Header` map as returned by the `Result` method and how to decide which one to use. Users shouldn't have to read the internal implementation of methods and make these kind of deductions. If the `HeaderMap` field is deprecated, the current `Header` method should be too: ```diff -// Header returns the response headers. +// Header returns the response headers explicitly set by the Handler. +// It is an internal detail. +// +// Deprecated: Header exists for historical compatibility +// and should not be used. To access the headers returned by a handler, +// use the Response.Header map as returned by the Result method. func (rw *ResponseRecorder) Header() http.Header { ``` /cc @cespare @bradfitz @dominikh",1,net http httptest deprecate responserecorder header method as well this is a continuation of and the httptest responserecorder headermap struct field was deprecated in with the deprecation notice pointing users to the response header map as returned by the result method this was to resolve issue which provides rationale for why that was done however there s also a responserecorder header method which does little more than provide direct access to the headermap field it also initializes the map if it s nil go header returns the response headers func rw responserecorder header http header m rw headermap if m nil m make http header rw headermap m return m this puts users in an awkward position if they read the deprecation notice on the headermap field and understand the rationale for why it was deprecated by reading through issue and also know the internal implementation details of the header method they ll know that they shouldn t be using the header method either if they don t know the internal implementation details of the header method they won t know how it differs from the response header map as returned by the result method and how to decide which one to use users shouldn t have to read the internal implementation of methods and make these kind of deductions if the headermap field is deprecated the current header method should be too diff header returns the response headers header returns the response headers explicitly set by the handler it is an internal detail deprecated header exists for historical compatibility and should not be used to access the headers returned by a handler use the response header map as returned by the result method func rw responserecorder header http header cc cespare bradfitz dominikh,1 13551,3738856939.0,IssuesEvent,2016-03-09 00:53:05,golang/go,https://api.github.com/repos/golang/go,closed,website: https://golang.org/doc/contribute.html uses old Gerrit link,Documentation,"https://golang.org/doc/contribute.html, https://github.com/golang/go/blob/master/CONTRIBUTING.md, and https://github.com/golang/go/blob/master/doc/contribute.html link to https://code.google.com/p/gerrit/. It's not a big deal for the first and third link, but https://github.com/golang/go/blob/master/CONTRIBUTING.md doesn't link to Google's Gerrit instance at all.",1.0,"website: https://golang.org/doc/contribute.html uses old Gerrit link - https://golang.org/doc/contribute.html, https://github.com/golang/go/blob/master/CONTRIBUTING.md, and https://github.com/golang/go/blob/master/doc/contribute.html link to https://code.google.com/p/gerrit/. It's not a big deal for the first and third link, but https://github.com/golang/go/blob/master/CONTRIBUTING.md doesn't link to Google's Gerrit instance at all.",1,website uses old gerrit link and link to it s not a big deal for the first and third link but doesn t link to google s gerrit instance at all ,1 24535,7523878604.0,IssuesEvent,2018-04-13 03:45:30,golang/go,https://api.github.com/repos/golang/go,closed,x/build/maintner: two Gerrit CLs have unexpected Status value,Builders NeedsInvestigation,"[`maintner.GerritCL.Status`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Status) is documented as: ```Go // Status will be ""merged"", ""abandoned"", ""new"", or ""draft"". Status string ``` That's mostly true, except for 2 CLs in the `go` repo: ``` 2018/04/05 21:51:56 empty status for CL 44073 2018/04/05 21:51:56 empty status for CL 44072 ``` Those 2 CLs have empty string value in `Status` field. Either the documentation needs to be updated, or this is bug and those 2 CLs shouldn't have empty status.",1.0,"x/build/maintner: two Gerrit CLs have unexpected Status value - [`maintner.GerritCL.Status`](https://godoc.org/golang.org/x/build/maintner#GerritCL.Status) is documented as: ```Go // Status will be ""merged"", ""abandoned"", ""new"", or ""draft"". Status string ``` That's mostly true, except for 2 CLs in the `go` repo: ``` 2018/04/05 21:51:56 empty status for CL 44073 2018/04/05 21:51:56 empty status for CL 44072 ``` Those 2 CLs have empty string value in `Status` field. Either the documentation needs to be updated, or this is bug and those 2 CLs shouldn't have empty status.",0,x build maintner two gerrit cls have unexpected status value is documented as go status will be merged abandoned new or draft status string that s mostly true except for cls in the go repo empty status for cl empty status for cl those cls have empty string value in status field either the documentation needs to be updated or this is bug and those cls shouldn t have empty status ,0 4820,3455904599.0,IssuesEvent,2015-12-17 22:15:21,golang/go,https://api.github.com/repos/golang/go,opened,x/build/cmd/release: run make.bash instead of all.bash if all.bash passed previously,Builders,"cmd/release used to be fast and only ran make.bash. Now it runs all.bash, which is slow. But if all.bash already succeeded in the past there's no need to run the tests again. Maybe consult build.golang.org and ask if it already succeeded, and then switch to make.bash instead? /cc @broady ",1.0,"x/build/cmd/release: run make.bash instead of all.bash if all.bash passed previously - cmd/release used to be fast and only ran make.bash. Now it runs all.bash, which is slow. But if all.bash already succeeded in the past there's no need to run the tests again. Maybe consult build.golang.org and ask if it already succeeded, and then switch to make.bash instead? /cc @broady ",0,x build cmd release run make bash instead of all bash if all bash passed previously cmd release used to be fast and only ran make bash now it runs all bash which is slow but if all bash already succeeded in the past there s no need to run the tests again maybe consult build golang org and ask if it already succeeded and then switch to make bash instead cc broady ,0 271221,20625531878.0,IssuesEvent,2022-03-07 22:04:35,golang/go,https://api.github.com/repos/golang/go,opened,x/website: update to latest spec just before release,Documentation release-blocker,"To get the most up-to-date spec into the 1.18 release, rather than cherry-picking possibly multiple CLs until the release, we should create a single CL in the release branch which contains a 1:1 copy of the latest spec at tip. cc: @dmitshur ",1.0,"x/website: update to latest spec just before release - To get the most up-to-date spec into the 1.18 release, rather than cherry-picking possibly multiple CLs until the release, we should create a single CL in the release branch which contains a 1:1 copy of the latest spec at tip. cc: @dmitshur ",1,x website update to latest spec just before release to get the most up to date spec into the release rather than cherry picking possibly multiple cls until the release we should create a single cl in the release branch which contains a copy of the latest spec at tip cc dmitshur ,1 43381,7044306113.0,IssuesEvent,2017-12-31 21:50:37,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/bn256: document that bn256 is weak,Documentation,"Due to recent improvements in calculating discrete logs [1], the BN-256 curve provides less than 128 bits of security. One estimate is that BN-256 provides closer to 96 bits of security. Trevor wrote a good summary of the situation [2]. The package comment for x/crypto/bn256 should note this weakness. [1] https://eprint.iacr.org/2015/1027 [2] https://moderncrypto.org/mail-archive/curves/2016/000740.html cc @agl @trevp",1.0,"x/crypto/bn256: document that bn256 is weak - Due to recent improvements in calculating discrete logs [1], the BN-256 curve provides less than 128 bits of security. One estimate is that BN-256 provides closer to 96 bits of security. Trevor wrote a good summary of the situation [2]. The package comment for x/crypto/bn256 should note this weakness. [1] https://eprint.iacr.org/2015/1027 [2] https://moderncrypto.org/mail-archive/curves/2016/000740.html cc @agl @trevp",1,x crypto document that is weak due to recent improvements in calculating discrete logs the bn curve provides less than bits of security one estimate is that bn provides closer to bits of security trevor wrote a good summary of the situation the package comment for x crypto should note this weakness cc agl trevp,1 146204,13173730659.0,IssuesEvent,2020-08-11 20:53:48,golang/go,https://api.github.com/repos/golang/go,closed,doc: write Go 1.15 release notes,Documentation NeedsFix help wanted recurring release-blocker,"Tracking bug for writing the Go 1.15 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.15. Previously #36878, #17929, #15810, #5929, etc.",1.0,"doc: write Go 1.15 release notes - Tracking bug for writing the Go 1.15 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.15. Previously #36878, #17929, #15810, #5929, etc.",1,doc write go release notes tracking bug for writing the go release notes the latest state on tip can be viewed at previously etc ,1 229783,17577633023.0,IssuesEvent,2021-08-15 22:50:45,golang/go,https://api.github.com/repos/golang/go,closed,sync/atomic: CompareAndSwapPointer should be CompareAndSwap [1.17 backport],Documentation CherryPickApproved,"@rhysh requested issue #47699 to be considered for backport to the next 1.17 minor release. > CC @golang/release , this is a new API for Go 1.17, and the release branch doesn't have the fix yet (see https://github.com/golang/go/blob/release-branch.go1.17/src/sync/atomic/value.go#L129 ). For your consideration, so it doesn't get lost in the shuffle on Monday. > > @gopherbot please backport to 1.17 ",1.0,"sync/atomic: CompareAndSwapPointer should be CompareAndSwap [1.17 backport] - @rhysh requested issue #47699 to be considered for backport to the next 1.17 minor release. > CC @golang/release , this is a new API for Go 1.17, and the release branch doesn't have the fix yet (see https://github.com/golang/go/blob/release-branch.go1.17/src/sync/atomic/value.go#L129 ). For your consideration, so it doesn't get lost in the shuffle on Monday. > > @gopherbot please backport to 1.17 ",1,sync atomic compareandswappointer should be compareandswap rhysh requested issue to be considered for backport to the next minor release cc golang release this is a new api for go and the release branch doesn t have the fix yet see for your consideration so it doesn t get lost in the shuffle on monday gopherbot please backport to ,1 3246,3097677983.0,IssuesEvent,2015-08-28 04:46:31,golang/go,https://api.github.com/repos/golang/go,opened,build: upgrade nacl builders to pepper_44 or later,Builders,Closing #11961 removed the limitation keeping us on pepper_41. This issue is a reminder to upgrade the nacl builders to a more recent version of pepper,1.0,build: upgrade nacl builders to pepper_44 or later - Closing #11961 removed the limitation keeping us on pepper_41. This issue is a reminder to upgrade the nacl builders to a more recent version of pepper,0,build upgrade nacl builders to pepper or later closing removed the limitation keeping us on pepper this issue is a reminder to upgrade the nacl builders to a more recent version of pepper,0 54146,13259178400.0,IssuesEvent,2020-08-20 16:21:12,golang/go,https://api.github.com/repos/golang/go,closed,x/build: go1.10.8 release tag mismatch source/binary from golang.org,Builders NeedsInvestigation WaitingForInfo,"go1.10.8 was tagged at commit b0cb374daf646454998bac7b393f3236a2ab6aca `[release-branch.go1.10-security] go1.10.8`, while the actually shipped source/binary from golang.org is commit bd0449f8d16a5ac1b1962c7ea07d764a7f18eca7 `[release-branch.go1.10] all: merge release-branch.go1.10-security into release-branch.go1.10`.",1.0,"x/build: go1.10.8 release tag mismatch source/binary from golang.org - go1.10.8 was tagged at commit b0cb374daf646454998bac7b393f3236a2ab6aca `[release-branch.go1.10-security] go1.10.8`, while the actually shipped source/binary from golang.org is commit bd0449f8d16a5ac1b1962c7ea07d764a7f18eca7 `[release-branch.go1.10] all: merge release-branch.go1.10-security into release-branch.go1.10`.",0,x build release tag mismatch source binary from golang org was tagged at commit while the actually shipped source binary from golang org is commit all merge release branch security into release branch ,0 58100,8229532452.0,IssuesEvent,2018-09-07 09:41:02,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: clarify go.mod documentation for trivial relative modules,Documentation NeedsInvestigation modules,"### What version of Go are you using (`go version`)? 
go version go1.11 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? 
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/rust/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/rust/code""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/rust/code/modtest/b/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/_d/8n_wrc4n32d1rgx80bn6hsl80000gn/T/go-build056371648=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Created two modules a and b in the same directory, not on the GOPATH. Module a contains a.go, go.mod: 
~/code/modtest/a: cat a.go
package a

func Hello() string {
	return ""Hello""
}
~/code/modtest/a: cat go.mod
module a
Module b contains b.go, go.mod: 
~/code/modtest/b: cat b.go
package main

import (
    ""fmt""

    ""a""
)

func main() {
	fmt.Printf(""%s\n"", a.Hello())
}
~/code/modtest/b: cat go.mod 
module b

require ../a v0.0.0
What is the proper syntax for the line require ../a v0.0.0 in this particular case? The closest I found in the docs (go help modules, go help go.mod, go help mod) was from go help importpath: 
Relative import paths

An import path beginning with ./ or ../ is called a relative path.
The toolchain supports relative import paths as a shortcut in two ways.

First, a relative path can be used as a shorthand on the command line.
...

Second, if you are compiling a Go program not in a work space,
you can use a relative path in an import statement in that program
to refer to nearby code also not in a work space.
This makes it easy to experiment with small multipackage programs
outside of the usual work spaces, but such programs cannot be
installed with ""go install"" (there is no work space in which to install them),
so they are rebuilt from scratch each time they are built.
To avoid ambiguity, Go programs cannot use relative import paths
within a work space.
It is unclear to me if the second case is supposed to apply in this situation. ### What did you expect to see? I expect this to compile and run similarly to how it works with the existing GOPATH. For example, copying the modules to the GOPATH gives the following: 
~/code/src: cd a
~/code/src/a: go build
~/code/src/a: cd ../b
~/code/src/b: go build
~/code/src/b: ./b
Hello
### What did you see instead? 
~/code/modtest: cd a
~/code/modtest/a: go build
~/code/modtest/a: cd ../b
~/code/modtest/b: go build
go: ../a@v0.0.0: unrecognized import path ""../a"" (https fetch: Get https://../a?go-get=1: dial tcp: lookup ..: no such host)
go: error loading module requirements
~/code/modtest/b:
",1.0,"cmd/go: clarify go.mod documentation for trivial relative modules - ### What version of Go are you using (`go version`)? 
go version go1.11 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? 
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/rust/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/rust/code""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/rust/code/modtest/b/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/_d/8n_wrc4n32d1rgx80bn6hsl80000gn/T/go-build056371648=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Created two modules a and b in the same directory, not on the GOPATH. Module a contains a.go, go.mod: 
~/code/modtest/a: cat a.go
package a

func Hello() string {
	return ""Hello""
}
~/code/modtest/a: cat go.mod
module a
Module b contains b.go, go.mod: 
~/code/modtest/b: cat b.go
package main

import (
    ""fmt""

    ""a""
)

func main() {
	fmt.Printf(""%s\n"", a.Hello())
}
~/code/modtest/b: cat go.mod 
module b

require ../a v0.0.0
What is the proper syntax for the line require ../a v0.0.0 in this particular case? The closest I found in the docs (go help modules, go help go.mod, go help mod) was from go help importpath: 
Relative import paths

An import path beginning with ./ or ../ is called a relative path.
The toolchain supports relative import paths as a shortcut in two ways.

First, a relative path can be used as a shorthand on the command line.
...

Second, if you are compiling a Go program not in a work space,
you can use a relative path in an import statement in that program
to refer to nearby code also not in a work space.
This makes it easy to experiment with small multipackage programs
outside of the usual work spaces, but such programs cannot be
installed with ""go install"" (there is no work space in which to install them),
so they are rebuilt from scratch each time they are built.
To avoid ambiguity, Go programs cannot use relative import paths
within a work space.
It is unclear to me if the second case is supposed to apply in this situation. ### What did you expect to see? I expect this to compile and run similarly to how it works with the existing GOPATH. For example, copying the modules to the GOPATH gives the following: 
~/code/src: cd a
~/code/src/a: go build
~/code/src/a: cd ../b
~/code/src/b: go build
~/code/src/b: ./b
Hello
### What did you see instead? 
~/code/modtest: cd a
~/code/modtest/a: go build
~/code/modtest/a: cd ../b
~/code/modtest/b: go build
go: ../a@v0.0.0: unrecognized import path ""../a"" (https fetch: Get https://../a?go-get=1: dial tcp: lookup ..: no such host)
go: error loading module requirements
~/code/modtest/b:
",1,cmd go clarify go mod documentation for trivial relative modules what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache users rust library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users rust code goproxy gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod users rust code modtest b go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders d t go tmp go build gno record gcc switches fno common what did you do created two modules a and b in the same directory not on the gopath module a contains a go go mod code modtest a cat a go package a func hello string return hello code modtest a cat go mod module a module b contains b go go mod code modtest b cat b go package main import fmt a func main fmt printf s n a hello code modtest b cat go mod module b require a what is the proper syntax for the line require a in this particular case the closest i found in the docs go help modules go help go mod go help mod was from go help importpath relative import paths an import path beginning with or is called a relative path the toolchain supports relative import paths as a shortcut in two ways first a relative path can be used as a shorthand on the command line second if you are compiling a go program not in a work space you can use a relative path in an import statement in that program to refer to nearby code also not in a work space this makes it easy to experiment with small multipackage programs outside of the usual work spaces but such programs cannot be installed with go install there is no work space in which to install them so they are rebuilt from scratch each time they are built to avoid ambiguity go programs cannot use relative import paths within a work space it is unclear to me if the second case is supposed to apply in this situation what did you expect to see i expect this to compile and run similarly to how it works with the existing gopath for example copying the modules to the gopath gives the following code src cd a code src a go build code src a cd b code src b go build code src b b hello what did you see instead code modtest cd a code modtest a go build code modtest a cd b code modtest b go build go a unrecognized import path a https fetch get dial tcp lookup no such host go error loading module requirements code modtest b ,1 94401,10821477545.0,IssuesEvent,2019-11-08 18:46:23,golang/go,https://api.github.com/repos/golang/go,closed,net: IPMask docs aren't great,Documentation NeedsFix help wanted,"The docs for `net.IPMask` say: https://golang.org/pkg/net/#IPMask > An IP mask is an IP address. > > `type IPMask []byte` That's, uh, pretty brief. We should say more because as-is my first reaction would be, ""Well, then why don't I juse use an IP address?"" For Go 1.13 at least, but Go 1.12 would be fine too. /cc @ianlancetaylor @mikioh ",1.0,"net: IPMask docs aren't great - The docs for `net.IPMask` say: https://golang.org/pkg/net/#IPMask > An IP mask is an IP address. > > `type IPMask []byte` That's, uh, pretty brief. We should say more because as-is my first reaction would be, ""Well, then why don't I juse use an IP address?"" For Go 1.13 at least, but Go 1.12 would be fine too. /cc @ianlancetaylor @mikioh ",1,net ipmask docs aren t great the docs for net ipmask say an ip mask is an ip address type ipmask byte that s uh pretty brief we should say more because as is my first reaction would be well then why don t i juse use an ip address for go at least but go would be fine too cc ianlancetaylor mikioh ,1 11556,3505781112.0,IssuesEvent,2016-01-08 00:56:56,golang/go,https://api.github.com/repos/golang/go,closed,runtime: document missing GODEBUG settings,Documentation,"`src/runtime/extern.go` needs docs for some missing `GODEBUG` keys: * `h2debug` (from https://go-review.googlesource.com/#/c/17754/1/http2/http2.go@29) * `h2client=0` (from net/http) and upcoming(?) `h2server=0`? * `netdns` (documented elsewhere, but not in runtime/extern.go) /cc @ianlancetaylor ",1.0,"runtime: document missing GODEBUG settings - `src/runtime/extern.go` needs docs for some missing `GODEBUG` keys: * `h2debug` (from https://go-review.googlesource.com/#/c/17754/1/http2/http2.go@29) * `h2client=0` (from net/http) and upcoming(?) `h2server=0`? * `netdns` (documented elsewhere, but not in runtime/extern.go) /cc @ianlancetaylor ",1,runtime document missing godebug settings src runtime extern go needs docs for some missing godebug keys from from net http and upcoming netdns documented elsewhere but not in runtime extern go cc ianlancetaylor ,1 12945,8752064186.0,IssuesEvent,2018-12-14 01:04:59,golang/go,https://api.github.com/repos/golang/go,closed,crypto/x509: CPU denial of service in chain validation,Security,"Package `crypto/x509` parses and validates X.509-encoded keys and certificates. It's supposed to handle certificate chains provided by an attacker with reasonable resource use. The `crypto/x509` package does not limit the amount of work performed for each chain verification, which might allow attackers to craft pathological inputs leading to a CPU denial of service. Go TLS servers accepting client certificates and TLS clients verifying certificates are affected. Thanks to Netflix for discovering and reporting this issue. This issue is CVE-2018-16875.",True,"crypto/x509: CPU denial of service in chain validation - Package `crypto/x509` parses and validates X.509-encoded keys and certificates. It's supposed to handle certificate chains provided by an attacker with reasonable resource use. The `crypto/x509` package does not limit the amount of work performed for each chain verification, which might allow attackers to craft pathological inputs leading to a CPU denial of service. Go TLS servers accepting client certificates and TLS clients verifying certificates are affected. Thanks to Netflix for discovering and reporting this issue. This issue is CVE-2018-16875.",0,crypto cpu denial of service in chain validation package crypto parses and validates x encoded keys and certificates it s supposed to handle certificate chains provided by an attacker with reasonable resource use the crypto package does not limit the amount of work performed for each chain verification which might allow attackers to craft pathological inputs leading to a cpu denial of service go tls servers accepting client certificates and tls clients verifying certificates are affected thanks to netflix for discovering and reporting this issue this issue is cve ,0 42493,6986040990.0,IssuesEvent,2017-12-14 00:59:04,golang/go,https://api.github.com/repos/golang/go,closed,testing: clarity of -timeout flag,Documentation,"This is directly related to #20090, opening a new issue because I'm not sure whether closed issues are supposed to be reopened. The description of the `-timeout` flag has changed twice for Go 1.9. The first change (done by me) was intended to clarify that the timeout applies per package. The latest revision, referring to ""a test binary"", is certainly correct, but in my experience many gophers do not know that the tests from each package is executed as a separate test binary. This can be inferred from the help text, but it's not explicit and likely to be ambiguous to many. There may well be a better description than what I provided. I'd just like for the documentation to be clear without needing to understand exactly how test binaries are built and executed. Original Text: > -timeout t > If a test runs longer than t, panic. > The default is 10 minutes (10m). https://golang.org/cl/45816: > -timeout d > If the **cumulative test time for a package** runs longer than > duration d, panic. Timeout is disabled if set to 0. > The default is 10 minutes (10m). https://golang.org/cl/47571: > -timeout d > If **a test binary** runs longer than duration d, panic. > The default is 10 minutes (10m). Notes: * Emphasis added. * The ""Timeout is disabled if set to 0"" text can be ignored. It was a mistake on my part.",1.0,"testing: clarity of -timeout flag - This is directly related to #20090, opening a new issue because I'm not sure whether closed issues are supposed to be reopened. The description of the `-timeout` flag has changed twice for Go 1.9. The first change (done by me) was intended to clarify that the timeout applies per package. The latest revision, referring to ""a test binary"", is certainly correct, but in my experience many gophers do not know that the tests from each package is executed as a separate test binary. This can be inferred from the help text, but it's not explicit and likely to be ambiguous to many. There may well be a better description than what I provided. I'd just like for the documentation to be clear without needing to understand exactly how test binaries are built and executed. Original Text: > -timeout t > If a test runs longer than t, panic. > The default is 10 minutes (10m). https://golang.org/cl/45816: > -timeout d > If the **cumulative test time for a package** runs longer than > duration d, panic. Timeout is disabled if set to 0. > The default is 10 minutes (10m). https://golang.org/cl/47571: > -timeout d > If **a test binary** runs longer than duration d, panic. > The default is 10 minutes (10m). Notes: * Emphasis added. * The ""Timeout is disabled if set to 0"" text can be ignored. It was a mistake on my part.",1,testing clarity of timeout flag this is directly related to opening a new issue because i m not sure whether closed issues are supposed to be reopened the description of the timeout flag has changed twice for go the first change done by me was intended to clarify that the timeout applies per package the latest revision referring to a test binary is certainly correct but in my experience many gophers do not know that the tests from each package is executed as a separate test binary this can be inferred from the help text but it s not explicit and likely to be ambiguous to many there may well be a better description than what i provided i d just like for the documentation to be clear without needing to understand exactly how test binaries are built and executed original text timeout t if a test runs longer than t panic the default is minutes timeout d if the cumulative test time for a package runs longer than duration d panic timeout is disabled if set to the default is minutes timeout d if a test binary runs longer than duration d panic the default is minutes notes emphasis added the timeout is disabled if set to text can be ignored it was a mistake on my part ,1 151864,12060733993.0,IssuesEvent,2020-04-15 21:51:34,golang/go,https://api.github.com/repos/golang/go,closed,x/mod/zip: frequent TestVCS failures with 'exit status 128',NeedsFix Testing modules,"``` --- FAIL: TestVCS (0.00s) --- FAIL: TestVCS/rsc.io_quote@v1.2.1 (31.77s) zip_test.go:944: fetch -f --depth=1 origin refs/tags/v1.2.1:refs/tags/v1.2.1: exit status 128 FAIL FAIL golang.org/x/mod/zip 37.493s ``` Some examples (a full list is hard to obtain due to #35515): * https://build.golang.org/log/ccfe7667f4a8078f0abb9f1690bb60b9c16b6667 * https://build.golang.org/log/770a0e7b2932494a0088282e8c368b83d0b4b429 * https://build.golang.org/log/8e4f13ddce054d013f61ca4107aff0aad92c2aee * https://build.golang.org/log/48b37e8f22936ba040107609992fb71851f7eaea * https://build.golang.org/log/409017b9f72dc739589429803dd6fcf3cb3fb533 The specific repository that fails seems to vary from run to run. It's not clear to me whether this is a bug in `x/mod/zip`, a bug in `git`, a network issue on the `linux-amd64-longtest` builder, or unreliability in the upstream `git` servers. CC @jayconrod @matloob @andybons ",1.0,"x/mod/zip: frequent TestVCS failures with 'exit status 128' - ``` --- FAIL: TestVCS (0.00s) --- FAIL: TestVCS/rsc.io_quote@v1.2.1 (31.77s) zip_test.go:944: fetch -f --depth=1 origin refs/tags/v1.2.1:refs/tags/v1.2.1: exit status 128 FAIL FAIL golang.org/x/mod/zip 37.493s ``` Some examples (a full list is hard to obtain due to #35515): * https://build.golang.org/log/ccfe7667f4a8078f0abb9f1690bb60b9c16b6667 * https://build.golang.org/log/770a0e7b2932494a0088282e8c368b83d0b4b429 * https://build.golang.org/log/8e4f13ddce054d013f61ca4107aff0aad92c2aee * https://build.golang.org/log/48b37e8f22936ba040107609992fb71851f7eaea * https://build.golang.org/log/409017b9f72dc739589429803dd6fcf3cb3fb533 The specific repository that fails seems to vary from run to run. It's not clear to me whether this is a bug in `x/mod/zip`, a bug in `git`, a network issue on the `linux-amd64-longtest` builder, or unreliability in the upstream `git` servers. CC @jayconrod @matloob @andybons ",0,x mod zip frequent testvcs failures with exit status fail testvcs fail testvcs rsc io quote zip test go fetch f depth origin refs tags refs tags exit status fail fail golang org x mod zip some examples a full list is hard to obtain due to the specific repository that fails seems to vary from run to run it s not clear to me whether this is a bug in x mod zip a bug in git a network issue on the linux longtest builder or unreliability in the upstream git servers cc jayconrod matloob andybons ,0 22075,4771711930.0,IssuesEvent,2016-10-26 18:46:59,golang/go,https://api.github.com/repos/golang/go,opened,"net: no docs on ""0"" or empty name of transport service",Documentation,"#13610 and CL 17755 fixed the behavior without documentation. There is no documentation that describes what happens when the zero value of transport service in Dial, Listen, ListenPacket functions and Resolve{TCP,UDP,IP}Addr functions. I guess those two groups behave differently.",1.0,"net: no docs on ""0"" or empty name of transport service - #13610 and CL 17755 fixed the behavior without documentation. There is no documentation that describes what happens when the zero value of transport service in Dial, Listen, ListenPacket functions and Resolve{TCP,UDP,IP}Addr functions. I guess those two groups behave differently.",1,net no docs on or empty name of transport service and cl fixed the behavior without documentation there is no documentation that describes what happens when the zero value of transport service in dial listen listenpacket functions and resolve tcp udp ip addr functions i guess those two groups behave differently ,1 6183,5309907817.0,IssuesEvent,2017-02-12 15:26:21,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: optimize map access,Performance,"The following code is quite common in production systems: ```go func getValueByKey(k string) Value { mu.Lock() v, ok := m[k] if !ok { v = newValue() m[k] = v } mu.Unlock() return v } ``` The following two optimizations may be applied by the compiler to the code: 1) Calculate hash for `k` only once, since `k` doesn't change 2) Move hash calculation outside the `mu` lock. This will improve scalability of the code on multi-CPU machines. cc @dr2chase , @josharian .",True,"cmd/compile: optimize map access - The following code is quite common in production systems: ```go func getValueByKey(k string) Value { mu.Lock() v, ok := m[k] if !ok { v = newValue() m[k] = v } mu.Unlock() return v } ``` The following two optimizations may be applied by the compiler to the code: 1) Calculate hash for `k` only once, since `k` doesn't change 2) Move hash calculation outside the `mu` lock. This will improve scalability of the code on multi-CPU machines. cc @dr2chase , @josharian .",0,cmd compile optimize map access the following code is quite common in production systems go func getvaluebykey k string value mu lock v ok m if ok v newvalue m v mu unlock return v the following two optimizations may be applied by the compiler to the code calculate hash for k only once since k doesn t change move hash calculation outside the mu lock this will improve scalability of the code on multi cpu machines cc josharian ,0 59684,14630118825.0,IssuesEvent,2020-12-23 17:04:58,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env/openbsd: add OpenBSD 6.8 builder,Builders NeedsFix OS-OpenBSD new-builder,"OpenBSD 6.6 is out: https://www.openbsd.org/66.html Update our GCE builders. (rather, add a builder) Pending CL https://go-review.googlesource.com/c/build/+/176237 does most the work (but using pre-release 6.5 instead of 6.6). Just need to build it, test it (with x/build/cmd/debugnewvm) and configure it if it works. /cc @cagedmantis @dmitshur @bcmills ",2.0,"x/build/env/openbsd: add OpenBSD 6.8 builder - OpenBSD 6.6 is out: https://www.openbsd.org/66.html Update our GCE builders. (rather, add a builder) Pending CL https://go-review.googlesource.com/c/build/+/176237 does most the work (but using pre-release 6.5 instead of 6.6). Just need to build it, test it (with x/build/cmd/debugnewvm) and configure it if it works. /cc @cagedmantis @dmitshur @bcmills ",0,x build env openbsd add openbsd builder openbsd is out update our gce builders rather add a builder pending cl does most the work but using pre release instead of just need to build it test it with x build cmd debugnewvm and configure it if it works cc cagedmantis dmitshur bcmills ,0 211587,16450014678.0,IssuesEvent,2021-05-21 03:24:00,golang/go,https://api.github.com/repos/golang/go,closed,io/fs: no examples for how to use it with the operating system,Documentation NeedsFix help wanted,"I needed to walk a directory, so I pulled up the `io/fs.WalkDir` docs, but there was nothing telling me how to get an `FS` instance for the operating system's filesystem. The only mention of `os.DirFS` is in `fs.Sub`, and I only found it because I had a hunch to search `os.`.",1.0,"io/fs: no examples for how to use it with the operating system - I needed to walk a directory, so I pulled up the `io/fs.WalkDir` docs, but there was nothing telling me how to get an `FS` instance for the operating system's filesystem. The only mention of `os.DirFS` is in `fs.Sub`, and I only found it because I had a hunch to search `os.`.",1,io fs no examples for how to use it with the operating system i needed to walk a directory so i pulled up the io fs walkdir docs but there was nothing telling me how to get an fs instance for the operating system s filesystem the only mention of os dirfs is in fs sub and i only found it because i had a hunch to search os ,1 421490,28321443287.0,IssuesEvent,2023-04-11 01:46:24,golang/go,https://api.github.com/repos/golang/go,closed,"spec: typo ""are"" -> ""or"" in Core types",Documentation NeedsFix," ### What is the URL of the page with the issue? https://go.dev/ref/spec#Core_types ### What is your user agent? Safari 16.5 ### Screenshot ### What did you do? ### What did you expect to see? The conjunction ""or"" ""to declare variables or compose other types"" in the bytestring discussion under ""Core Types"" Note that bytestring is not a real type; it cannot be used to declare variables or compose other types. It exists solely to describe the behavior of some operations that read from a sequence of bytes, which may be a byte slice or a string. ### What did you see instead? The verb ""are"" ""to declare variables are compose other types"" Note that bytestring is not a real type; it cannot be used to declare variables are compose other types. It exists solely to describe the behavior of some operations that read from a sequence of bytes, which may be a byte slice or a string. ",1.0,"spec: typo ""are"" -> ""or"" in Core types - ### What is the URL of the page with the issue? https://go.dev/ref/spec#Core_types ### What is your user agent? Safari 16.5 ### Screenshot ### What did you do? ### What did you expect to see? The conjunction ""or"" ""to declare variables or compose other types"" in the bytestring discussion under ""Core Types"" Note that bytestring is not a real type; it cannot be used to declare variables or compose other types. It exists solely to describe the behavior of some operations that read from a sequence of bytes, which may be a byte slice or a string. ### What did you see instead? The verb ""are"" ""to declare variables are compose other types"" Note that bytestring is not a real type; it cannot be used to declare variables are compose other types. It exists solely to describe the behavior of some operations that read from a sequence of bytes, which may be a byte slice or a string. ",1,spec typo are or in core types please answer these questions before submitting your issue thanks what is the url of the page with the issue what is your user agent you can find your user agent here safari screenshot please paste a screenshot of the page img width alt image src what did you do if possible provide a recipe for reproducing the error what did you expect to see the conjunction or to declare variables or compose other types in the bytestring discussion under core types note that bytestring is not a real type it cannot be used to declare variables or compose other types it exists solely to describe the behavior of some operations that read from a sequence of bytes which may be a byte slice or a string what did you see instead the verb are to declare variables are compose other types note that bytestring is not a real type it cannot be used to declare variables are compose other types it exists solely to describe the behavior of some operations that read from a sequence of bytes which may be a byte slice or a string ,1 196151,14815149271.0,IssuesEvent,2021-01-14 06:41:03,golang/go,https://api.github.com/repos/golang/go,opened,"std,cmd: add test to ensure that all modules in GOROOT are tidy",NeedsFix Testing,"We can add a test that catches and reports when the a module in GOROOT is not tidy. Having an automated test for this will prevent it from happening without anyone noticing, and it makes it easier for humans to review CLs that modify go.mod files, since they won't need to worry about checking this manually. It's probably not a big deal if a module isn't tidy, but it turned out to be easy and inexpensive to perform this check as part of the test for #36852 and #41409, so let's try it. (If we find that it's unhelpful, or there are situations when modules must be non-tidy, we can remove it.)",1.0,"std,cmd: add test to ensure that all modules in GOROOT are tidy - We can add a test that catches and reports when the a module in GOROOT is not tidy. Having an automated test for this will prevent it from happening without anyone noticing, and it makes it easier for humans to review CLs that modify go.mod files, since they won't need to worry about checking this manually. It's probably not a big deal if a module isn't tidy, but it turned out to be easy and inexpensive to perform this check as part of the test for #36852 and #41409, so let's try it. (If we find that it's unhelpful, or there are situations when modules must be non-tidy, we can remove it.)",0,std cmd add test to ensure that all modules in goroot are tidy we can add a test that catches and reports when the a module in goroot is not tidy having an automated test for this will prevent it from happening without anyone noticing and it makes it easier for humans to review cls that modify go mod files since they won t need to worry about checking this manually it s probably not a big deal if a module isn t tidy but it turned out to be easy and inexpensive to perform this check as part of the test for and so let s try it if we find that it s unhelpful or there are situations when modules must be non tidy we can remove it ,0 149174,11884776892.0,IssuesEvent,2020-03-27 18:17:27,golang/go,https://api.github.com/repos/golang/go,closed,net/http: TestIdentityResponse is flaky on slow builders,NeedsFix Testing,"[2020-03-26T14:23:17-f9c5ef8/solaris-amd64-oraclerel](https://build.golang.org/log/3515b6baf36531074ea84ecefa1d7735cf4c5793) [2020-02-07T18:04:09-c7c525a/plan9-386-0intro](https://build.golang.org/log/67ba72fb1f053e7299bbb1cf852f4a3de406d18d) ``` --- FAIL: TestIdentityResponse (2.08s) serve_test.go:3636: Timeout expired after 2s FAIL FAIL net/http 14.459s ``` It's not obvious to me why this test has a timeout at all: if the call hangs, letting the test die (and dump stacks for the hung goroutines) seems strictly more useful than a ""Timeout expired"" error without stacks.",1.0,"net/http: TestIdentityResponse is flaky on slow builders - [2020-03-26T14:23:17-f9c5ef8/solaris-amd64-oraclerel](https://build.golang.org/log/3515b6baf36531074ea84ecefa1d7735cf4c5793) [2020-02-07T18:04:09-c7c525a/plan9-386-0intro](https://build.golang.org/log/67ba72fb1f053e7299bbb1cf852f4a3de406d18d) ``` --- FAIL: TestIdentityResponse (2.08s) serve_test.go:3636: Timeout expired after 2s FAIL FAIL net/http 14.459s ``` It's not obvious to me why this test has a timeout at all: if the call hangs, letting the test die (and dump stacks for the hung goroutines) seems strictly more useful than a ""Timeout expired"" error without stacks.",0,net http testidentityresponse is flaky on slow builders fail testidentityresponse serve test go timeout expired after fail fail net http it s not obvious to me why this test has a timeout at all if the call hangs letting the test die and dump stacks for the hung goroutines seems strictly more useful than a timeout expired error without stacks ,0 203013,15864952177.0,IssuesEvent,2021-04-08 14:15:58,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: missing `""` in code snippet",Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
# Doesn't matter.
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
# Doesn't matter.
### What did you do? Find typo when reading reference. https://golang.org/ref/mod#environment-variables ![image](https://user-images.githubusercontent.com/8807977/113972037-83334f80-986c-11eb-9e97-25277273fec1.png) ### What did you expect to see? ``` GOSUMDB=""sum.golang.org+ https://sum.golang.org"" ``` ### What did you see instead? ",1.0,"x/website: missing `""` in code snippet - ### What version of Go are you using (`go version`)? 
$ go version
# Doesn't matter.
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
# Doesn't matter.
### What did you do? Find typo when reading reference. https://golang.org/ref/mod#environment-variables ![image](https://user-images.githubusercontent.com/8807977/113972037-83334f80-986c-11eb-9e97-25277273fec1.png) ### What did you expect to see? ``` GOSUMDB=""sum.golang.org+ https://sum.golang.org"" ``` ### What did you see instead? ",1,x website missing in code snippet please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version doesn t matter does this issue reproduce with the latest release what operating system and processor architecture are you using go env go env output go env doesn t matter 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 find typo when reading reference what did you expect to see gosumdb sum golang org what did you see instead ,1 73224,19599353407.0,IssuesEvent,2022-01-05 22:18:39,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/coordinator: SlowBots status page broken for CL 375694,Builders NeedsInvestigation Soon,"The SlowBot status page at https://farmer.golang.org/try?commit=edfc2bef, linked from [CL 375694](https://go-review.googlesource.com/c/go/+/375694/3#message-a869de37952174356c179cf2b78cdc17ed029776), appears to be broken: ![unnamed](https://user-images.githubusercontent.com/5200974/148291847-cedf2439-e795-48e0-9142-d1960f740ff1.png) That CL attempts to fix a test that fails fairly frequently on the builders (#34495), so I would like to be able to review and merge it soon. Is there something we can do to unblock the SlowBots? (CC @golang/release)",1.0,"x/build/cmd/coordinator: SlowBots status page broken for CL 375694 - The SlowBot status page at https://farmer.golang.org/try?commit=edfc2bef, linked from [CL 375694](https://go-review.googlesource.com/c/go/+/375694/3#message-a869de37952174356c179cf2b78cdc17ed029776), appears to be broken: ![unnamed](https://user-images.githubusercontent.com/5200974/148291847-cedf2439-e795-48e0-9142-d1960f740ff1.png) That CL attempts to fix a test that fails fairly frequently on the builders (#34495), so I would like to be able to review and merge it soon. Is there something we can do to unblock the SlowBots? (CC @golang/release)",0,x build cmd coordinator slowbots status page broken for cl the slowbot status page at linked from appears to be broken that cl attempts to fix a test that fails fairly frequently on the builders so i would like to be able to review and merge it soon is there something we can do to unblock the slowbots cc golang release ,0 389906,26838745176.0,IssuesEvent,2023-02-02 21:55:34,golang/go,https://api.github.com/repos/golang/go,closed,x/website: doc/modules/managing-dependencies: markdown link is broken,Documentation NeedsFix website," ### What is the URL of the page with the issue? https://go.dev/doc/modules/managing-dependencies ### What is your user agent? Microsoft Edge Version 96.0.1054.53 (Official build) (64-bit) ### Screenshot #### Broken Link ![image](https://user-images.githubusercontent.com/4377454/146906473-c972f697-55c4-40bd-b9a5-07e2113ba468.png) #### Duplicated sentences ![image](https://user-images.githubusercontent.com/4377454/146906627-9c8cb103-2996-4370-841d-6c918dd514b9.png) ### What did you do? ### What did you expect to see? It's supposed to be a correct markdown link. ### What did you see instead? ",1.0,"x/website: doc/modules/managing-dependencies: markdown link is broken - ### What is the URL of the page with the issue? https://go.dev/doc/modules/managing-dependencies ### What is your user agent? Microsoft Edge Version 96.0.1054.53 (Official build) (64-bit) ### Screenshot #### Broken Link ![image](https://user-images.githubusercontent.com/4377454/146906473-c972f697-55c4-40bd-b9a5-07e2113ba468.png) #### Duplicated sentences ![image](https://user-images.githubusercontent.com/4377454/146906627-9c8cb103-2996-4370-841d-6c918dd514b9.png) ### What did you do? ### What did you expect to see? It's supposed to be a correct markdown link. ### What did you see instead? ",1,x website doc modules managing dependencies markdown link is broken please answer these questions before submitting your issue thanks what is the url of the page with the issue what is your user agent microsoft edge version official build bit screenshot broken link duplicated sentences what did you do if possible provide a recipe for reproducing the error what did you expect to see it s supposed to be a correct markdown link what did you see instead ,1 74300,9779189957.0,IssuesEvent,2019-06-07 13:57:44,golang/go,https://api.github.com/repos/golang/go,closed,text/template: document concurrency properties for the instances returned by (*Template).New,Documentation NeedsFix,"```go package main import ( ""fmt"" ""sync"" ""text/template"" ) func main() { var wg sync.WaitGroup tpl := template.New("""") for i := 1; i < 20; i++ { name := fmt.Sprintf(""n%d.txt"", i) wg.Add(1) go func() { defer wg.Done() tpl.New(name).Parse(""Go!"") }() } wg.Wait() } ``` The above fails with: ```bash fatal error: concurrent map read and map write goroutine 36 [running]: runtime.throw(0x1136d33, 0x21) /Users/bep/sdk/go1.12beta2/src/runtime/panic.go:617 +0x72 fp=0xc000075d78 sp=0xc000075d48 pc=0x1029d02 runtime.mapaccess1_faststr(0x110d820, 0xc000066210, 0xc000016230, 0x7, 0x0) /Users/bep/sdk/go1.12beta2/src/runtime/map_faststr.go:21 +0x464 fp=0xc000075de8 sp=0xc000075d78 pc=0x1010a34 text/template.(*Template).associate(0xc00004a340, 0xc00004a340, 0xc0000ae800, 0xc00006ec01) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:217 +0x62 fp=0xc000075e28 sp=0xc000075de8 pc=0x10ec762 text/template.(*Template).AddParseTree(0xc00004a340, 0xc000016230, 0x7, 0xc0000ae800, 0x0, 0x0, 0x0) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:128 +0xfa fp=0xc000075e78 sp=0xc000075e28 pc=0x10ebb0a text/template.(*Template).Parse(0xc00004a340, 0x1131652, 0x3, 0x0, 0x0, 0x0) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:203 +0x1f8 fp=0xc000075f78 sp=0xc000075e78 pc=0x10ec528 main.main.func1(0xc000016114, 0xc00004a0c0, 0xc000016230, 0x7) /Users/bep/dev/go/bep/temp/main.go:19 +0xfa fp=0xc000075fc0 sp=0xc000075f78 pc=0x10ee17a runtime.goexit() /Users/bep/sdk/go1.12beta2/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc000075fc8 sp=0xc000075fc0 pc=0x1052f41 created by main.main /Users/bep/dev/go/bep/temp/main.go:17 +0x13b goroutine 1 [semacquire]: sync.runtime_Semacquire(0xc000016114) /Users/bep/sdk/go1.12beta2/src/runtime/sema.go:56 +0x39 sync.(*WaitGroup).Wait(0xc000016114) /Users/bep/sdk/go1.12beta2/src/sync/waitgroup.go:130 +0x65 main.main() /Users/bep/dev/go/bep/temp/main.go:23 +0x161 Error: process exited with code 2. ``` I'm currently running `go1.12beta2` (yes, I know), but I have had this failure on earlier versions, too. Note that I'm not saying that this is a bug (the doc for `Parse` isn't clear on this), but as this has hit me more than once in real programs, I think at least a documentation update is needed. ",1.0,"text/template: document concurrency properties for the instances returned by (*Template).New - ```go package main import ( ""fmt"" ""sync"" ""text/template"" ) func main() { var wg sync.WaitGroup tpl := template.New("""") for i := 1; i < 20; i++ { name := fmt.Sprintf(""n%d.txt"", i) wg.Add(1) go func() { defer wg.Done() tpl.New(name).Parse(""Go!"") }() } wg.Wait() } ``` The above fails with: ```bash fatal error: concurrent map read and map write goroutine 36 [running]: runtime.throw(0x1136d33, 0x21) /Users/bep/sdk/go1.12beta2/src/runtime/panic.go:617 +0x72 fp=0xc000075d78 sp=0xc000075d48 pc=0x1029d02 runtime.mapaccess1_faststr(0x110d820, 0xc000066210, 0xc000016230, 0x7, 0x0) /Users/bep/sdk/go1.12beta2/src/runtime/map_faststr.go:21 +0x464 fp=0xc000075de8 sp=0xc000075d78 pc=0x1010a34 text/template.(*Template).associate(0xc00004a340, 0xc00004a340, 0xc0000ae800, 0xc00006ec01) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:217 +0x62 fp=0xc000075e28 sp=0xc000075de8 pc=0x10ec762 text/template.(*Template).AddParseTree(0xc00004a340, 0xc000016230, 0x7, 0xc0000ae800, 0x0, 0x0, 0x0) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:128 +0xfa fp=0xc000075e78 sp=0xc000075e28 pc=0x10ebb0a text/template.(*Template).Parse(0xc00004a340, 0x1131652, 0x3, 0x0, 0x0, 0x0) /Users/bep/sdk/go1.12beta2/src/text/template/template.go:203 +0x1f8 fp=0xc000075f78 sp=0xc000075e78 pc=0x10ec528 main.main.func1(0xc000016114, 0xc00004a0c0, 0xc000016230, 0x7) /Users/bep/dev/go/bep/temp/main.go:19 +0xfa fp=0xc000075fc0 sp=0xc000075f78 pc=0x10ee17a runtime.goexit() /Users/bep/sdk/go1.12beta2/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc000075fc8 sp=0xc000075fc0 pc=0x1052f41 created by main.main /Users/bep/dev/go/bep/temp/main.go:17 +0x13b goroutine 1 [semacquire]: sync.runtime_Semacquire(0xc000016114) /Users/bep/sdk/go1.12beta2/src/runtime/sema.go:56 +0x39 sync.(*WaitGroup).Wait(0xc000016114) /Users/bep/sdk/go1.12beta2/src/sync/waitgroup.go:130 +0x65 main.main() /Users/bep/dev/go/bep/temp/main.go:23 +0x161 Error: process exited with code 2. ``` I'm currently running `go1.12beta2` (yes, I know), but I have had this failure on earlier versions, too. Note that I'm not saying that this is a bug (the doc for `Parse` isn't clear on this), but as this has hit me more than once in real programs, I think at least a documentation update is needed. ",1,text template document concurrency properties for the instances returned by template new go package main import fmt sync text template func main var wg sync waitgroup tpl template new for i i i name fmt sprintf n d txt i wg add go func defer wg done tpl new name parse go wg wait the above fails with bash fatal error concurrent map read and map write goroutine runtime throw users bep sdk src runtime panic go fp sp pc runtime faststr users bep sdk src runtime map faststr go fp sp pc text template template associate users bep sdk src text template template go fp sp pc text template template addparsetree users bep sdk src text template template go fp sp pc text template template parse users bep sdk src text template template go fp sp pc main main users bep dev go bep temp main go fp sp pc runtime goexit users bep sdk src runtime asm s fp sp pc created by main main users bep dev go bep temp main go goroutine sync runtime semacquire users bep sdk src runtime sema go sync waitgroup wait users bep sdk src sync waitgroup go main main users bep dev go bep temp main go error process exited with code i m currently running yes i know but i have had this failure on earlier versions too note that i m not saying that this is a bug the doc for parse isn t clear on this but as this has hit me more than once in real programs i think at least a documentation update is needed ,1 129204,10566890534.0,IssuesEvent,2019-10-05 22:18:42,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: test prompts to authenticate vcs-test.golang.org,NeedsInvestigation Testing,"When running `go test cmd/go/...` for the first time on a new machine, I saw an `ssh` prompt on the terminal: ``` The authenticity of host 'vcs-test.golang.org (35.184.38.56)' can't be established. ECDSA key fingerprint is SHA256:[…]. Are you sure you want to continue connecting (yes/no)? yes ``` Perhaps we can add a `known_hosts` file somewhere in `cmd/go/testdata` and set some environment variable to suppress the prompt? (See also #27494.) CC @hanwen @FiloSottile @jayconrod ",1.0,"cmd/go: test prompts to authenticate vcs-test.golang.org - When running `go test cmd/go/...` for the first time on a new machine, I saw an `ssh` prompt on the terminal: ``` The authenticity of host 'vcs-test.golang.org (35.184.38.56)' can't be established. ECDSA key fingerprint is SHA256:[…]. Are you sure you want to continue connecting (yes/no)? yes ``` Perhaps we can add a `known_hosts` file somewhere in `cmd/go/testdata` and set some environment variable to suppress the prompt? (See also #27494.) CC @hanwen @FiloSottile @jayconrod ",0,cmd go test prompts to authenticate vcs test golang org when running go test cmd go for the first time on a new machine i saw an ssh prompt on the terminal the authenticity of host vcs test golang org can t be established ecdsa key fingerprint is are you sure you want to continue connecting yes no yes perhaps we can add a known hosts file somewhere in cmd go testdata and set some environment variable to suppress the prompt see also cc hanwen filosottile jayconrod ,0 65956,16510317415.0,IssuesEvent,2021-05-26 02:40:25,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/sourcecache: increase download size limit to accommodate larger repositories in 2021,Builders NeedsFix,"TryBots are failing on CL 322750 with: ``` reading website/212bb63fb0e7677bf1f7b9c00752b5ae51417f5b from gerrit: body over 52428800 bytes ``` ~~It seems like the underlying error might be coming indirectly from Gerrit at this point.~~ Update: It's our own limit in x/build, see comment below. We should determine if TryBots should be able to handle a large CL (it's adding approximately 70 MB of content from x/blog repo), or otherwise improve the error message to say that a known limit is being exceeded. CC @golang/release, @rsc.",1.0,"x/build/internal/sourcecache: increase download size limit to accommodate larger repositories in 2021 - TryBots are failing on CL 322750 with: ``` reading website/212bb63fb0e7677bf1f7b9c00752b5ae51417f5b from gerrit: body over 52428800 bytes ``` ~~It seems like the underlying error might be coming indirectly from Gerrit at this point.~~ Update: It's our own limit in x/build, see comment below. We should determine if TryBots should be able to handle a large CL (it's adding approximately 70 MB of content from x/blog repo), or otherwise improve the error message to say that a known limit is being exceeded. CC @golang/release, @rsc.",0,x build internal sourcecache increase download size limit to accommodate larger repositories in trybots are failing on cl with reading website from gerrit body over bytes it seems like the underlying error might be coming indirectly from gerrit at this point update it s our own limit in x build see comment below we should determine if trybots should be able to handle a large cl it s adding approximately mb of content from x blog repo or otherwise improve the error message to say that a known limit is being exceeded cc golang release rsc ,0 11045,3454722561.0,IssuesEvent,2015-12-17 17:00:59,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: document that ""go test"" sets the PWD to the package directory",Documentation,"Using ```go1.5.1``` I have been relying on this behavior for some time and just assumed that it was always true, but when I looked through the documentation for ```go help test``` it doesn't mention this fact at all. Many benchmarks make this assumption when they load test files from a testdata directory that is relative to the package directory. Because ```go test``` sets the PWD, stuff like this works from anywhere: ``` rawr@carbonite: /tmp $ go test compress/flate -run none -bench . PASS BenchmarkDecodeDigitsSpeed1e4-4 10000 194030 ns/op 51.54 MB/s 40301 B/op 7 allocs/op ... ``` But compiling the test binary does not: ``` rawr@carbonite: /tmp $ go test -c compress/flate rawr@carbonite: /tmp $ ./flate.test -test.run none -test.bench . PASS BenchmarkDecodeDigitsSpeed1e4-4 --- FAIL: BenchmarkDecodeDigitsSpeed1e4-4 reader_test.go:45: open ../testdata/e.txt: no such file or directory ... ``` I think the fact that the compiled version fails is WAI, but this behavior should be documented.",1.0,"cmd/go: document that ""go test"" sets the PWD to the package directory - Using ```go1.5.1``` I have been relying on this behavior for some time and just assumed that it was always true, but when I looked through the documentation for ```go help test``` it doesn't mention this fact at all. Many benchmarks make this assumption when they load test files from a testdata directory that is relative to the package directory. Because ```go test``` sets the PWD, stuff like this works from anywhere: ``` rawr@carbonite: /tmp $ go test compress/flate -run none -bench . PASS BenchmarkDecodeDigitsSpeed1e4-4 10000 194030 ns/op 51.54 MB/s 40301 B/op 7 allocs/op ... ``` But compiling the test binary does not: ``` rawr@carbonite: /tmp $ go test -c compress/flate rawr@carbonite: /tmp $ ./flate.test -test.run none -test.bench . PASS BenchmarkDecodeDigitsSpeed1e4-4 --- FAIL: BenchmarkDecodeDigitsSpeed1e4-4 reader_test.go:45: open ../testdata/e.txt: no such file or directory ... ``` I think the fact that the compiled version fails is WAI, but this behavior should be documented.",1,cmd go document that go test sets the pwd to the package directory using i have been relying on this behavior for some time and just assumed that it was always true but when i looked through the documentation for go help test it doesn t mention this fact at all many benchmarks make this assumption when they load test files from a testdata directory that is relative to the package directory because go test sets the pwd stuff like this works from anywhere rawr carbonite tmp go test compress flate run none bench pass ns op mb s b op allocs op but compiling the test binary does not rawr carbonite tmp go test c compress flate rawr carbonite tmp flate test test run none test bench pass fail reader test go open testdata e txt no such file or directory i think the fact that the compiled version fails is wai but this behavior should be documented ,1 70109,18018259207.0,IssuesEvent,2021-09-16 16:05:21,golang/go,https://api.github.com/repos/golang/go,opened,x/build: ios-arm64-corellium builders have long wait times,Builders NeedsFix,"Users have reported long wait times with ios-arm64-corellium builds: ``` • ios-arm64-corellium | running 1h38m44s ``` ``` ios-arm64-corellium rev cfa233d7 (sub-repo mobile rev 855b5ad0) (trybot set for Ib1a2f53); waiting_for_machine; (nil *buildlet.Client), 1h45m36s ago 2021-09-16T14:15:15Z checking_for_snapshot 2021-09-16T14:15:15Z finish_checking_for_snapshot after 35ms 2021-09-16T14:15:15Z get_buildlet +6335.7s (now) ``` `host-ios-arm64-corellium-ios: 2/2 (1 missing)` Perhaps the builders need to be rebooted. @eliasnaur @golang/release ",1.0,"x/build: ios-arm64-corellium builders have long wait times - Users have reported long wait times with ios-arm64-corellium builds: ``` • ios-arm64-corellium | running 1h38m44s ``` ``` ios-arm64-corellium rev cfa233d7 (sub-repo mobile rev 855b5ad0) (trybot set for Ib1a2f53); waiting_for_machine; (nil *buildlet.Client), 1h45m36s ago 2021-09-16T14:15:15Z checking_for_snapshot 2021-09-16T14:15:15Z finish_checking_for_snapshot after 35ms 2021-09-16T14:15:15Z get_buildlet +6335.7s (now) ``` `host-ios-arm64-corellium-ios: 2/2 (1 missing)` Perhaps the builders need to be rebooted. @eliasnaur @golang/release ",0,x build ios corellium builders have long wait times users have reported long wait times with ios corellium builds • ios corellium running  ios corellium rev sub repo mobile rev trybot set for waiting for machine nil buildlet client ago checking for snapshot finish checking for snapshot after get buildlet now host ios corellium ios missing perhaps the builders need to be rebooted eliasnaur golang release ,0 317315,23671675856.0,IssuesEvent,2022-08-27 13:01:35,golang/go,https://api.github.com/repos/golang/go,closed,"strings, bytes: Title doesn't shield against emoji",Documentation NeedsDecision," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.1 darwin/arm64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""arm64""
GOBIN=""/bin""
GOCACHE=""/Users/wang/Library/Caches/go-build""
GOENV=""/Users/wang/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""arm64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/wang/go/pkg/mod""
GONOPROXY=""gitlab.hexcloud.cn""
GONOSUMDB=""gitlab.hexcloud.cn""
GOOS=""darwin""
GOPATH=""/Users/wang/go""
GOPRIVATE=""gitlab.hexcloud.cn""
GOPROXY=""https://goproxy.io,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_arm64""
GOVCS=""""
GOVERSION=""go1.17.1""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/wang/open/source/go/src/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/fc/5_f38pyn6k915kw7_vvfjhrc0000gn/T/go-build1773033347=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.1 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.17.1
uname -v: Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	11.5.1
BuildVersion:	20G80
lldb --version: lldb-1205.0.28.2
Apple Swift version 5.4.2 (swiftlang-1205.0.28.2 clang-1205.0.19.57)
### What did you do? [playground](https://play.golang.org/p/a0CvAAQCRn8) ### What did you expect to see? ☺☻☹Hello ### What did you see instead? ☺☻☹hello ",1.0,"strings, bytes: Title doesn't shield against emoji - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.1 darwin/arm64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""arm64""
GOBIN=""/bin""
GOCACHE=""/Users/wang/Library/Caches/go-build""
GOENV=""/Users/wang/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""arm64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/wang/go/pkg/mod""
GONOPROXY=""gitlab.hexcloud.cn""
GONOSUMDB=""gitlab.hexcloud.cn""
GOOS=""darwin""
GOPATH=""/Users/wang/go""
GOPRIVATE=""gitlab.hexcloud.cn""
GOPROXY=""https://goproxy.io,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_arm64""
GOVCS=""""
GOVERSION=""go1.17.1""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/wang/open/source/go/src/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/fc/5_f38pyn6k915kw7_vvfjhrc0000gn/T/go-build1773033347=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.1 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.17.1
uname -v: Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	11.5.1
BuildVersion:	20G80
lldb --version: lldb-1205.0.28.2
Apple Swift version 5.4.2 (swiftlang-1205.0.28.2 clang-1205.0.19.57)
### What did you do? [playground](https://play.golang.org/p/a0CvAAQCRn8) ### What did you expect to see? ☺☻☹Hello ### What did you see instead? ☺☻☹hello ",1,strings bytes title doesn t shield against emoji what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env on goarch gobin bin gocache users wang library caches go build goenv users wang library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users wang go pkg mod gonoproxy gitlab hexcloud cn gonosumdb gitlab hexcloud cn goos darwin gopath users wang go goprivate gitlab hexcloud cn goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users wang open source go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders fc t go tmp go build gno record gcc switches fno common goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version wed jun pdt root xnu release productname macos productversion buildversion lldb version lldb apple swift version swiftlang clang 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 what did you expect to see ☺☻☹hello what did you see instead ☺☻☹hello ,1 26718,5282807590.0,IssuesEvent,2017-02-07 19:46:38,golang/go,https://api.github.com/repos/golang/go,closed,runtime/pprof: document the requirement to wait to capture any CPU profile samples,Documentation,"Package's godoc example starts the CPU profiling and defers pprof.StopCPUProfile, but it fails to document that the function need to spend sometime before returning in order for any samples to be collected. We might want to add a time.Sleep to make it more obvious and document it throughly that time is required to collect samples. ``` if err := pprof.StartCPUProfile(f); err != nil { log.Fatal(""could not start CPU profile: "", err) } defer pprof.StopCPUProfile() ```",1.0,"runtime/pprof: document the requirement to wait to capture any CPU profile samples - Package's godoc example starts the CPU profiling and defers pprof.StopCPUProfile, but it fails to document that the function need to spend sometime before returning in order for any samples to be collected. We might want to add a time.Sleep to make it more obvious and document it throughly that time is required to collect samples. ``` if err := pprof.StartCPUProfile(f); err != nil { log.Fatal(""could not start CPU profile: "", err) } defer pprof.StopCPUProfile() ```",1,runtime pprof document the requirement to wait to capture any cpu profile samples package s godoc example starts the cpu profiling and defers pprof stopcpuprofile but it fails to document that the function need to spend sometime before returning in order for any samples to be collected we might want to add a time sleep to make it more obvious and document it throughly that time is required to collect samples if err pprof startcpuprofile f err nil log fatal could not start cpu profile err defer pprof stopcpuprofile ,1 17659,4184067055.0,IssuesEvent,2016-06-23 04:32:07,golang/go,https://api.github.com/repos/golang/go,closed,testing: output failure report to stderr as per docu instead of stdout,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? 1.6.2 (installed via go1.6.2.linux-amd64.tar.gz at https://golang.org/dl/) 2. What operating system and processor architecture are you using (`go env`)? The OS is Fedora 23 (Workstation Edition). The `go env` output doesn't quite capture that fully: GOARCH=""amd64"" GOBIN=""/usr/src/go/bin"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr/src/go"" GORACE="""" GOROOT=""/usr/src/golang-1.6"" GOTOOLDIR=""/usr/src/golang-1.6/pkg/tool/linux_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" 3. What did you do? go code https://play.golang.org/p/6GR6cTzVcM go test case for that code https://play.golang.org/p/ZEJ2iNJMPV Run a simple test case that fails, outputting a t.Fatal(err). 4. What did you expect to see? https://golang.org/pkg/testing/#T indicates that testing logs are accumulated and output to stderr so I expect the t.Fatal() output report to be on stderr. 5. What did you see instead? The report output is on stdout. It seems like something as trivial as https://github.com/tpepper/go/commit/c60fccd1231de145ec81f35b8693000e91eafbe5 (which is on top of tip's changes to allow subtests) could bring the report output in line with the documentation. But as noted in that tentative commit message, this might break users who have coded to the behavior without reporting the inconsistency. Perhaps the answer is to change the documentation, except the enabling the distinction between stdout and stderr is actually useful. ",1.0,"testing: output failure report to stderr as per docu instead of stdout - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? 1.6.2 (installed via go1.6.2.linux-amd64.tar.gz at https://golang.org/dl/) 2. What operating system and processor architecture are you using (`go env`)? The OS is Fedora 23 (Workstation Edition). The `go env` output doesn't quite capture that fully: GOARCH=""amd64"" GOBIN=""/usr/src/go/bin"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr/src/go"" GORACE="""" GOROOT=""/usr/src/golang-1.6"" GOTOOLDIR=""/usr/src/golang-1.6/pkg/tool/linux_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" 3. What did you do? go code https://play.golang.org/p/6GR6cTzVcM go test case for that code https://play.golang.org/p/ZEJ2iNJMPV Run a simple test case that fails, outputting a t.Fatal(err). 4. What did you expect to see? https://golang.org/pkg/testing/#T indicates that testing logs are accumulated and output to stderr so I expect the t.Fatal() output report to be on stderr. 5. What did you see instead? The report output is on stdout. It seems like something as trivial as https://github.com/tpepper/go/commit/c60fccd1231de145ec81f35b8693000e91eafbe5 (which is on top of tip's changes to allow subtests) could bring the report output in line with the documentation. But as noted in that tentative commit message, this might break users who have coded to the behavior without reporting the inconsistency. Perhaps the answer is to change the documentation, except the enabling the distinction between stdout and stderr is actually useful. ",1,testing output failure report to stderr as per docu instead of stdout please answer these questions before submitting your issue thanks what version of go are you using go version installed via linux tar gz at what operating system and processor architecture are you using go env the os is fedora workstation edition the go env output doesn t quite capture that fully goarch gobin usr src go bin goexe gohostarch gohostos linux goos linux gopath usr src go gorace goroot usr src golang gotooldir usr src golang pkg tool linux cc gcc gogccflags fpic pthread fmessage length cxx g cgo enabled what did you do go code go test case for that code run a simple test case that fails outputting a t fatal err what did you expect to see indicates that testing logs are accumulated and output to stderr so i expect the t fatal output report to be on stderr what did you see instead the report output is on stdout it seems like something as trivial as which is on top of tip s changes to allow subtests could bring the report output in line with the documentation but as noted in that tentative commit message this might break users who have coded to the behavior without reporting the inconsistency perhaps the answer is to change the documentation except the enabling the distinction between stdout and stderr is actually useful ,1 21923,4758759430.0,IssuesEvent,2016-10-24 20:27:11,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: RawMessage should marshal without pointer receiver,Documentation,"
The current json.RawMessage implementation defines MarshalJSON on a pointer receiver. 
This causes unexpected behavior when marshalling with non-pointer-receiver objects.

For example:
http://play.golang.org/p/Cf_6zpIKC0

Instead, MarshalJSON should be defined on a non-pointer receiver for json.RawMessage. 
This will continue to work for existing code that uses pointer-receivers, but will
change behavior to work "correctly" on code that accidentally uses
non-pointer-receivers.
",1.0,"encoding/json: RawMessage should marshal without pointer receiver - 
The current json.RawMessage implementation defines MarshalJSON on a pointer receiver. 
This causes unexpected behavior when marshalling with non-pointer-receiver objects.

For example:
http://play.golang.org/p/Cf_6zpIKC0

Instead, MarshalJSON should be defined on a non-pointer receiver for json.RawMessage. 
This will continue to work for existing code that uses pointer-receivers, but will
change behavior to work "correctly" on code that accidentally uses
non-pointer-receivers.
",1,encoding json rawmessage should marshal without pointer receiver the current json rawmessage implementation defines marshaljson on a pointer receiver this causes unexpected behavior when marshalling with non pointer receiver objects for example a href instead marshaljson should be defined on a non pointer receiver for json rawmessage this will continue to work for existing code that uses pointer receivers but will change behavior to work quot correctly quot on code that accidentally uses non pointer receivers ,1 54137,7875095915.0,IssuesEvent,2018-06-25 19:14:22,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document and test behavior of ServeMux with ports,Documentation NeedsFix Testing help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9.2 and 1.10beta1 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/knorton/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/knorton/Documents/2018/01/underpants"" GORACE="""" GOROOT=""/Users/knorton/Documents/2018/01/underpants/go1.10"" GOTMPDIR="""" GOTOOLDIR=""/Users/knorton/Documents/2018/01/underpants/go1.10/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/9k/yc77pqm56jj79pp163xszgn00000gn/T/go-build934488457=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? Consider this Go program: ``` package main import ( ""fmt"" ""log"" ""net/http"" ) func main() { m := http.NewServeMux() m.HandleFunc(""localhost:8080/"", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, ""locahost:8080"") }) log.Panic(http.ListenAndServe("":8080"", m)) } ``` If you use Go 1.8.5: 1. `go run example.go` 2. Visit http://localhost:8080/ 3. You will see the text ""localhost:8080"" display in the browser. If you use Go 1.10beta1 and Go 1.9.2: 1. `go run example.go` 2. Visit http://localhost:8080/ 3. You will get a 404 NotFound. ### What did you expect to see? I expect that compiling the example in 1.9.2 should behave as it did in 1.8.5. More specifically, I would expect Go 1.9.2 to call the handler that I explicitly added for the host `localhost:8080`. ### What did you see instead? Instead, this program called with Go 1.9.2 returns a 404 instead of calling the handler that I added for the host localhost:8080. ### More Details This change seems to have been reviewed at: https://go-review.googlesource.com/c/go/+/38194 This change strips the port from the host only when it is trying to locate a handler. It does not strip the port when the user adds a handler for a host that includes a port number. As a result, trying to add handlers for hosts that include the port no longer works. To make matters worse, these change makes it hard to write http code for hosts with ports that works on both Go 1.9 and Go <1.9. In Go 1.9, the route has to be setup with `m.HandleFunc(""localhost"", ...)` And in Go < 1.9, the route has to be setup with `m.HandleFunc(""localhost:8080"", ...)`. To make the code work on all versions of Go, the handler function needs to be registered for both ""localhost"" and ""localhost:8080"" ",1.0,"net/http: document and test behavior of ServeMux with ports - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.9.2 and 1.10beta1 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/knorton/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/knorton/Documents/2018/01/underpants"" GORACE="""" GOROOT=""/Users/knorton/Documents/2018/01/underpants/go1.10"" GOTMPDIR="""" GOTOOLDIR=""/Users/knorton/Documents/2018/01/underpants/go1.10/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/9k/yc77pqm56jj79pp163xszgn00000gn/T/go-build934488457=/tmp/go-build -gno-record-gcc-switches -fno-common"" ``` ### What did you do? Consider this Go program: ``` package main import ( ""fmt"" ""log"" ""net/http"" ) func main() { m := http.NewServeMux() m.HandleFunc(""localhost:8080/"", func(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, ""locahost:8080"") }) log.Panic(http.ListenAndServe("":8080"", m)) } ``` If you use Go 1.8.5: 1. `go run example.go` 2. Visit http://localhost:8080/ 3. You will see the text ""localhost:8080"" display in the browser. If you use Go 1.10beta1 and Go 1.9.2: 1. `go run example.go` 2. Visit http://localhost:8080/ 3. You will get a 404 NotFound. ### What did you expect to see? I expect that compiling the example in 1.9.2 should behave as it did in 1.8.5. More specifically, I would expect Go 1.9.2 to call the handler that I explicitly added for the host `localhost:8080`. ### What did you see instead? Instead, this program called with Go 1.9.2 returns a 404 instead of calling the handler that I added for the host localhost:8080. ### More Details This change seems to have been reviewed at: https://go-review.googlesource.com/c/go/+/38194 This change strips the port from the host only when it is trying to locate a handler. It does not strip the port when the user adds a handler for a host that includes a port number. As a result, trying to add handlers for hosts that include the port no longer works. To make matters worse, these change makes it hard to write http code for hosts with ports that works on both Go 1.9 and Go <1.9. In Go 1.9, the route has to be setup with `m.HandleFunc(""localhost"", ...)` And in Go < 1.9, the route has to be setup with `m.HandleFunc(""localhost:8080"", ...)`. To make the code work on all versions of Go, the handler function needs to be registered for both ""localhost"" and ""localhost:8080"" ",1,net http document and test behavior of servemux with ports please answer these questions before submitting your issue thanks what version of go are you using go version and does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache users knorton library caches go build goexe gohostarch gohostos darwin goos darwin gopath users knorton documents underpants gorace goroot users knorton documents underpants gotmpdir gotooldir users knorton documents underpants pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do consider this go program package main import fmt log net http func main m http newservemux m handlefunc localhost func w http responsewriter r http request fmt fprintln w locahost log panic http listenandserve m if you use go go run example go visit you will see the text localhost display in the browser if you use go and go go run example go visit you will get a notfound what did you expect to see i expect that compiling the example in should behave as it did in more specifically i would expect go to call the handler that i explicitly added for the host localhost what did you see instead instead this program called with go returns a instead of calling the handler that i added for the host localhost more details this change seems to have been reviewed at this change strips the port from the host only when it is trying to locate a handler it does not strip the port when the user adds a handler for a host that includes a port number as a result trying to add handlers for hosts that include the port no longer works to make matters worse these change makes it hard to write http code for hosts with ports that works on both go and go in go the route has to be setup with m handlefunc localhost and in go the route has to be setup with m handlefunc localhost to make the code work on all versions of go the handler function needs to be registered for both localhost and localhost ,1 98202,11047903658.0,IssuesEvent,2019-12-09 19:59:09,golang/go,https://api.github.com/repos/golang/go,closed,doc: release history webpage contains suboptimal links [1.13 backport],CherryPickApproved Documentation,"@dmitshur requested issue #35988 to be considered for backport to the next 1.13 minor release. > @gopherbot, could you please be so kind as to open two backport issues: one for Go 1.13 and another for Go 1.12. This is a documentation fix. ",1.0,"doc: release history webpage contains suboptimal links [1.13 backport] - @dmitshur requested issue #35988 to be considered for backport to the next 1.13 minor release. > @gopherbot, could you please be so kind as to open two backport issues: one for Go 1.13 and another for Go 1.12. This is a documentation fix. ",1,doc release history webpage contains suboptimal links dmitshur requested issue to be considered for backport to the next minor release gopherbot could you please be so kind as to open two backport issues one for go and another for go this is a documentation fix ,1 135575,11011703792.0,IssuesEvent,2019-12-04 16:46:34,golang/go,https://api.github.com/repos/golang/go,closed,runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet,NeedsInvestigation Testing,"There was a timeout in the `image/gif` test, but from the symptoms it looks more like a runtime bug to me: one of the threads is idle on `runtime.futex` via `runtime.mcall`, and the the other one says `goroutine running on other thread; stack unavailable`. That combination of symptoms is similar to #32327, although the path from `runtime.mcall` to `runtime.futex` differs. https://build.golang.org/log/e08f0037958f84cf1b1fe6b9f80c8208d332104c ``` SIGQUIT: quit PC=0x6be3c m=0 sigcode=0 goroutine 0 [idle]: runtime.futex(0x2ad150, 0x8000000002, 0x0, 0x0, 0x12000, 0x46d40, 0x46704, 0xc00035e780, 0x46d7c, 0xc0000384c8, ...) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/sys_linux_ppc64x.s:472 +0x1c runtime.futexsleep(0x2ad150, 0x200046708, 0xffffffffffffffff) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/os_linux.go:44 +0x3c runtime.lock(0x2ad150) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/lock_futex.go:102 +0x1bc runtime.exitsyscall0(0xc000076180) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/proc.go:3119 +0x7c runtime.mcall(0xc000076180) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/asm_ppc64x.s:202 +0x58 goroutine 1 [chan receive, 3 minutes]: testing.(*T).Run(0xc0000acd00, 0x18dbfc, 0x1b, 0x193748, 0x100000000000349) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:961 +0x304 testing.runTests.func1(0xc0000ac000) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1207 +0x78 testing.tRunner(0xc0000ac000, 0xc000058d48) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:909 +0xc8 testing.runTests(0xc00008c080, 0x2a7dc0, 0x18, 0x18, 0x0) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1205 +0x27c testing.(*M).Run(0xc0000a8000, 0x0) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1122 +0x158 main.main() _testmain.go:96 +0x130 goroutine 30 [running]: goroutine running on other thread; stack unavailable created by testing.(*T).Run /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:960 +0x2e8 r0 0xdd r1 0x3fffd047b228 r2 0x8000000000 r3 0x2ad150 r4 0x80 r5 0x2 r6 0x0 r7 0x0 r8 0x0 r9 0x0 r10 0x0 r11 0x0 r12 0x0 r13 0x0 r14 0x1a0b0 r15 0xc000030e78 r16 0x0 r17 0xc000025900 r18 0x0 r19 0x1b4782 r20 0xc000020010 r21 0x2ad840 r22 0x0 r23 0x0 r24 0x8 r25 0x3fff8b55a520 r26 0x3fff8b55a578 r27 0x73 r28 0x72 r29 0x1 r30 0x2ad2a0 r31 0x19bbc pc 0x6be3c ctr 0x0 link 0x3a62c xer 0x0 ccr 0x54400002 trap 0xc00 *** Test killed with quit: ran too long (4m0s). FAIL image/gif 240.002s ``` CC @laboger @aclements @mknyszek @randall77 ",1.0,"runtime: apparent deadlock in image/gif test on linux-ppc64-buildlet - There was a timeout in the `image/gif` test, but from the symptoms it looks more like a runtime bug to me: one of the threads is idle on `runtime.futex` via `runtime.mcall`, and the the other one says `goroutine running on other thread; stack unavailable`. That combination of symptoms is similar to #32327, although the path from `runtime.mcall` to `runtime.futex` differs. https://build.golang.org/log/e08f0037958f84cf1b1fe6b9f80c8208d332104c ``` SIGQUIT: quit PC=0x6be3c m=0 sigcode=0 goroutine 0 [idle]: runtime.futex(0x2ad150, 0x8000000002, 0x0, 0x0, 0x12000, 0x46d40, 0x46704, 0xc00035e780, 0x46d7c, 0xc0000384c8, ...) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/sys_linux_ppc64x.s:472 +0x1c runtime.futexsleep(0x2ad150, 0x200046708, 0xffffffffffffffff) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/os_linux.go:44 +0x3c runtime.lock(0x2ad150) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/lock_futex.go:102 +0x1bc runtime.exitsyscall0(0xc000076180) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/proc.go:3119 +0x7c runtime.mcall(0xc000076180) /tmp/workdir-host-linux-ppc64-osu/go/src/runtime/asm_ppc64x.s:202 +0x58 goroutine 1 [chan receive, 3 minutes]: testing.(*T).Run(0xc0000acd00, 0x18dbfc, 0x1b, 0x193748, 0x100000000000349) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:961 +0x304 testing.runTests.func1(0xc0000ac000) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1207 +0x78 testing.tRunner(0xc0000ac000, 0xc000058d48) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:909 +0xc8 testing.runTests(0xc00008c080, 0x2a7dc0, 0x18, 0x18, 0x0) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1205 +0x27c testing.(*M).Run(0xc0000a8000, 0x0) /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:1122 +0x158 main.main() _testmain.go:96 +0x130 goroutine 30 [running]: goroutine running on other thread; stack unavailable created by testing.(*T).Run /tmp/workdir-host-linux-ppc64-osu/go/src/testing/testing.go:960 +0x2e8 r0 0xdd r1 0x3fffd047b228 r2 0x8000000000 r3 0x2ad150 r4 0x80 r5 0x2 r6 0x0 r7 0x0 r8 0x0 r9 0x0 r10 0x0 r11 0x0 r12 0x0 r13 0x0 r14 0x1a0b0 r15 0xc000030e78 r16 0x0 r17 0xc000025900 r18 0x0 r19 0x1b4782 r20 0xc000020010 r21 0x2ad840 r22 0x0 r23 0x0 r24 0x8 r25 0x3fff8b55a520 r26 0x3fff8b55a578 r27 0x73 r28 0x72 r29 0x1 r30 0x2ad2a0 r31 0x19bbc pc 0x6be3c ctr 0x0 link 0x3a62c xer 0x0 ccr 0x54400002 trap 0xc00 *** Test killed with quit: ran too long (4m0s). FAIL image/gif 240.002s ``` CC @laboger @aclements @mknyszek @randall77 ",0,runtime apparent deadlock in image gif test on linux buildlet there was a timeout in the image gif test but from the symptoms it looks more like a runtime bug to me one of the threads is idle on runtime futex via runtime mcall and the the other one says goroutine running on other thread stack unavailable that combination of symptoms is similar to although the path from runtime mcall to runtime futex differs sigquit quit pc m sigcode goroutine runtime futex tmp workdir host linux osu go src runtime sys linux s runtime futexsleep tmp workdir host linux osu go src runtime os linux go runtime lock tmp workdir host linux osu go src runtime lock futex go runtime tmp workdir host linux osu go src runtime proc go runtime mcall tmp workdir host linux osu go src runtime asm s goroutine testing t run tmp workdir host linux osu go src testing testing go testing runtests tmp workdir host linux osu go src testing testing go testing trunner tmp workdir host linux osu go src testing testing go testing runtests tmp workdir host linux osu go src testing testing go testing m run tmp workdir host linux osu go src testing testing go main main testmain go goroutine goroutine running on other thread stack unavailable created by testing t run tmp workdir host linux osu go src testing testing go pc ctr link xer ccr trap test killed with quit ran too long fail image gif cc laboger aclements mknyszek ,0 69022,9239247735.0,IssuesEvent,2019-03-14 00:33:31,golang/go,https://api.github.com/repos/golang/go,closed,spec: apparent contradiction for passing of slice argument to variadic parameter,Documentation NeedsFix WaitingForInfo,"``` Version of November 16, 2018 ``` Section [""Passing arguments to ... parameters""](https://golang.org/ref/spec#Passing_arguments_to_..._parameters) says: > If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created. Notice the use of the word ""may"". This appears to contradict what I understand to be the case in practice (i.e. that it _will_ be passed unchanged, for reasons of efficiency) but also the example that follows: > ... who will have the same value as s with the same underlying array. Notice the use of the word ""will"". cc @griesemer FYI @mvdan @rogpeppe ",1.0,"spec: apparent contradiction for passing of slice argument to variadic parameter - ``` Version of November 16, 2018 ``` Section [""Passing arguments to ... parameters""](https://golang.org/ref/spec#Passing_arguments_to_..._parameters) says: > If the final argument is assignable to a slice type []T, it may be passed unchanged as the value for a ...T parameter if the argument is followed by .... In this case no new slice is created. Notice the use of the word ""may"". This appears to contradict what I understand to be the case in practice (i.e. that it _will_ be passed unchanged, for reasons of efficiency) but also the example that follows: > ... who will have the same value as s with the same underlying array. Notice the use of the word ""will"". cc @griesemer FYI @mvdan @rogpeppe ",1,spec apparent contradiction for passing of slice argument to variadic parameter version of november section says if the final argument is assignable to a slice type t it may be passed unchanged as the value for a t parameter if the argument is followed by in this case no new slice is created notice the use of the word may this appears to contradict what i understand to be the case in practice i e that it will be passed unchanged for reasons of efficiency but also the example that follows who will have the same value as s with the same underlying array notice the use of the word will cc griesemer fyi mvdan rogpeppe ,1 51981,6205858289.0,IssuesEvent,2017-07-06 17:04:59,golang/go,https://api.github.com/repos/golang/go,closed,runtime: TestRWMutex is flaky?,NeedsFix Testing,"Please answer these questions before submitting your issue. Thanks! #### 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. ```bash for i in `seq 100`; do go test -v runtime -run ""TestRWMutex""; done ``` #### What did you expect to see? PASS * 100 #### What did you see instead? ``` === RUN TestRWMutex SIGQUIT: quit PC=0x10625b6 m=2 sigcode=0 goroutine 0 [idle]: runtime.usleep(0x8b00002710, 0x0, 0x68c71d5b2f, 0x45d964b800, 0x271000000000, 0x8bb25b57c4, 0x45d964b800, 0x3, 0x0, 0x68c71d5b2f, ...) /Users/hiro/go/src/runtime/sys_darwin_amd64.s:323 +0x36 fp=0x700006055de0 sp=0x700006055dc0 pc=0x10625b6 runtime.sysmon() /Users/hiro/go/src/runtime/proc.go:3799 +0xa8 fp=0x700006055e68 sp=0x700006055de0 pc=0x1039a08 runtime.mstart1() /Users/hiro/go/src/runtime/proc.go:1172 +0x11e fp=0x700006055e90 sp=0x700006055e68 pc=0x103285e runtime.mstart() /Users/hiro/go/src/runtime/proc.go:1142 +0x64 fp=0x700006055ea8 sp=0x700006055e90 pc=0x1032734 goroutine 1 [chan receive]: runtime.gopark(0x131a290, 0xc420076418, 0x1308f6e, 0xc, 0xc420051b17, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc420051ac8 sp=0xc420051a98 pc=0x102fa7c runtime.goparkunlock(0xc420076418, 0x1308f6e, 0xc, 0xc4200e8017, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc420051b08 sp=0xc420051ac8 pc=0x102fb6e runtime.chanrecv(0xc4200763c0, 0x0, 0xc420051b01, 0x10ebc14) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc420051bb8 sp=0xc420051b08 pc=0x1005dc4 runtime.chanrecv1(0xc4200763c0, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc420051be8 sp=0xc420051bb8 pc=0x1005a6b testing.(*T).Run(0xc4200e2000, 0x130879c, 0xb, 0x131b2e0, 0x108f201) /Users/hiro/go/src/testing/testing.go:801 +0x332 fp=0xc420051c98 sp=0xc420051be8 pc=0x10ebc32 testing.runTests.func1(0xc4200e2000) /Users/hiro/go/src/testing/testing.go:1053 +0x64 fp=0xc420051ce8 sp=0xc420051c98 pc=0x10efd04 testing.tRunner(0xc4200e2000, 0xc420051d98) /Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc420051d10 sp=0xc420051ce8 pc=0x10eb8a0 testing.runTests(0xc42000c300, 0x1498000, 0xd7, 0xd7, 0x5f) /Users/hiro/go/src/testing/testing.go:1051 +0x2d8 fp=0xc420051dc8 sp=0xc420051d10 pc=0x10ed688 testing.(*M).Run(0xc420051f18, 0x12474b6) /Users/hiro/go/src/testing/testing.go:932 +0x111 fp=0xc420051ec0 sp=0xc420051dc8 pc=0x10ec031 runtime_test.TestMain(0xc420051f18) /Users/hiro/go/src/runtime/crash_test.go:28 +0x2f fp=0xc420051f10 sp=0xc420051ec0 pc=0x1216c9f main.main() runtime/_test/_testmain.go:902 +0xdb fp=0xc420051f80 sp=0xc420051f10 pc=0x126701b runtime.main() /Users/hiro/go/src/runtime/proc.go:185 +0x20d fp=0xc420051fe0 sp=0xc420051f80 pc=0x102f5dd runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420051fe8 sp=0xc420051fe0 pc=0x10612f1 goroutine 2 [force gc (idle)]: runtime.gopark(0x131a290, 0x149a0c0, 0x130a49c, 0xf, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002c768 sp=0xc42002c738 pc=0x102fa7c runtime.goparkunlock(0x149a0c0, 0x130a49c, 0xf, 0xc420000114, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002c7a8 sp=0xc42002c768 pc=0x102fb6e runtime.forcegchelper() /Users/hiro/go/src/runtime/proc.go:235 +0xcc fp=0xc42002c7e0 sp=0xc42002c7a8 pc=0x102f89c runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002c7e8 sp=0xc42002c7e0 pc=0x10612f1 created by runtime.init.4 /Users/hiro/go/src/runtime/proc.go:224 +0x35 goroutine 3 [GC sweep wait]: runtime.gopark(0x131a290, 0x149a3c0, 0x130941f, 0xd, 0x1021014, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002cf60 sp=0xc42002cf30 pc=0x102fa7c runtime.goparkunlock(0x149a3c0, 0x130941f, 0xd, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002cfa0 sp=0xc42002cf60 pc=0x102fb6e runtime.bgsweep(0xc420020070) /Users/hiro/go/src/runtime/mgcsweep.go:52 +0xa3 fp=0xc42002cfd8 sp=0xc42002cfa0 pc=0x10210d3 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002cfe0 sp=0xc42002cfd8 pc=0x10612f1 created by runtime.gcenable /Users/hiro/go/src/runtime/mgc.go:216 +0x58 goroutine 4 [finalizer wait]: runtime.gopark(0x131a290, 0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002d700 sp=0xc42002d6d0 pc=0x102fa7c runtime.goparkunlock(0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002d740 sp=0xc42002d700 pc=0x102fb6e runtime.runfinq() /Users/hiro/go/src/runtime/mfinal.go:175 +0xb8 fp=0xc42002d7e0 sp=0xc42002d740 pc=0x1017ed8 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002d7e8 sp=0xc42002d7e0 pc=0x10612f1 created by runtime.createfing /Users/hiro/go/src/runtime/mfinal.go:156 +0x62 goroutine 5 [syscall]: runtime.notetsleepg(0x14ba2c0, 0xffffffffffffffff, 0x0) /Users/hiro/go/src/runtime/lock_sema.go:280 +0x4b fp=0xc42002df80 sp=0xc42002df40 pc=0x10119eb os/signal.signal_recv(0x0) /Users/hiro/go/src/runtime/sigqueue.go:131 +0xa7 fp=0xc42002dfa8 sp=0xc42002df80 pc=0x1045807 os/signal.loop() /Users/hiro/go/src/os/signal/signal_unix.go:22 +0x22 fp=0xc42002dfe0 sp=0xc42002dfa8 pc=0x10e4232 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002dfe8 sp=0xc42002dfe0 pc=0x10612f1 created by os/signal.init.0 /Users/hiro/go/src/os/signal/signal_unix.go:28 +0x41 goroutine 6 [select, locked to thread]: runtime.gopark(0x131a2d8, 0x0, 0x1306abf, 0x6, 0x18, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42003aca0 sp=0xc42003ac70 pc=0x102fa7c runtime.selectgo(0xc42003af50, 0xc420076180) /Users/hiro/go/src/runtime/select.go:395 +0x1138 fp=0xc42003af18 sp=0xc42003aca0 pc=0x103fff8 runtime.ensureSigM.func1() /Users/hiro/go/src/runtime/signal_unix.go:511 +0x1fe fp=0xc42003afe0 sp=0xc42003af18 pc=0x105da9e runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42003afe8 sp=0xc42003afe0 pc=0x10612f1 created by runtime.ensureSigM /Users/hiro/go/src/runtime/signal_unix.go:494 +0xda goroutine 7 [chan receive]: runtime.gopark(0x131a290, 0xc42005e358, 0x1308f6e, 0xc, 0xc420024117, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002ee80 sp=0xc42002ee50 pc=0x102fa7c runtime.goparkunlock(0xc42005e358, 0x1308f6e, 0xc, 0x17, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002eec0 sp=0xc42002ee80 pc=0x102fb6e runtime.chanrecv(0xc42005e300, 0x0, 0x1, 0x0) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002ef70 sp=0xc42002eec0 pc=0x1005dc4 runtime.chanrecv1(0xc42005e300, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002efa0 sp=0xc42002ef70 pc=0x1005a6b testing.(*M).before.func1(0xc42005e300) /Users/hiro/go/src/testing/testing.go:1111 +0x38 fp=0xc42002efd8 sp=0xc42002efa0 pc=0x10efd98 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002efe0 sp=0xc42002efd8 pc=0x10612f1 created by testing.(*M).before /Users/hiro/go/src/testing/testing.go:1110 +0x191 goroutine 8 [chan receive]: runtime.gopark(0x131a290, 0xc420106058, 0x1308f6e, 0xc, 0xc42002f617, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002f5e8 sp=0xc42002f5b8 pc=0x102fa7c runtime.goparkunlock(0xc420106058, 0x1308f6e, 0xc, 0x1010f0120104017, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002f628 sp=0xc42002f5e8 pc=0x102fb6e runtime.chanrecv(0xc420106000, 0x0, 0xc42002f701, 0x1249879) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002f6d8 sp=0xc42002f628 pc=0x1005dc4 runtime.chanrecv1(0xc420106000, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002f708 sp=0xc42002f6d8 pc=0x1005a6b runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8) /Users/hiro/go/src/runtime/rwmutex_test.go:103 +0x1eb fp=0xc42002f770 sp=0xc42002f708 pc=0x12498ab runtime_test.TestRWMutex(0xc4200e20f0) /Users/hiro/go/src/runtime/rwmutex_test.go:118 +0x12f fp=0xc42002f7a8 sp=0xc42002f770 pc=0x1249a0f testing.tRunner(0xc4200e20f0, 0x131b2e0) /Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc42002f7d0 sp=0xc42002f7a8 pc=0x10eb8a0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002f7d8 sp=0xc42002f7d0 pc=0x10612f1 created by testing.(*T).Run /Users/hiro/go/src/testing/testing.go:800 +0x314 goroutine 50 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1 goroutine 51 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 52 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010efc0 sp=0xc42010efb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010efc8 sp=0xc42010efc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 53 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010f7c0 sp=0xc42010f7b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010f7c8 sp=0xc42010f7c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 54 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 55 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 56 [runnable]: runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:71 fp=0xc420110fc0 sp=0xc420110fb8 pc=0x1249540 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420110fc8 sp=0xc420110fc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:97 +0x16d goroutine 57 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4201117c0 sp=0xc4201117b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201117c8 sp=0xc4201117c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 58 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc420111fc0 sp=0xc420111fb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420111fc8 sp=0xc420111fc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 59 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4200f47c0 sp=0xc4200f47b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f47c8 sp=0xc4200f47c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 60 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010afc0 sp=0xc42010afb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010afc8 sp=0xc42010afc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 61 [runnable]: runtime.(*RWMutex).RUnlock(0xc420104000) /Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010b7c8 sp=0xc42010b7c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 rax 0x4 rbx 0x3 rcx 0x700006055dc0 rdx 0x0 rdi 0x0 rsi 0x0 rbp 0x700006055dd0 rsp 0x700006055dc0 r8 0x700006055dc0 r9 0x8 r10 0x0 r11 0x246 r12 0x3b4a277fed96 r13 0xb03 r14 0x10326d0 r15 0x1602620 rip 0x10625b6 rflags 0x247 cs 0x7 fs 0x0 gs 0x0 *** Test killed with quit: ran too long (10m0s). FAIL runtime 600.024s ``` #### Does this issue reproduce with the latest release (go1.8.3)? #### System details ``` go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/hiro/.go"" GORACE="""" GOROOT=""/Users/hiro/go"" GOTOOLDIR=""/Users/hiro/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wq/dwn8hs0x7njbzty9f68y61700000gn/T/go-build091579411=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOROOT/bin/go version: go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64 GOROOT/bin/go tool compile -V: compile version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 X:framepointer uname -v: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.12.5 BuildVersion: 16F73 lldb --version: lldb-370.0.42 Swift-3.1 gdb --version: GNU gdb (GDB) 7.12.1 ``` FWIW, `sync.TestRWMutex` doesn't fail.",1.0,"runtime: TestRWMutex is flaky? - Please answer these questions before submitting your issue. Thanks! #### 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. ```bash for i in `seq 100`; do go test -v runtime -run ""TestRWMutex""; done ``` #### What did you expect to see? PASS * 100 #### What did you see instead? ``` === RUN TestRWMutex SIGQUIT: quit PC=0x10625b6 m=2 sigcode=0 goroutine 0 [idle]: runtime.usleep(0x8b00002710, 0x0, 0x68c71d5b2f, 0x45d964b800, 0x271000000000, 0x8bb25b57c4, 0x45d964b800, 0x3, 0x0, 0x68c71d5b2f, ...) /Users/hiro/go/src/runtime/sys_darwin_amd64.s:323 +0x36 fp=0x700006055de0 sp=0x700006055dc0 pc=0x10625b6 runtime.sysmon() /Users/hiro/go/src/runtime/proc.go:3799 +0xa8 fp=0x700006055e68 sp=0x700006055de0 pc=0x1039a08 runtime.mstart1() /Users/hiro/go/src/runtime/proc.go:1172 +0x11e fp=0x700006055e90 sp=0x700006055e68 pc=0x103285e runtime.mstart() /Users/hiro/go/src/runtime/proc.go:1142 +0x64 fp=0x700006055ea8 sp=0x700006055e90 pc=0x1032734 goroutine 1 [chan receive]: runtime.gopark(0x131a290, 0xc420076418, 0x1308f6e, 0xc, 0xc420051b17, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc420051ac8 sp=0xc420051a98 pc=0x102fa7c runtime.goparkunlock(0xc420076418, 0x1308f6e, 0xc, 0xc4200e8017, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc420051b08 sp=0xc420051ac8 pc=0x102fb6e runtime.chanrecv(0xc4200763c0, 0x0, 0xc420051b01, 0x10ebc14) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc420051bb8 sp=0xc420051b08 pc=0x1005dc4 runtime.chanrecv1(0xc4200763c0, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc420051be8 sp=0xc420051bb8 pc=0x1005a6b testing.(*T).Run(0xc4200e2000, 0x130879c, 0xb, 0x131b2e0, 0x108f201) /Users/hiro/go/src/testing/testing.go:801 +0x332 fp=0xc420051c98 sp=0xc420051be8 pc=0x10ebc32 testing.runTests.func1(0xc4200e2000) /Users/hiro/go/src/testing/testing.go:1053 +0x64 fp=0xc420051ce8 sp=0xc420051c98 pc=0x10efd04 testing.tRunner(0xc4200e2000, 0xc420051d98) /Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc420051d10 sp=0xc420051ce8 pc=0x10eb8a0 testing.runTests(0xc42000c300, 0x1498000, 0xd7, 0xd7, 0x5f) /Users/hiro/go/src/testing/testing.go:1051 +0x2d8 fp=0xc420051dc8 sp=0xc420051d10 pc=0x10ed688 testing.(*M).Run(0xc420051f18, 0x12474b6) /Users/hiro/go/src/testing/testing.go:932 +0x111 fp=0xc420051ec0 sp=0xc420051dc8 pc=0x10ec031 runtime_test.TestMain(0xc420051f18) /Users/hiro/go/src/runtime/crash_test.go:28 +0x2f fp=0xc420051f10 sp=0xc420051ec0 pc=0x1216c9f main.main() runtime/_test/_testmain.go:902 +0xdb fp=0xc420051f80 sp=0xc420051f10 pc=0x126701b runtime.main() /Users/hiro/go/src/runtime/proc.go:185 +0x20d fp=0xc420051fe0 sp=0xc420051f80 pc=0x102f5dd runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420051fe8 sp=0xc420051fe0 pc=0x10612f1 goroutine 2 [force gc (idle)]: runtime.gopark(0x131a290, 0x149a0c0, 0x130a49c, 0xf, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002c768 sp=0xc42002c738 pc=0x102fa7c runtime.goparkunlock(0x149a0c0, 0x130a49c, 0xf, 0xc420000114, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002c7a8 sp=0xc42002c768 pc=0x102fb6e runtime.forcegchelper() /Users/hiro/go/src/runtime/proc.go:235 +0xcc fp=0xc42002c7e0 sp=0xc42002c7a8 pc=0x102f89c runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002c7e8 sp=0xc42002c7e0 pc=0x10612f1 created by runtime.init.4 /Users/hiro/go/src/runtime/proc.go:224 +0x35 goroutine 3 [GC sweep wait]: runtime.gopark(0x131a290, 0x149a3c0, 0x130941f, 0xd, 0x1021014, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002cf60 sp=0xc42002cf30 pc=0x102fa7c runtime.goparkunlock(0x149a3c0, 0x130941f, 0xd, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002cfa0 sp=0xc42002cf60 pc=0x102fb6e runtime.bgsweep(0xc420020070) /Users/hiro/go/src/runtime/mgcsweep.go:52 +0xa3 fp=0xc42002cfd8 sp=0xc42002cfa0 pc=0x10210d3 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002cfe0 sp=0xc42002cfd8 pc=0x10612f1 created by runtime.gcenable /Users/hiro/go/src/runtime/mgc.go:216 +0x58 goroutine 4 [finalizer wait]: runtime.gopark(0x131a290, 0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002d700 sp=0xc42002d6d0 pc=0x102fa7c runtime.goparkunlock(0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002d740 sp=0xc42002d700 pc=0x102fb6e runtime.runfinq() /Users/hiro/go/src/runtime/mfinal.go:175 +0xb8 fp=0xc42002d7e0 sp=0xc42002d740 pc=0x1017ed8 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002d7e8 sp=0xc42002d7e0 pc=0x10612f1 created by runtime.createfing /Users/hiro/go/src/runtime/mfinal.go:156 +0x62 goroutine 5 [syscall]: runtime.notetsleepg(0x14ba2c0, 0xffffffffffffffff, 0x0) /Users/hiro/go/src/runtime/lock_sema.go:280 +0x4b fp=0xc42002df80 sp=0xc42002df40 pc=0x10119eb os/signal.signal_recv(0x0) /Users/hiro/go/src/runtime/sigqueue.go:131 +0xa7 fp=0xc42002dfa8 sp=0xc42002df80 pc=0x1045807 os/signal.loop() /Users/hiro/go/src/os/signal/signal_unix.go:22 +0x22 fp=0xc42002dfe0 sp=0xc42002dfa8 pc=0x10e4232 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002dfe8 sp=0xc42002dfe0 pc=0x10612f1 created by os/signal.init.0 /Users/hiro/go/src/os/signal/signal_unix.go:28 +0x41 goroutine 6 [select, locked to thread]: runtime.gopark(0x131a2d8, 0x0, 0x1306abf, 0x6, 0x18, 0x1) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42003aca0 sp=0xc42003ac70 pc=0x102fa7c runtime.selectgo(0xc42003af50, 0xc420076180) /Users/hiro/go/src/runtime/select.go:395 +0x1138 fp=0xc42003af18 sp=0xc42003aca0 pc=0x103fff8 runtime.ensureSigM.func1() /Users/hiro/go/src/runtime/signal_unix.go:511 +0x1fe fp=0xc42003afe0 sp=0xc42003af18 pc=0x105da9e runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42003afe8 sp=0xc42003afe0 pc=0x10612f1 created by runtime.ensureSigM /Users/hiro/go/src/runtime/signal_unix.go:494 +0xda goroutine 7 [chan receive]: runtime.gopark(0x131a290, 0xc42005e358, 0x1308f6e, 0xc, 0xc420024117, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002ee80 sp=0xc42002ee50 pc=0x102fa7c runtime.goparkunlock(0xc42005e358, 0x1308f6e, 0xc, 0x17, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002eec0 sp=0xc42002ee80 pc=0x102fb6e runtime.chanrecv(0xc42005e300, 0x0, 0x1, 0x0) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002ef70 sp=0xc42002eec0 pc=0x1005dc4 runtime.chanrecv1(0xc42005e300, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002efa0 sp=0xc42002ef70 pc=0x1005a6b testing.(*M).before.func1(0xc42005e300) /Users/hiro/go/src/testing/testing.go:1111 +0x38 fp=0xc42002efd8 sp=0xc42002efa0 pc=0x10efd98 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002efe0 sp=0xc42002efd8 pc=0x10612f1 created by testing.(*M).before /Users/hiro/go/src/testing/testing.go:1110 +0x191 goroutine 8 [chan receive]: runtime.gopark(0x131a290, 0xc420106058, 0x1308f6e, 0xc, 0xc42002f617, 0x3) /Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002f5e8 sp=0xc42002f5b8 pc=0x102fa7c runtime.goparkunlock(0xc420106058, 0x1308f6e, 0xc, 0x1010f0120104017, 0x3) /Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002f628 sp=0xc42002f5e8 pc=0x102fb6e runtime.chanrecv(0xc420106000, 0x0, 0xc42002f701, 0x1249879) /Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002f6d8 sp=0xc42002f628 pc=0x1005dc4 runtime.chanrecv1(0xc420106000, 0x0) /Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002f708 sp=0xc42002f6d8 pc=0x1005a6b runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8) /Users/hiro/go/src/runtime/rwmutex_test.go:103 +0x1eb fp=0xc42002f770 sp=0xc42002f708 pc=0x12498ab runtime_test.TestRWMutex(0xc4200e20f0) /Users/hiro/go/src/runtime/rwmutex_test.go:118 +0x12f fp=0xc42002f7a8 sp=0xc42002f770 pc=0x1249a0f testing.tRunner(0xc4200e20f0, 0x131b2e0) /Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc42002f7d0 sp=0xc42002f7a8 pc=0x10eb8a0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002f7d8 sp=0xc42002f7d0 pc=0x10612f1 created by testing.(*T).Run /Users/hiro/go/src/testing/testing.go:800 +0x314 goroutine 50 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1 goroutine 51 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 52 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010efc0 sp=0xc42010efb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010efc8 sp=0xc42010efc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 53 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010f7c0 sp=0xc42010f7b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010f7c8 sp=0xc42010f7c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 54 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 55 [running]: goroutine running on other thread; stack unavailable created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105 goroutine 56 [runnable]: runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:71 fp=0xc420110fc0 sp=0xc420110fb8 pc=0x1249540 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420110fc8 sp=0xc420110fc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:97 +0x16d goroutine 57 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4201117c0 sp=0xc4201117b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201117c8 sp=0xc4201117c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 58 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc420111fc0 sp=0xc420111fb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420111fc8 sp=0xc420111fc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 59 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4200f47c0 sp=0xc4200f47b8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f47c8 sp=0xc4200f47c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 60 [runnable]: runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010afc0 sp=0xc42010afb8 pc=0x12493c0 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010afc8 sp=0xc42010afc0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 goroutine 61 [runnable]: runtime.(*RWMutex).RUnlock(0xc420104000) /Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000) /Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405 runtime.goexit() /Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010b7c8 sp=0xc42010b7c0 pc=0x10612f1 created by runtime_test.HammerRWMutex /Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9 rax 0x4 rbx 0x3 rcx 0x700006055dc0 rdx 0x0 rdi 0x0 rsi 0x0 rbp 0x700006055dd0 rsp 0x700006055dc0 r8 0x700006055dc0 r9 0x8 r10 0x0 r11 0x246 r12 0x3b4a277fed96 r13 0xb03 r14 0x10326d0 r15 0x1602620 rip 0x10625b6 rflags 0x247 cs 0x7 fs 0x0 gs 0x0 *** Test killed with quit: ran too long (10m0s). FAIL runtime 600.024s ``` #### Does this issue reproduce with the latest release (go1.8.3)? #### System details ``` go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/hiro/.go"" GORACE="""" GOROOT=""/Users/hiro/go"" GOTOOLDIR=""/Users/hiro/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wq/dwn8hs0x7njbzty9f68y61700000gn/T/go-build091579411=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" GOROOT/bin/go version: go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64 GOROOT/bin/go tool compile -V: compile version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 X:framepointer uname -v: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.12.5 BuildVersion: 16F73 lldb --version: lldb-370.0.42 Swift-3.1 gdb --version: GNU gdb (GDB) 7.12.1 ``` FWIW, `sync.TestRWMutex` doesn't fail.",0,runtime testrwmutex is flaky please answer these questions before submitting your issue thanks 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 bash for i in seq do go test v runtime run testrwmutex done what did you expect to see pass what did you see instead run testrwmutex sigquit quit pc m sigcode goroutine runtime usleep users hiro go src runtime sys darwin s fp sp pc runtime sysmon users hiro go src runtime proc go fp sp pc runtime users hiro go src runtime proc go fp sp pc runtime mstart users hiro go src runtime proc go fp sp pc goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime chanrecv users hiro go src runtime chan go fp sp pc runtime users hiro go src runtime chan go fp sp pc testing t run users hiro go src testing testing go fp sp pc testing runtests users hiro go src testing testing go fp sp pc testing trunner users hiro go src testing testing go fp sp pc testing runtests users hiro go src testing testing go fp sp pc testing m run users hiro go src testing testing go fp sp pc runtime test testmain users hiro go src runtime crash test go fp sp pc main main runtime test testmain go fp sp pc runtime main users hiro go src runtime proc go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime forcegchelper users hiro go src runtime proc go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime init users hiro go src runtime proc go goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime bgsweep users hiro go src runtime mgcsweep go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime gcenable users hiro go src runtime mgc go goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime runfinq users hiro go src runtime mfinal go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime createfing users hiro go src runtime mfinal go goroutine runtime notetsleepg users hiro go src runtime lock sema go fp sp pc os signal signal recv users hiro go src runtime sigqueue go fp sp pc os signal loop users hiro go src os signal signal unix go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by os signal init users hiro go src os signal signal unix go goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime selectgo users hiro go src runtime select go fp sp pc runtime ensuresigm users hiro go src runtime signal unix go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime ensuresigm users hiro go src runtime signal unix go goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime chanrecv users hiro go src runtime chan go fp sp pc runtime users hiro go src runtime chan go fp sp pc testing m before users hiro go src testing testing go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by testing m before users hiro go src testing testing go goroutine runtime gopark users hiro go src runtime proc go fp sp pc runtime goparkunlock users hiro go src runtime proc go fp sp pc runtime chanrecv users hiro go src runtime chan go fp sp pc runtime users hiro go src runtime chan go fp sp pc runtime test hammerrwmutex users hiro go src runtime rwmutex test go fp sp pc runtime test testrwmutex users hiro go src runtime rwmutex test go fp sp pc testing trunner users hiro go src testing testing go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by testing t run users hiro go src testing testing go goroutine goroutine running on other thread stack unavailable created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine goroutine running on other thread stack unavailable created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine goroutine running on other thread stack unavailable created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine goroutine running on other thread stack unavailable created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test writer users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go goroutine runtime rwmutex runlock users hiro go src runtime export test go fp sp pc runtime test reader users hiro go src runtime rwmutex test go fp sp pc runtime goexit users hiro go src runtime asm s fp sp pc created by runtime test hammerrwmutex users hiro go src runtime rwmutex test go rax rbx rcx rdx rdi rsi rbp rsp rip rflags cs fs gs test killed with quit ran too long fail runtime does this issue reproduce with the latest release system details go version devel mon jul darwin goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users hiro go gorace goroot users hiro go gotooldir users hiro go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders wq t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config goroot bin go version go version devel mon jul darwin goroot bin go tool compile v compile version devel mon jul x framepointer uname v darwin kernel version fri apr pdt root xnu release productname mac os x productversion buildversion lldb version lldb swift gdb version gnu gdb gdb fwiw sync testrwmutex doesn t fail ,0 3737,2783007638.0,IssuesEvent,2015-05-06 21:00:15,golang/go,https://api.github.com/repos/golang/go,closed,testing: (*testing.Benchmark).Log always logs,Documentation,"With this benchmark: package main import ""testing"" func BenchmarkLog(b *testing.B) { b.Log(""why?"") } I get this output: $ go test -bench . testing: warning: no tests to run PASS BenchmarkLog 2000000000 0.00 ns/op --- BENCH: BenchmarkLog issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? The docs say, ""The text will be printed only if the test fails or the -test.v flag is set."" Why is b.Log logging anyway?",1.0,"testing: (*testing.Benchmark).Log always logs - With this benchmark: package main import ""testing"" func BenchmarkLog(b *testing.B) { b.Log(""why?"") } I get this output: $ go test -bench . testing: warning: no tests to run PASS BenchmarkLog 2000000000 0.00 ns/op --- BENCH: BenchmarkLog issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? issue_test.go:6: why? The docs say, ""The text will be printed only if the test fails or the -test.v flag is set."" Why is b.Log logging anyway?",1,testing testing benchmark log always logs with this benchmark package main import testing func benchmarklog b testing b b log why i get this output go test bench testing warning no tests to run pass benchmarklog ns op bench benchmarklog issue test go why issue test go why issue test go why issue test go why issue test go why issue test go why the docs say the text will be printed only if the test fails or the test v flag is set why is b log logging anyway ,1 442657,30849007705.0,IssuesEvent,2023-08-02 15:25:56,golang/go,https://api.github.com/repos/golang/go,closed,reflect: documentation of StructField.Offset is not clear about type embedding,Documentation help wanted NeedsInvestigation compiler/runtime,"When I read the document I think StructField.Offset means the offset of the field of caller struct, not the offset of embeded struct.But it is the offset of embeded struct. I think the document should be updated to clear it. ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.2 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/a/Library/Caches/go-build""
GOENV=""/Users/a/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/a/go/pkg/mod""
GOOS=""darwin""
GOPATH=""/Users/a/go""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.19.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mw/884f6hx53r56gd7zxsm1h8bm0000gp/T/go-build2286547601=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://go.dev/play/p/xae9pAtDcY7 ### What did you expect to see? 8 8 ### What did you see instead? 8 0 * ps current solution of the origin problem (get correct offset of a field of struct by name with reflect): ``` func mustGetOffsetFormStruct(rs reflect.Type,fieldName string) uintptr{ f,ok:=rs.FieldByName(fieldName) if ok==false{ panic(`fieldName not in struct`) } if len(f.Index)==1{ return f.Offset } offset:=uintptr(0) for _,index:=range f.Index{ rf:=rs.Field(index) offset+=rf.Offset rs = rf.Type } return offset } ```",1.0,"reflect: documentation of StructField.Offset is not clear about type embedding - When I read the document I think StructField.Offset means the offset of the field of caller struct, not the offset of embeded struct.But it is the offset of embeded struct. I think the document should be updated to clear it. ### What version of Go are you using (`go version`)? 
$ go version
go version go1.19.2 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/a/Library/Caches/go-build""
GOENV=""/Users/a/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/a/go/pkg/mod""
GOOS=""darwin""
GOPATH=""/Users/a/go""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.19.2""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
CGO_CFLAGS=""-g -O2""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-g -O2""
CGO_FFLAGS=""-g -O2""
CGO_LDFLAGS=""-g -O2""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mw/884f6hx53r56gd7zxsm1h8bm0000gp/T/go-build2286547601=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://go.dev/play/p/xae9pAtDcY7 ### What did you expect to see? 8 8 ### What did you see instead? 8 0 * ps current solution of the origin problem (get correct offset of a field of struct by name with reflect): ``` func mustGetOffsetFormStruct(rs reflect.Type,fieldName string) uintptr{ f,ok:=rs.FieldByName(fieldName) if ok==false{ panic(`fieldName not in struct`) } if len(f.Index)==1{ return f.Offset } offset:=uintptr(0) for _,index:=range f.Index{ rf:=rs.Field(index) offset+=rf.Offset rs = rf.Type } return offset } ```",1,reflect documentation of structfield offset is not clear about type embedding when i read the document i think structfield offset means the offset of the field of caller struct not the offset of embeded struct but it is the offset of embeded struct i think the document should be updated to clear it what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users a library caches go build goenv users a library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users a go pkg mod goos darwin gopath users a go goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders mw t go tmp go build gno record gcc switches fno common what did you do what did you expect to see what did you see instead ps current solution of the origin problem get correct offset of a field of struct by name with reflect func mustgetoffsetformstruct rs reflect type fieldname string uintptr f ok rs fieldbyname fieldname if ok false panic fieldname not in struct if len f index return f offset offset uintptr for index range f index rf rs field index offset rf offset rs rf type return offset ,1 264491,20022723485.0,IssuesEvent,2022-02-01 17:53:50,golang/go,https://api.github.com/repos/golang/go,closed,spec: document/explain which interfaces implement `comparable`,Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18beta1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/bobg/.cache/go-build""
GOENV=""/home/bobg/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/bobg/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/bobg/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/bobg/sdk/go1.18beta1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/bobg/sdk/go1.18beta1/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.18beta1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/bobg/go/src/github.com/bobg/modver/go.mod""
GOWORK=""""
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-build3923542930=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://go.dev/play/p/S-ijx-XOlu8?v=gotip ```go var ( anyType = types.Universe.Lookup(""any"").Type() comparableType = types.Universe.Lookup(""comparable"").Type() ) fmt.Println(types.AssignableTo(comparableType, anyType)) fmt.Println(types.AssignableTo(anyType, comparableType)) ``` ### What did you expect to see? true false That is, I (naively?) expected the same check that prevents me using non-comparable types as map keys to tell me that I cannot assign a value of an unconstrained type to a variable of a comparable type. ### What did you see instead? true true ",1.0,"spec: document/explain which interfaces implement `comparable` - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.18beta1 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""on""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/bobg/.cache/go-build""
GOENV=""/home/bobg/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/bobg/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/bobg/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/home/bobg/sdk/go1.18beta1""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/home/bobg/sdk/go1.18beta1/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.18beta1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/bobg/go/src/github.com/bobg/modver/go.mod""
GOWORK=""""
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-build3923542930=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://go.dev/play/p/S-ijx-XOlu8?v=gotip ```go var ( anyType = types.Universe.Lookup(""any"").Type() comparableType = types.Universe.Lookup(""comparable"").Type() ) fmt.Println(types.AssignableTo(comparableType, anyType)) fmt.Println(types.AssignableTo(anyType, comparableType)) ``` ### What did you expect to see? true false That is, I (naively?) expected the same check that prevents me using non-comparable types as map keys to tell me that I cannot assign a value of an unconstrained type to a variable of a comparable type. ### What did you see instead? true true ",1,spec document explain which interfaces implement comparable please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env on goarch gobin gocache home bobg cache go build goenv home bobg config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home bobg go pkg mod gonoproxy gonosumdb goos linux gopath home bobg go goprivate goproxy goroot home bobg sdk gosumdb sum golang org gotmpdir gotooldir home bobg sdk pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home bobg go src github com bobg modver go mod gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do go var anytype types universe lookup any type comparabletype types universe lookup comparable type fmt println types assignableto comparabletype anytype fmt println types assignableto anytype comparabletype what did you expect to see true false that is i naively expected the same check that prevents me using non comparable types as map keys to tell me that i cannot assign a value of an unconstrained type to a variable of a comparable type what did you see instead true true ,1 83275,10324545105.0,IssuesEvent,2019-09-01 10:09:37,golang/go,https://api.github.com/repos/golang/go,closed,testing: example output whitespace trimming can be confusing,Documentation NeedsFix help wanted,"Consider the [Example for filepath.Split](https://godoc.org/path#Split). The code is: ```go fmt.Println(path.Split(""static/myfile.css"")) fmt.Println(path.Split(""myfile.css"")) fmt.Println(path.Split("""")) ``` The output is: ``` static/ myfile.css myfile.css ``` Given that there are three `fmt.Println` calls, it seems to me that there really ought to be three lines of output. (And if we decide that we don't want to or can't change example output whitespace trimming, we should at least tweak this example so that the last line of output contains non-whitespace, e.g. by prefixing each output line with an asterisk or number.) ",1.0,"testing: example output whitespace trimming can be confusing - Consider the [Example for filepath.Split](https://godoc.org/path#Split). The code is: ```go fmt.Println(path.Split(""static/myfile.css"")) fmt.Println(path.Split(""myfile.css"")) fmt.Println(path.Split("""")) ``` The output is: ``` static/ myfile.css myfile.css ``` Given that there are three `fmt.Println` calls, it seems to me that there really ought to be three lines of output. (And if we decide that we don't want to or can't change example output whitespace trimming, we should at least tweak this example so that the last line of output contains non-whitespace, e.g. by prefixing each output line with an asterisk or number.) ",1,testing example output whitespace trimming can be confusing consider the the code is go fmt println path split static myfile css fmt println path split myfile css fmt println path split the output is static myfile css myfile css given that there are three fmt println calls it seems to me that there really ought to be three lines of output and if we decide that we don t want to or can t change example output whitespace trimming we should at least tweak this example so that the last line of output contains non whitespace e g by prefixing each output line with an asterisk or number ,1 26821,5290372201.0,IssuesEvent,2017-02-08 19:43:45,golang/go,https://api.github.com/repos/golang/go,closed,"doc: from contribute.html it is not clear what ""CL"" is",Documentation,"contribute.html uses the acronym ""CL"" without defining it first: > If your change relates to an open issue, please add a comment to the issue announcing your proposed fix, including a link to your CL. Not understood or misunderstood words can block one's understanding of the document or even cause one to abandon the subject. It would be better to introduce the acronym immediately after the first occurrence of ""change list"", e.g. > Unless explicitly told otherwise, such as in the discussion leading up to sending in the **change list (CL)**, it's better not to specify a reviewer",1.0,"doc: from contribute.html it is not clear what ""CL"" is - contribute.html uses the acronym ""CL"" without defining it first: > If your change relates to an open issue, please add a comment to the issue announcing your proposed fix, including a link to your CL. Not understood or misunderstood words can block one's understanding of the document or even cause one to abandon the subject. It would be better to introduce the acronym immediately after the first occurrence of ""change list"", e.g. > Unless explicitly told otherwise, such as in the discussion leading up to sending in the **change list (CL)**, it's better not to specify a reviewer",1,doc from contribute html it is not clear what cl is contribute html uses the acronym cl without defining it first if your change relates to an open issue please add a comment to the issue announcing your proposed fix including a link to your cl not understood or misunderstood words can block one s understanding of the document or even cause one to abandon the subject it would be better to introduce the acronym immediately after the first occurrence of change list e g unless explicitly told otherwise such as in the discussion leading up to sending in the change list cl it s better not to specify a reviewer,1 220921,17269670205.0,IssuesEvent,2021-07-22 18:00:27,golang/go,https://api.github.com/repos/golang/go,closed,"x/exp/vulndb/govulncheck: test fails when ""unzip"" is not in PATH",NeedsFix Testing release-blocker,"`golang.org/x/exp/vulndb/govulncheck` is persistently failing on the `longtest` builders since [CL 329809](https://golang.org/cl/329809): ``` --- FAIL: TestKubernetes (7.89s) main_test.go:300: failed to build k8s: main_test.go:301: exec: ""unzip"": executable file not found in $PATH FAIL FAIL golang.org/x/exp/vulndb/govulncheck 40.964s ``` It probably needs a `t.Skip` if `exec.LookPath(""unzip"")` fails. (Compare [`golang.org/x/tools/internal/testenv.NeedsTool`](https://beta.pkg.go.dev/golang.org/x/tools@v0.1.5/internal/testenv#NeedsTool).)",1.0,"x/exp/vulndb/govulncheck: test fails when ""unzip"" is not in PATH - `golang.org/x/exp/vulndb/govulncheck` is persistently failing on the `longtest` builders since [CL 329809](https://golang.org/cl/329809): ``` --- FAIL: TestKubernetes (7.89s) main_test.go:300: failed to build k8s: main_test.go:301: exec: ""unzip"": executable file not found in $PATH FAIL FAIL golang.org/x/exp/vulndb/govulncheck 40.964s ``` It probably needs a `t.Skip` if `exec.LookPath(""unzip"")` fails. (Compare [`golang.org/x/tools/internal/testenv.NeedsTool`](https://beta.pkg.go.dev/golang.org/x/tools@v0.1.5/internal/testenv#NeedsTool).)",0,x exp vulndb govulncheck test fails when unzip is not in path golang org x exp vulndb govulncheck is persistently failing on the longtest builders since fail testkubernetes main test go failed to build main test go exec unzip executable file not found in path fail fail golang org x exp vulndb govulncheck it probably needs a t skip if exec lookpath unzip fails compare ,0 264456,23119968720.0,IssuesEvent,2022-07-27 20:21:54,golang/go,https://api.github.com/repos/golang/go,closed,"runtime,misc/cgo/test: timeout in TestSetgidStress on linux/amd64",Testing NeedsInvestigation release-blocker compiler/runtime,"``` ##### ../misc/cgo/test ok misc/cgo/test 2.556s ok misc/cgo/test 2.474s SIGQUIT: quit PC=0x472ee1 m=0 sigcode=0 … goroutine 7 [runnable]: runtime.gopark(0xc00019a060?, 0xc000058ee8?, 0x9f?, 0x46?, 0x7f0df652b108?) /workdir/go/src/runtime/proc.go:363 +0xd6 fp=0xc000058e68 sp=0xc000058e48 pc=0x440a36 runtime.chanrecv(0xc0000ca000, 0x0, 0x1) /workdir/go/src/runtime/chan.go:583 +0x49b fp=0xc000058ef8 sp=0xc000058e68 pc=0x40de9b runtime.chanrecv1(0x6eb980?, 0x3e8?) /workdir/go/src/runtime/chan.go:442 +0x18 fp=0xc000058f20 sp=0xc000058ef8 pc=0x40d9d8 misc/cgo/test.testSetgidStress(0x4862d7?) /workdir/go/misc/cgo/test/setgid2_linux.go:33 +0x9c fp=0xc000058f58 sp=0xc000058f20 pc=0x56119c misc/cgo/test.TestSetgidStress(0x0?) /workdir/go/misc/cgo/test/cgo_linux_test.go:23 +0x19 fp=0xc000058f70 sp=0xc000058f58 pc=0x526519 testing.tRunner(0xc0000c8000, 0x5b9500) /workdir/go/src/testing/testing.go:1446 +0x10b fp=0xc000058fc0 sp=0xc000058f70 pc=0x4d6a4b testing.(*T).Run.func1() /workdir/go/src/testing/testing.go:1493 +0x2a fp=0xc000058fe0 sp=0xc000058fc0 pc=0x4d78ea runtime.goexit() /workdir/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000058fe8 sp=0xc000058fe0 pc=0x471001 created by testing.(*T).Run /workdir/go/src/testing/testing.go:1493 +0x35f … *** Test killed with quit: ran too long (11m0s). FAIL misc/cgo/test 660.128s ``` `greplogs -l -e 'goroutine \d+ .*:\n(?:.+\n\t.+\n)*misc/cgo/test\.TestSetgidStress'` [2022-06-30T21:57:02-aad9382/linux-amd64-sid](https://build.golang.org/log/9bfeb0f4a0062c8923eb41686f730082dfa6f6cc)",1.0,"runtime,misc/cgo/test: timeout in TestSetgidStress on linux/amd64 - ``` ##### ../misc/cgo/test ok misc/cgo/test 2.556s ok misc/cgo/test 2.474s SIGQUIT: quit PC=0x472ee1 m=0 sigcode=0 … goroutine 7 [runnable]: runtime.gopark(0xc00019a060?, 0xc000058ee8?, 0x9f?, 0x46?, 0x7f0df652b108?) /workdir/go/src/runtime/proc.go:363 +0xd6 fp=0xc000058e68 sp=0xc000058e48 pc=0x440a36 runtime.chanrecv(0xc0000ca000, 0x0, 0x1) /workdir/go/src/runtime/chan.go:583 +0x49b fp=0xc000058ef8 sp=0xc000058e68 pc=0x40de9b runtime.chanrecv1(0x6eb980?, 0x3e8?) /workdir/go/src/runtime/chan.go:442 +0x18 fp=0xc000058f20 sp=0xc000058ef8 pc=0x40d9d8 misc/cgo/test.testSetgidStress(0x4862d7?) /workdir/go/misc/cgo/test/setgid2_linux.go:33 +0x9c fp=0xc000058f58 sp=0xc000058f20 pc=0x56119c misc/cgo/test.TestSetgidStress(0x0?) /workdir/go/misc/cgo/test/cgo_linux_test.go:23 +0x19 fp=0xc000058f70 sp=0xc000058f58 pc=0x526519 testing.tRunner(0xc0000c8000, 0x5b9500) /workdir/go/src/testing/testing.go:1446 +0x10b fp=0xc000058fc0 sp=0xc000058f70 pc=0x4d6a4b testing.(*T).Run.func1() /workdir/go/src/testing/testing.go:1493 +0x2a fp=0xc000058fe0 sp=0xc000058fc0 pc=0x4d78ea runtime.goexit() /workdir/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc000058fe8 sp=0xc000058fe0 pc=0x471001 created by testing.(*T).Run /workdir/go/src/testing/testing.go:1493 +0x35f … *** Test killed with quit: ran too long (11m0s). FAIL misc/cgo/test 660.128s ``` `greplogs -l -e 'goroutine \d+ .*:\n(?:.+\n\t.+\n)*misc/cgo/test\.TestSetgidStress'` [2022-06-30T21:57:02-aad9382/linux-amd64-sid](https://build.golang.org/log/9bfeb0f4a0062c8923eb41686f730082dfa6f6cc)",0,runtime misc cgo test timeout in testsetgidstress on linux misc cgo test ok misc cgo test ok misc cgo test sigquit quit pc m sigcode … goroutine runtime gopark workdir go src runtime proc go fp sp pc runtime chanrecv workdir go src runtime chan go fp sp pc runtime workdir go src runtime chan go fp sp pc misc cgo test testsetgidstress workdir go misc cgo test linux go fp sp pc misc cgo test testsetgidstress workdir go misc cgo test cgo linux test go fp sp pc testing trunner workdir go src testing testing go fp sp pc testing t run workdir go src testing testing go fp sp pc runtime goexit workdir go src runtime asm s fp sp pc created by testing t run workdir go src testing testing go … test killed with quit ran too long fail misc cgo test greplogs l e goroutine d n n t n misc cgo test testsetgidstress ,0 38421,6670599130.0,IssuesEvent,2017-10-04 00:46:56,golang/go,https://api.github.com/repos/golang/go,closed,"plugin: ambiguous/undocumented ldflags=""-pluginpath ... -X ...""",Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.8 linux/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/fsenart/projects"" GORACE="""" GOROOT=""/home/fsenart/tools/go1.8"" GOTOOLDIR=""/home/fsenart/tools/go1.8/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build076969156=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? `$GOPATH/src/issue_ldflags/host.go` ```go // +build host package main import ""plugin"" var hostDummy string = ""EMPTY"" func main() { p, err := plugin.Open(""guest.so"") if err != nil { panic(err) } f, err := p.Lookup(""F"") if err != nil { panic(err) } println(hostDummy) f.(func())() } ``` `$GOPATH/src/issue_ldflags/guest.go` ```go // +build guest package main var guestDummy string = ""EMPTY"" func F() { println(guestDummy) } ``` `$GOPATH/src/issue_ldflags/Makefile` ```Makefile scenario_1: # INSIDE GOPATH & compile WITHOUT specifying source file @echo Host @echo === @go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host @nm host | grep hostDummy @echo Guest @echo ===== @go build -tags guest -buildmode=plugin -ldflags='-X $(shell basename $(CURDIR)).guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_2: # INSIDE GOPATH & compile WITH specifying source file @echo Host @echo === @go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host host.go @nm host | grep hostDummy @echo Guest @echo ===== # If not seeing 2 lines, change the Makefile with the seen id. # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2410 @go build -tags guest -buildmode=plugin -ldflags='-X plugin/unnamed-1edb35ed362d12b8c6c92ff2cc31ad97e4131d95.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_3: # OUTSIDE GOPATH & compile WITHOUT specifying source file @echo Host @echo === @GOPATH=/nowhere go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host @nm host | grep hostDummy @echo Guest @echo ===== @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-X _$(CURDIR).guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_4: # OUTSIDE GOPATH & compile WITH specifying source file @echo Host @echo === @GOPATH=/nowhere go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host host.go @nm host | grep hostDummy @echo Guest @echo ===== # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2410 # If not seeing 2 lines, change the Makefile with the seen id. @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-X plugin/unnamed-1edb35ed362d12b8c6c92ff2cc31ad97e4131d95.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? I expect to be able to use `-ldflags=""-X importpath.guestDummy""` to set a build time variable when compiling with `-buildmode=plugin` ; as I can do when compiling regular binaries with `-ldflags=""-X main.hostDummy""` ### What did you see instead? In the context of plugins `importpath` is variable and depends on the building context. I found that I can have a fixed behavior when using `-pluginpath` ldflags. But this flag is not well documented: ``` -pluginpath string full path name for plugin ``` Can I use it confidently is this context? is this the good pattern to set a build time variable in plugins? ",1.0,"plugin: ambiguous/undocumented ldflags=""-pluginpath ... -X ..."" - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? ``` go version go1.8 linux/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/fsenart/projects"" GORACE="""" GOROOT=""/home/fsenart/tools/go1.8"" GOTOOLDIR=""/home/fsenart/tools/go1.8/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build076969156=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? `$GOPATH/src/issue_ldflags/host.go` ```go // +build host package main import ""plugin"" var hostDummy string = ""EMPTY"" func main() { p, err := plugin.Open(""guest.so"") if err != nil { panic(err) } f, err := p.Lookup(""F"") if err != nil { panic(err) } println(hostDummy) f.(func())() } ``` `$GOPATH/src/issue_ldflags/guest.go` ```go // +build guest package main var guestDummy string = ""EMPTY"" func F() { println(guestDummy) } ``` `$GOPATH/src/issue_ldflags/Makefile` ```Makefile scenario_1: # INSIDE GOPATH & compile WITHOUT specifying source file @echo Host @echo === @go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host @nm host | grep hostDummy @echo Guest @echo ===== @go build -tags guest -buildmode=plugin -ldflags='-X $(shell basename $(CURDIR)).guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_2: # INSIDE GOPATH & compile WITH specifying source file @echo Host @echo === @go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host host.go @nm host | grep hostDummy @echo Guest @echo ===== # If not seeing 2 lines, change the Makefile with the seen id. # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2410 @go build -tags guest -buildmode=plugin -ldflags='-X plugin/unnamed-1edb35ed362d12b8c6c92ff2cc31ad97e4131d95.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_3: # OUTSIDE GOPATH & compile WITHOUT specifying source file @echo Host @echo === @GOPATH=/nowhere go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host @nm host | grep hostDummy @echo Guest @echo ===== @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-X _$(CURDIR).guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so @nm guest.so | grep guestDummy @echo Run @echo === @./host scenario_4: # OUTSIDE GOPATH & compile WITH specifying source file @echo Host @echo === @GOPATH=/nowhere go build -tags host -ldflags='-X main.hostDummy=dummyHost' -o host host.go @nm host | grep hostDummy @echo Guest @echo ===== # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2410 # If not seeing 2 lines, change the Makefile with the seen id. @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-X plugin/unnamed-1edb35ed362d12b8c6c92ff2cc31ad97e4131d95.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host @echo === # WITH custom plugin path # https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L2412 @GOPATH=/nowhere go build -tags guest -buildmode=plugin -ldflags='-pluginpath=custompluginpath -X custompluginpath.guestDummy=dummyGuest' -o guest.so guest.go @nm guest.so | grep guestDummy @echo Run @echo === @./host ``` If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. ### What did you expect to see? I expect to be able to use `-ldflags=""-X importpath.guestDummy""` to set a build time variable when compiling with `-buildmode=plugin` ; as I can do when compiling regular binaries with `-ldflags=""-X main.hostDummy""` ### What did you see instead? In the context of plugins `importpath` is variable and depends on the building context. I found that I can have a fixed behavior when using `-pluginpath` ldflags. But this flag is not well documented: ``` -pluginpath string full path name for plugin ``` Can I use it confidently is this context? is this the good pattern to set a build time variable in plugins? ",1,plugin ambiguous undocumented ldflags pluginpath x please answer these questions before submitting your issue thanks what version of go are you using go version go version linux what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath home fsenart projects gorace goroot home fsenart tools gotooldir home fsenart tools pkg tool linux gccgo gccgo cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do gopath src issue ldflags host go go build host package main import plugin var hostdummy string empty func main p err plugin open guest so if err nil panic err f err p lookup f if err nil panic err println hostdummy f func gopath src issue ldflags guest go go build guest package main var guestdummy string empty func f println guestdummy gopath src issue ldflags makefile makefile scenario inside gopath compile without specifying source file echo host echo go build tags host ldflags x main hostdummy dummyhost o host nm host grep hostdummy echo guest echo go build tags guest buildmode plugin ldflags x shell basename curdir guestdummy dummyguest o guest so nm guest so grep guestdummy echo run echo host echo with custom plugin path go build tags guest buildmode plugin ldflags pluginpath custompluginpath x custompluginpath guestdummy dummyguest o guest so nm guest so grep guestdummy echo run echo host scenario inside gopath compile with specifying source file echo host echo go build tags host ldflags x main hostdummy dummyhost o host host go nm host grep hostdummy echo guest echo if not seeing lines change the makefile with the seen id go build tags guest buildmode plugin ldflags x plugin unnamed guestdummy dummyguest o guest so guest go nm guest so grep guestdummy echo run echo host echo with custom plugin path go build tags guest buildmode plugin ldflags pluginpath custompluginpath x custompluginpath guestdummy dummyguest o guest so guest go nm guest so grep guestdummy echo run echo host scenario outside gopath compile without specifying source file echo host echo gopath nowhere go build tags host ldflags x main hostdummy dummyhost o host nm host grep hostdummy echo guest echo gopath nowhere go build tags guest buildmode plugin ldflags x curdir guestdummy dummyguest o guest so nm guest so grep guestdummy echo run echo host echo with custom plugin path gopath nowhere go build tags guest buildmode plugin ldflags pluginpath custompluginpath x custompluginpath guestdummy dummyguest o guest so nm guest so grep guestdummy echo run echo host scenario outside gopath compile with specifying source file echo host echo gopath nowhere go build tags host ldflags x main hostdummy dummyhost o host host go nm host grep hostdummy echo guest echo if not seeing lines change the makefile with the seen id gopath nowhere go build tags guest buildmode plugin ldflags x plugin unnamed guestdummy dummyguest o guest so guest go nm guest so grep guestdummy echo run echo host echo with custom plugin path gopath nowhere go build tags guest buildmode plugin ldflags pluginpath custompluginpath x custompluginpath guestdummy dummyguest o guest so guest go nm guest so grep guestdummy echo run echo host if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see i expect to be able to use ldflags x importpath guestdummy to set a build time variable when compiling with buildmode plugin as i can do when compiling regular binaries with ldflags x main hostdummy what did you see instead in the context of plugins importpath is variable and depends on the building context i found that i can have a fixed behavior when using pluginpath ldflags but this flag is not well documented pluginpath string full path name for plugin can i use it confidently is this context is this the good pattern to set a build time variable in plugins ,1 44547,7113023345.0,IssuesEvent,2018-01-17 19:00:26,golang/go,https://api.github.com/repos/golang/go,closed,proposal: spec: the integer division exception rule should be moved to the integer overflow section,Documentation,"In Go spec: ``` As an exception to this rule, if the dividend x is the most negative value for the int type of x, the quotient q = x / -1 is equal to x (and r = 0). x, q int8 -128 int16 -32768 int32 -2147483648 int64 -9223372036854775808 ``` The above content is in the ""Integer operators"" section, but I think it should be moved to the ""Integer overflow"" section. And it is not an exception. It is just a normal overflow, the ""wrap around"" behavior is the same as other overflows. I think it can just be shown as one line example to show how ""wrap around"" works. The benefit of the proposal is to make people know `int8( -128)/int(-1)` is exactly an overflow. ",1.0,"proposal: spec: the integer division exception rule should be moved to the integer overflow section - In Go spec: ``` As an exception to this rule, if the dividend x is the most negative value for the int type of x, the quotient q = x / -1 is equal to x (and r = 0). x, q int8 -128 int16 -32768 int32 -2147483648 int64 -9223372036854775808 ``` The above content is in the ""Integer operators"" section, but I think it should be moved to the ""Integer overflow"" section. And it is not an exception. It is just a normal overflow, the ""wrap around"" behavior is the same as other overflows. I think it can just be shown as one line example to show how ""wrap around"" works. The benefit of the proposal is to make people know `int8( -128)/int(-1)` is exactly an overflow. ",1,proposal spec the integer division exception rule should be moved to the integer overflow section in go spec as an exception to this rule if the dividend x is the most negative value for the int type of x the quotient q x is equal to x and r x q the above content is in the integer operators section but i think it should be moved to the integer overflow section and it is not an exception it is just a normal overflow the wrap around behavior is the same as other overflows i think it can just be shown as one line example to show how wrap around works the benefit of the proposal is to make people know int is exactly an overflow ,1 210898,16389357800.0,IssuesEvent,2021-05-17 14:22:02,golang/go,https://api.github.com/repos/golang/go,closed,embed: Files starting with : (double dots) are not embedded (undocumented behavior),Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.4 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/baryshnikov/.cache/go-build""
GOENV=""/home/baryshnikov/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/baryshnikov/Develop/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/baryshnikov/Develop/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/latest""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/latest/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.4""
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-build1338096382=/tmp/go-build -gno-record-gcc-switches""
### What did you do? [demo-fs.tar.gz](https://github.com/golang/go/files/6493199/demo-fs.tar.gz)
Source code (see attachment) 
package main

import (
	""embed""
	""fmt""
	""os""
)

//go:embed assets
var assets embed.FS

func main() {
	files := []string{
		""assets/root.txt"",
		""assets/:normal"",
		""assets/:alsonormal/file2.txt"",
	}

	// check in real file system
	for _, file := range files {
		_, err := os.Open(file)
		if err != nil {
			fmt.Println(""[FAILED ] failed open"", file, ""in real file system:"", err)
		} else {
			fmt.Println(""[SUCCESS] open"", file, ""in real file system"")
		}
	}

	// check in embedded
	for _, file := range files {
		_, err := assets.Open(file)
		if err != nil {
			fmt.Println(""[FAILED ] failed open"", file, ""in embedded file system"", "":"", err)
		} else {
			fmt.Println(""[SUCCESS] open"", file, ""in embedded file system"")
		}
	}
}
### What did you expect to see? Embedded files with `:` in names were included. (from demo) ``` [SUCCESS] open assets/root.txt in real file system [SUCCESS] open assets/:normal in real file system [SUCCESS] open assets/:alsonormal/file2.txt in real file system [SUCCESS] open assets/root.txt in embedded file system [SUCCESS] open assets/:normal in embedded file system [SUCCESS] open assets/:alsonormal/file2.txt in embedded file system ``` ### What did you see instead? Embedded files with `:` in names were not included. (from demo) ``` [SUCCESS] open assets/root.txt in real file system [SUCCESS] open assets/:normal in real file system [SUCCESS] open assets/:alsonormal/file2.txt in real file system [SUCCESS] open assets/root.txt in embedded file system [FAILED ] failed open assets/:normal in embedded file system : open assets/:normal: file does not exist [FAILED ] failed open assets/:alsonormal/file2.txt in embedded file system : open assets/:alsonormal/file2.txt: file does not exist ``` ### Analysis Likely related to https://github.com/golang/go/issues/45447. Embedded files names restriction should be relaxed and/or documented. ",1.0,"embed: Files starting with : (double dots) are not embedded (undocumented behavior) - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.4 linux/amd64
### Does this issue reproduce with the latest release? ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/baryshnikov/.cache/go-build""
GOENV=""/home/baryshnikov/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/baryshnikov/Develop/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/baryshnikov/Develop/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/opt/go/latest""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/opt/go/latest/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.16.4""
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-build1338096382=/tmp/go-build -gno-record-gcc-switches""
### What did you do? [demo-fs.tar.gz](https://github.com/golang/go/files/6493199/demo-fs.tar.gz)
Source code (see attachment) 
package main

import (
	""embed""
	""fmt""
	""os""
)

//go:embed assets
var assets embed.FS

func main() {
	files := []string{
		""assets/root.txt"",
		""assets/:normal"",
		""assets/:alsonormal/file2.txt"",
	}

	// check in real file system
	for _, file := range files {
		_, err := os.Open(file)
		if err != nil {
			fmt.Println(""[FAILED ] failed open"", file, ""in real file system:"", err)
		} else {
			fmt.Println(""[SUCCESS] open"", file, ""in real file system"")
		}
	}

	// check in embedded
	for _, file := range files {
		_, err := assets.Open(file)
		if err != nil {
			fmt.Println(""[FAILED ] failed open"", file, ""in embedded file system"", "":"", err)
		} else {
			fmt.Println(""[SUCCESS] open"", file, ""in embedded file system"")
		}
	}
}
### What did you expect to see? Embedded files with `:` in names were included. (from demo) ``` [SUCCESS] open assets/root.txt in real file system [SUCCESS] open assets/:normal in real file system [SUCCESS] open assets/:alsonormal/file2.txt in real file system [SUCCESS] open assets/root.txt in embedded file system [SUCCESS] open assets/:normal in embedded file system [SUCCESS] open assets/:alsonormal/file2.txt in embedded file system ``` ### What did you see instead? Embedded files with `:` in names were not included. (from demo) ``` [SUCCESS] open assets/root.txt in real file system [SUCCESS] open assets/:normal in real file system [SUCCESS] open assets/:alsonormal/file2.txt in real file system [SUCCESS] open assets/root.txt in embedded file system [FAILED ] failed open assets/:normal in embedded file system : open assets/:normal: file does not exist [FAILED ] failed open assets/:alsonormal/file2.txt in embedded file system : open assets/:alsonormal/file2.txt: file does not exist ``` ### Analysis Likely related to https://github.com/golang/go/issues/45447. Embedded files names restriction should be relaxed and/or documented. ",1,embed files starting with double dots are not embedded undocumented behavior please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home baryshnikov cache go build goenv home baryshnikov config go env goexe goflags gohostarch gohostos linux goinsecure gomodcache home baryshnikov develop go pkg mod gonoproxy gonosumdb goos linux gopath home baryshnikov develop go goprivate goproxy goroot opt go latest gosumdb sum golang org gotmpdir gotooldir opt go latest pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 source code see attachment package main import embed fmt os go embed assets var assets embed fs func main files string assets root txt assets normal assets alsonormal txt check in real file system for file range files err os open file if err nil fmt println failed open file in real file system err else fmt println open file in real file system check in embedded for file range files err assets open file if err nil fmt println failed open file in embedded file system err else fmt println open file in embedded file system what did you expect to see embedded files with in names were included from demo open assets root txt in real file system open assets normal in real file system open assets alsonormal txt in real file system open assets root txt in embedded file system open assets normal in embedded file system open assets alsonormal txt in embedded file system what did you see instead embedded files with in names were not included from demo open assets root txt in real file system open assets normal in real file system open assets alsonormal txt in real file system open assets root txt in embedded file system failed open assets normal in embedded file system open assets normal file does not exist failed open assets alsonormal txt in embedded file system open assets alsonormal txt file does not exist analysis likely related to embedded files names restriction should be relaxed and or documented ,1 23409,4934276302.0,IssuesEvent,2016-11-28 18:37:24,golang/go,https://api.github.com/repos/golang/go,closed,net/mail: not clear that Header.Get is case insensitive,Documentation NeedsFix,"Reading the godoc: ``` func (h Header) Get(key string) string Get gets the first value associated with the given key. If there are no values associated with the key, Get returns """". ``` It's not immediately obvious that `key` is not case sensitive. As it turns out, `Get(""From"")` and `Get(""from"")` mean the same because internally this all goes through https://golang.org/pkg/net/textproto/#CanonicalMIMEHeaderKey. Perhaps this is just me not being used to MIME Headers being canonical in this way. But I think a sentence like ""note that key is case insensitive as it is canonicalized"" would help some people. The `net/mail` godoc does not mention MIME headers anywhere either. Perhaps this should go in `net/textproto` too, even though that's much closer to the actual `CanonicalMIMEHeaderKey` func.",1.0,"net/mail: not clear that Header.Get is case insensitive - Reading the godoc: ``` func (h Header) Get(key string) string Get gets the first value associated with the given key. If there are no values associated with the key, Get returns """". ``` It's not immediately obvious that `key` is not case sensitive. As it turns out, `Get(""From"")` and `Get(""from"")` mean the same because internally this all goes through https://golang.org/pkg/net/textproto/#CanonicalMIMEHeaderKey. Perhaps this is just me not being used to MIME Headers being canonical in this way. But I think a sentence like ""note that key is case insensitive as it is canonicalized"" would help some people. The `net/mail` godoc does not mention MIME headers anywhere either. Perhaps this should go in `net/textproto` too, even though that's much closer to the actual `CanonicalMIMEHeaderKey` func.",1,net mail not clear that header get is case insensitive reading the godoc func h header get key string string get gets the first value associated with the given key if there are no values associated with the key get returns it s not immediately obvious that key is not case sensitive as it turns out get from and get from mean the same because internally this all goes through perhaps this is just me not being used to mime headers being canonical in this way but i think a sentence like note that key is case insensitive as it is canonicalized would help some people the net mail godoc does not mention mime headers anywhere either perhaps this should go in net textproto too even though that s much closer to the actual canonicalmimeheaderkey func ,1 54334,7883360324.0,IssuesEvent,2018-06-27 04:31:01,golang/go,https://api.github.com/repos/golang/go,closed,cmd/link: failed to set variable at build time if variable value is result from method call,Documentation NeedsFix help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.3 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/cuonglm/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/cuonglm/go"" GORACE="""" GOROOT=""/home/cuonglm/sources/go"" GOTMPDIR="""" GOTOOLDIR=""/home/cuonglm/sources/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build755255777=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? https://play.golang.org/p/M9xGmognyrl run as: ``` go run -ldflags ""-X main.X=y -X main.MyX=myY"" main.go ``` ### What did you expect to see? ``` y myY ``` ### What did you see instead? ``` y myX ``` ",1.0,"cmd/link: failed to set variable at build time if variable value is result from method call - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.10.3 linux/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/cuonglm/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/cuonglm/go"" GORACE="""" GOROOT=""/home/cuonglm/sources/go"" GOTMPDIR="""" GOTOOLDIR=""/home/cuonglm/sources/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build755255777=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? https://play.golang.org/p/M9xGmognyrl run as: ``` go run -ldflags ""-X main.X=y -X main.MyX=myY"" main.go ``` ### What did you expect to see? ``` y myY ``` ### What did you see instead? ``` y myX ``` ",1,cmd link failed to set variable at build time if variable value is result from method call please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache home cuonglm cache go build goexe gohostarch gohostos linux goos linux gopath home cuonglm go gorace goroot home cuonglm sources go gotmpdir gotooldir home cuonglm sources go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do run as go run ldflags x main x y x main myx myy main go what did you expect to see y myy what did you see instead y myx ,1 178025,13758118213.0,IssuesEvent,2020-10-06 23:09:55,golang/go,https://api.github.com/repos/golang/go,closed,cmd/addr2line: TestAddr2Line fails with double / in $GOROOT_FINAL [1.15 backport],CherryPickApproved Testing,"@bcmills requested issue #41447 to be considered for backport to the next 1.15 minor release. > @gopherbot, please backport to 1.15. See rationale in https://github.com/golang/go/issues/41447#issuecomment-694278216. ",1.0,"cmd/addr2line: TestAddr2Line fails with double / in $GOROOT_FINAL [1.15 backport] - @bcmills requested issue #41447 to be considered for backport to the next 1.15 minor release. > @gopherbot, please backport to 1.15. See rationale in https://github.com/golang/go/issues/41447#issuecomment-694278216. ",0,cmd fails with double in goroot final bcmills requested issue to be considered for backport to the next minor release gopherbot please backport to see rationale in ,0 82426,10281365154.0,IssuesEvent,2019-08-26 08:19:52,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Documents misaligned in menu for release notes,Documentation,"The **Documents** menu option is misaligned in the Go release notes. The alignment is correct on other documentation pages. ### What did you do? Go to the release notes for Go, for example [go1.11](https://golang.org/doc/go1.11), [go1.12](https://golang.org/doc/go1.12) or [go1.13 (tip)](https://tip.golang.org/doc/go1.13) ### What did you expect to see? **Documents** aligned with the other menu options. ### What did you see instead? **Documents** being positioned higher up than the rest of the menu options. ### Browsers tested The following browsers were tested under macOS High Sierra. - Firefox Developer Edition - Safari - Google Chrome",1.0,"x/website: Documents misaligned in menu for release notes - The **Documents** menu option is misaligned in the Go release notes. The alignment is correct on other documentation pages. ### What did you do? Go to the release notes for Go, for example [go1.11](https://golang.org/doc/go1.11), [go1.12](https://golang.org/doc/go1.12) or [go1.13 (tip)](https://tip.golang.org/doc/go1.13) ### What did you expect to see? **Documents** aligned with the other menu options. ### What did you see instead? **Documents** being positioned higher up than the rest of the menu options. ### Browsers tested The following browsers were tested under macOS High Sierra. - Firefox Developer Edition - Safari - Google Chrome",1,x website documents misaligned in menu for release notes the documents menu option is misaligned in the go release notes img width alt go release notes src the alignment is correct on other documentation pages img width alt go documentation src what did you do go to the release notes for go for example or what did you expect to see documents aligned with the other menu options what did you see instead documents being positioned higher up than the rest of the menu options browsers tested the following browsers were tested under macos high sierra firefox developer edition safari google chrome,1 22098,4772987249.0,IssuesEvent,2016-10-26 22:35:37,golang/go,https://api.github.com/repos/golang/go,closed,context: WithCancel example is not explaining cancel func,Documentation NeedsFix,"As a user, I'd expect WithCancel example at https://tip.golang.org/pkg/context/#example_WithCancel to explain specific cancellation of the context by calling the cancel func. The example doesn't even require a cancellable context, see https://play.golang.org/p/4hMwLTCVaU. Is this example trying to achieve something similar to what's below? ``` package main import ( ""context"" ""fmt"" ""time"" ) func main() { count := func(ctx context.Context, dst chan<- int) { n := 1 for { select { case dst <- n: n++ case <-ctx.Done(): fmt.Println(""not leaking"") return } } } ctx, cancel := context.WithCancel(context.Background()) defer cancel() ints := make(chan int) go count(ctx, ints) for n := range ints { fmt.Println(n) if n == 5 { cancel() break } } time.Sleep(time.Minute) } ``` /cc @bradfitz ",1.0,"context: WithCancel example is not explaining cancel func - As a user, I'd expect WithCancel example at https://tip.golang.org/pkg/context/#example_WithCancel to explain specific cancellation of the context by calling the cancel func. The example doesn't even require a cancellable context, see https://play.golang.org/p/4hMwLTCVaU. Is this example trying to achieve something similar to what's below? ``` package main import ( ""context"" ""fmt"" ""time"" ) func main() { count := func(ctx context.Context, dst chan<- int) { n := 1 for { select { case dst <- n: n++ case <-ctx.Done(): fmt.Println(""not leaking"") return } } } ctx, cancel := context.WithCancel(context.Background()) defer cancel() ints := make(chan int) go count(ctx, ints) for n := range ints { fmt.Println(n) if n == 5 { cancel() break } } time.Sleep(time.Minute) } ``` /cc @bradfitz ",1,context withcancel example is not explaining cancel func as a user i d expect withcancel example at to explain specific cancellation of the context by calling the cancel func the example doesn t even require a cancellable context see is this example trying to achieve something similar to what s below package main import context fmt time func main count func ctx context context dst chan int n for select case dst n n case ctx done fmt println not leaking return ctx cancel context withcancel context background defer cancel ints make chan int go count ctx ints for n range ints fmt println n if n cancel break time sleep time minute cc bradfitz ,1 320551,23814298091.0,IssuesEvent,2022-09-05 04:06:45,golang/go,https://api.github.com/repos/golang/go,closed,Document link always quoted 500,Documentation," In [https://go-zh.org/doc/](https://go-zh.org/doc/) when i click `Go 语言之旅` it always report 500 ",1.0,"Document link always quoted 500 - In [https://go-zh.org/doc/](https://go-zh.org/doc/) when i click `Go 语言之旅` it always report 500 ",1,document link always quoted in when i click go 语言之旅 it always report img width alt image src ,1 5935,2989758065.0,IssuesEvent,2015-07-21 02:45:56,golang/go,https://api.github.com/repos/golang/go,closed,doc: effective_go.html GOMAXPROCS=1 does not hold anymore with Go1.5,Documentation,"[0] https://github.com/golang/go/blob/master/doc/effective_go.html#L3192-L3206 states that ""The current implementation of the Go runtime will not parallelize this code by default."" as of Go 1.5 the implementation for that changed: https://github.com/golang/go/blob/master/doc/go1.5.html#L36-L37 and ""by default, Go programs run with GOMAXPROCS set to the number of cores available"". the section [0] should reflect that new implementation detail with perhaps something like: The implementation of the Go runtime parallelize this code by default. Go programs run with GOMAXPROCS set to the number of cores available but you can change this implementation default to your needs. There are two related ways to do this. Either run your job with environment variable GOMAXPROCS set to the number of cores to use or import the runtime package and call runtime.GOMAXPROCS(NCPU).",1.0,"doc: effective_go.html GOMAXPROCS=1 does not hold anymore with Go1.5 - [0] https://github.com/golang/go/blob/master/doc/effective_go.html#L3192-L3206 states that ""The current implementation of the Go runtime will not parallelize this code by default."" as of Go 1.5 the implementation for that changed: https://github.com/golang/go/blob/master/doc/go1.5.html#L36-L37 and ""by default, Go programs run with GOMAXPROCS set to the number of cores available"". the section [0] should reflect that new implementation detail with perhaps something like: The implementation of the Go runtime parallelize this code by default. Go programs run with GOMAXPROCS set to the number of cores available but you can change this implementation default to your needs. There are two related ways to do this. Either run your job with environment variable GOMAXPROCS set to the number of cores to use or import the runtime package and call runtime.GOMAXPROCS(NCPU).",1,doc effective go html gomaxprocs does not hold anymore with states that the current implementation of the go runtime will not parallelize this code by default as of go the implementation for that changed and by default go programs run with gomaxprocs set to the number of cores available the section should reflect that new implementation detail with perhaps something like the implementation of the go runtime parallelize this code by default go programs run with gomaxprocs set to the number of cores available but you can change this implementation default to your needs there are two related ways to do this either run your job with environment variable gomaxprocs set to the number of cores to use or import the runtime package and call runtime gomaxprocs ncpu ,1 31621,8719340800.0,IssuesEvent,2018-12-08 00:11:36,golang/go,https://api.github.com/repos/golang/go,closed,x/build: windows/arm builder got misconfigured,Builders,"windows/arm builder looks misconfigured. From https://build.golang.org/log/4d354f5970ff4e883ec131851af59fcdf1556dbb ``` ERROR: Cannot find C:\Data\Go\bin\go.exe Set GOROOT_BOOTSTRAP to a working Go tree >= Go 1.4. build failed: make script failed: exit status 1 ``` @jordanrh1, please investigate. Thank you. Alex",1.0,"x/build: windows/arm builder got misconfigured - windows/arm builder looks misconfigured. From https://build.golang.org/log/4d354f5970ff4e883ec131851af59fcdf1556dbb ``` ERROR: Cannot find C:\Data\Go\bin\go.exe Set GOROOT_BOOTSTRAP to a working Go tree >= Go 1.4. build failed: make script failed: exit status 1 ``` @jordanrh1, please investigate. Thank you. Alex",0,x build windows arm builder got misconfigured windows arm builder looks misconfigured from error cannot find c data go bin go exe set goroot bootstrap to a working go tree go build failed make script failed exit status please investigate thank you alex,0 28478,8150275673.0,IssuesEvent,2018-08-22 12:29:43,golang/go,https://api.github.com/repos/golang/go,closed,builders: linux-s390x-ibm has no space left on device,Builders,"Recent builds have been failing on linux-s390x-ibm with messages like ``` /var/buildlet/go-linux-s390x-bootstrap/pkg/tool/linux_s390x/link: flushing $WORK/_/data/golang/workdir/go/src/cmd/dist/_obj/exe/a.out: write $WORK/_/data/golang/workdir/go/src/cmd/dist/_obj/exe/a.out: no space left on device ``` https://build.golang.org/log/70d02de37115ec58a773a000bdb7d3ad5aa0ee11 /cc @mundaym ",1.0,"builders: linux-s390x-ibm has no space left on device - Recent builds have been failing on linux-s390x-ibm with messages like ``` /var/buildlet/go-linux-s390x-bootstrap/pkg/tool/linux_s390x/link: flushing $WORK/_/data/golang/workdir/go/src/cmd/dist/_obj/exe/a.out: write $WORK/_/data/golang/workdir/go/src/cmd/dist/_obj/exe/a.out: no space left on device ``` https://build.golang.org/log/70d02de37115ec58a773a000bdb7d3ad5aa0ee11 /cc @mundaym ",0,builders linux ibm has no space left on device recent builds have been failing on linux ibm with messages like var buildlet go linux bootstrap pkg tool linux link flushing work data golang workdir go src cmd dist obj exe a out write work data golang workdir go src cmd dist obj exe a out no space left on device cc mundaym ,0 33215,6180328708.0,IssuesEvent,2017-07-03 05:06:13,golang/go,https://api.github.com/repos/golang/go,opened,Effective_GO documentation mistake,Documentation," [https://golang.org/doc/effective_go.html#functions](url) on this code ``` func nextInt(b []byte, i int) (int, int) { for ; i < len(b) && !isDigit(b[i]); i++ { } x := 0 for ; i < len(b) && isDigit(b[i]); i++ { x = x*10 + int(b[i]) - '0' } return x, i } ``` I think ``` for ; i < len(b) && !isDigit(b[i]); i++ { } ``` is a duplication mistake",1.0,"Effective_GO documentation mistake - [https://golang.org/doc/effective_go.html#functions](url) on this code ``` func nextInt(b []byte, i int) (int, int) { for ; i < len(b) && !isDigit(b[i]); i++ { } x := 0 for ; i < len(b) && isDigit(b[i]); i++ { x = x*10 + int(b[i]) - '0' } return x, i } ``` I think ``` for ; i < len(b) && !isDigit(b[i]); i++ { } ``` is a duplication mistake",1,effective go documentation mistake url on this code func nextint b byte i int int int for i len b isdigit b i x for i len b isdigit b i x x int b return x i i think for i len b isdigit b i is a duplication mistake,1 80625,10195250833.0,IssuesEvent,2019-08-12 17:39:48,golang/go,https://api.github.com/repos/golang/go,closed,encoding/json: Unmarshal map[string]interface{} target mishandled when passed as an interface{},Documentation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.6 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""xxx""
GOCACHE=""xxx""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""xxx""
GOPROXY=""""
GORACE=""""
GOROOT=""xxx""
GOTMPDIR=""""
GOTOOLDIR=""xxx""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build894533395=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Used a reference to the same map in multiple call to json.Unmarshal. See https://play.golang.org/p/bum-Q01e96M ### What did you expect to see? Expected JSON unmarshaling into maps to merge entries between different calls to json.Unmarshal, as indicated by the docs. The play example should output: 
map1: map[key1:data1 key2:data2]
map2: map[key1:data1 key2:data2]
map3: map[key1:map[key1.1:data1 key1.2:data2]]
### What did you see instead? Whenever the type of the unmarshal target is interface{} then a replacement value is created even if the existing entry is of type map[string]interface{} and is a suitable instance for unmarshal to use. The play example outputs: 
result: map[key2:data2]
result: map[key1:data1 key2:data2]
result: map[key1:map[key1.2:data2]]
",1.0,"encoding/json: Unmarshal map[string]interface{} target mishandled when passed as an interface{} - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.6 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""xxx""
GOCACHE=""xxx""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""xxx""
GOPROXY=""""
GORACE=""""
GOROOT=""xxx""
GOTMPDIR=""""
GOTOOLDIR=""xxx""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build894533395=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Used a reference to the same map in multiple call to json.Unmarshal. See https://play.golang.org/p/bum-Q01e96M ### What did you expect to see? Expected JSON unmarshaling into maps to merge entries between different calls to json.Unmarshal, as indicated by the docs. The play example should output: 
map1: map[key1:data1 key2:data2]
map2: map[key1:data1 key2:data2]
map3: map[key1:map[key1.1:data1 key1.2:data2]]
### What did you see instead? Whenever the type of the unmarshal target is interface{} then a replacement value is created even if the existing entry is of type map[string]interface{} and is a suitable instance for unmarshal to use. The play example outputs: 
result: map[key2:data2]
result: map[key1:data1 key2:data2]
result: map[key1:map[key1.2:data2]]
",1,encoding json unmarshal map interface target mishandled when passed as an interface what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin xxx gocache xxx goexe goflags gohostarch gohostos linux goos linux gopath xxx goproxy gorace goroot xxx gotmpdir gotooldir xxx gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do used a reference to the same map in multiple call to json unmarshal see what did you expect to see expected json unmarshaling into maps to merge entries between different calls to json unmarshal as indicated by the docs the play example should output map map map what did you see instead whenever the type of the unmarshal target is interface then a replacement value is created even if the existing entry is of type map interface and is a suitable instance for unmarshal to use the play example outputs result map result map result map ,1 173137,14403476434.0,IssuesEvent,2020-12-03 16:06:12,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document os/signal changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
os/signal

TODO: https://golang.org/cl/219640: add NotifyContext to cancel context using system signals

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document os/signal changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
os/signal

TODO: https://golang.org/cl/219640: add NotifyContext to cancel context using system signals

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document os signal changes for go as of filing this issue the contained the following html os signal todo a href add notifycontext to cancel context using system signals per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 43508,7048557683.0,IssuesEvent,2018-01-02 18:11:33,golang/go,https://api.github.com/repos/golang/go,closed,"math: wrong result for Pow(±0, .5) contrary to documentation",Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9.2 linux/amd64 ### Does this issue reproduce with the latest release? I believe go1.9.2 is the latest release. ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr/local/google/home/majnemer/go"" GORACE="""" GOROOT=""/usr/lib/google-golang"" GOTOOLDIR=""/usr/lib/google-golang/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build846653371=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? I ran the following program: https://play.golang.org/p/_lUAaRG9D-P ### What did you expect to see? The [documentation for math.Pow](https://golang.org/pkg/math/#Pow) says the following: > Pow(±0, y) = +0 for finite y > 0 and not an odd integer .5 is finite and not an odd integer which means math.Pow should give back +0. ### What did you see instead? math.Pow gave back -0.",1.0,"math: wrong result for Pow(±0, .5) contrary to documentation - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.9.2 linux/amd64 ### Does this issue reproduce with the latest release? I believe go1.9.2 is the latest release. ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/usr/local/google/home/majnemer/go"" GORACE="""" GOROOT=""/usr/lib/google-golang"" GOTOOLDIR=""/usr/lib/google-golang/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build846653371=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? I ran the following program: https://play.golang.org/p/_lUAaRG9D-P ### What did you expect to see? The [documentation for math.Pow](https://golang.org/pkg/math/#Pow) says the following: > Pow(±0, y) = +0 for finite y > 0 and not an odd integer .5 is finite and not an odd integer which means math.Pow should give back +0. ### What did you see instead? math.Pow gave back -0.",1,math wrong result for pow ± contrary to documentation please answer these questions before submitting your issue thanks what version of go are you using go version go version linux does this issue reproduce with the latest release i believe is the latest release what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath usr local google home majnemer go gorace goroot usr lib google golang gotooldir usr lib google golang pkg tool linux gccgo gccgo cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config what did you do i ran the following program what did you expect to see the says the following pow ± y for finite y and not an odd integer is finite and not an odd integer which means math pow should give back what did you see instead math pow gave back ,1 49618,7523803642.0,IssuesEvent,2018-04-13 03:15:47,golang/go,https://api.github.com/repos/golang/go,closed,runtime: document that calling LockOSThread in init will lock main to m0 (the first OS thread),Documentation NeedsFix,"Continued from a brief in-person discussion with Ian and Keith earlier today. A lot of people (including myself) want to write GUI programs in Go; we even had `shiny` to provide our own solution to this desire. Most, if not all OSs, require that all GUI code runs on a single OS thread, but most don't care *which* OS thread is used. macOS is the exception — macOS consigns the idea that the very first thread created by the OS is the only one allowed to do GUI stuff, and it has a few ways to do this: - it provides the `pthread_main_np()` function, which returns true if the current thread is the first thread the OS creates (and in the Darwin kernel, pthreads *are* the kernel threading model, in essence); WebKit calls this function directly - libSystem.dylib, the shared library that all programs eventually link to (think kernel32.dll on Windows), uses `__attribute__((constructor))` to call a variety of thread-specific initialization functions in other libraries (such as libdispatch, which is important for modern Cocoa programming) - Core Foundation, which Cocoa is built on top of, uses a variety of undocumented variables to control its own data structures that, while they can be overridden with the correct `extern` statements, will not catch all possible cases - this list is probably incomplete Various components in Cocoa have internal consistency checks to make sure they are only ever called on the ""main thread""; a program *will* abort if these checks fail. In runtime-speak, the first thread created by the OS is called `m0` (or was called `m0` back when the runtime was written in C), so I will call it that from here on out. On other platforms, we could just insert a `runtime.LockOSThread()` in a goroutine to tie the goroutine that will do all GUI stuff to an OS thread, but for macOS this alone wouldn't work. I have found a number of ways to bypass some of the above bullet points, but things just wind up breaking later (and I don't think the libdispatch thing can be hacked without hard-coding its internal data structures...). And this doesn't even consider things like transpiled JavaScript (in which I don't even know what the requirements *are*) or mobile platforms (I'm sure iOS has the same requirements as macOS but I'm not sure about any other platform). So far, the most widely used workaround has been to call `runtime.LockOSThread()` in `init`. I didn't think this was a good solution because there was no guarantee that `init` will always stay on `m0`, especially once `init` was allowed to run concurrently with other goroutines. However, after talking with Ian and Keith earlier today, I learned that this is already guaranteed, just not documented. If this was documented, then we could all safely rely on the behavior. I wouldn't know if this should be documented in package runtime (under LockOSThread) or in the spec (as part of the definition of initialization behavior). Furthermore, there's the potential that a different package's `init` will call `runtime.UnlockOSThread()`, most likely to undo its own `runtime.LockOSThread()` — in which case, `LockOSThread` should be nested. Nesting will handle the case of a *later* package calling `UnlockOSThread`, but not of an *earlier* one doing so too, so perhaps `UnlockOSThread` should also be made a no-op in `init` functions, if that's even possible. And of course, all bets are off if another function in `main` calls `UnlockOSThread`. Even if this is also made a no-op (which is probably not a good idea), package authors will need to document what functions must be run in `main`. This isn't a problem, though; it's something package authors should know, though.",1.0,"runtime: document that calling LockOSThread in init will lock main to m0 (the first OS thread) - Continued from a brief in-person discussion with Ian and Keith earlier today. A lot of people (including myself) want to write GUI programs in Go; we even had `shiny` to provide our own solution to this desire. Most, if not all OSs, require that all GUI code runs on a single OS thread, but most don't care *which* OS thread is used. macOS is the exception — macOS consigns the idea that the very first thread created by the OS is the only one allowed to do GUI stuff, and it has a few ways to do this: - it provides the `pthread_main_np()` function, which returns true if the current thread is the first thread the OS creates (and in the Darwin kernel, pthreads *are* the kernel threading model, in essence); WebKit calls this function directly - libSystem.dylib, the shared library that all programs eventually link to (think kernel32.dll on Windows), uses `__attribute__((constructor))` to call a variety of thread-specific initialization functions in other libraries (such as libdispatch, which is important for modern Cocoa programming) - Core Foundation, which Cocoa is built on top of, uses a variety of undocumented variables to control its own data structures that, while they can be overridden with the correct `extern` statements, will not catch all possible cases - this list is probably incomplete Various components in Cocoa have internal consistency checks to make sure they are only ever called on the ""main thread""; a program *will* abort if these checks fail. In runtime-speak, the first thread created by the OS is called `m0` (or was called `m0` back when the runtime was written in C), so I will call it that from here on out. On other platforms, we could just insert a `runtime.LockOSThread()` in a goroutine to tie the goroutine that will do all GUI stuff to an OS thread, but for macOS this alone wouldn't work. I have found a number of ways to bypass some of the above bullet points, but things just wind up breaking later (and I don't think the libdispatch thing can be hacked without hard-coding its internal data structures...). And this doesn't even consider things like transpiled JavaScript (in which I don't even know what the requirements *are*) or mobile platforms (I'm sure iOS has the same requirements as macOS but I'm not sure about any other platform). So far, the most widely used workaround has been to call `runtime.LockOSThread()` in `init`. I didn't think this was a good solution because there was no guarantee that `init` will always stay on `m0`, especially once `init` was allowed to run concurrently with other goroutines. However, after talking with Ian and Keith earlier today, I learned that this is already guaranteed, just not documented. If this was documented, then we could all safely rely on the behavior. I wouldn't know if this should be documented in package runtime (under LockOSThread) or in the spec (as part of the definition of initialization behavior). Furthermore, there's the potential that a different package's `init` will call `runtime.UnlockOSThread()`, most likely to undo its own `runtime.LockOSThread()` — in which case, `LockOSThread` should be nested. Nesting will handle the case of a *later* package calling `UnlockOSThread`, but not of an *earlier* one doing so too, so perhaps `UnlockOSThread` should also be made a no-op in `init` functions, if that's even possible. And of course, all bets are off if another function in `main` calls `UnlockOSThread`. Even if this is also made a no-op (which is probably not a good idea), package authors will need to document what functions must be run in `main`. This isn't a problem, though; it's something package authors should know, though.",1,runtime document that calling lockosthread in init will lock main to the first os thread continued from a brief in person discussion with ian and keith earlier today a lot of people including myself want to write gui programs in go we even had shiny to provide our own solution to this desire most if not all oss require that all gui code runs on a single os thread but most don t care which os thread is used macos is the exception — macos consigns the idea that the very first thread created by the os is the only one allowed to do gui stuff and it has a few ways to do this it provides the pthread main np function which returns true if the current thread is the first thread the os creates and in the darwin kernel pthreads are the kernel threading model in essence webkit calls this function directly libsystem dylib the shared library that all programs eventually link to think dll on windows uses attribute constructor to call a variety of thread specific initialization functions in other libraries such as libdispatch which is important for modern cocoa programming core foundation which cocoa is built on top of uses a variety of undocumented variables to control its own data structures that while they can be overridden with the correct extern statements will not catch all possible cases this list is probably incomplete various components in cocoa have internal consistency checks to make sure they are only ever called on the main thread a program will abort if these checks fail in runtime speak the first thread created by the os is called or was called back when the runtime was written in c so i will call it that from here on out on other platforms we could just insert a runtime lockosthread in a goroutine to tie the goroutine that will do all gui stuff to an os thread but for macos this alone wouldn t work i have found a number of ways to bypass some of the above bullet points but things just wind up breaking later and i don t think the libdispatch thing can be hacked without hard coding its internal data structures and this doesn t even consider things like transpiled javascript in which i don t even know what the requirements are or mobile platforms i m sure ios has the same requirements as macos but i m not sure about any other platform so far the most widely used workaround has been to call runtime lockosthread in init i didn t think this was a good solution because there was no guarantee that init will always stay on especially once init was allowed to run concurrently with other goroutines however after talking with ian and keith earlier today i learned that this is already guaranteed just not documented if this was documented then we could all safely rely on the behavior i wouldn t know if this should be documented in package runtime under lockosthread or in the spec as part of the definition of initialization behavior furthermore there s the potential that a different package s init will call runtime unlockosthread most likely to undo its own runtime lockosthread — in which case lockosthread should be nested nesting will handle the case of a later package calling unlockosthread but not of an earlier one doing so too so perhaps unlockosthread should also be made a no op in init functions if that s even possible and of course all bets are off if another function in main calls unlockosthread even if this is also made a no op which is probably not a good idea package authors will need to document what functions must be run in main this isn t a problem though it s something package authors should know though ,1 173135,14403476244.0,IssuesEvent,2020-12-03 16:06:11,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document net/http/httputil changes for Go 1.16,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/http/httputil

TODO: https://golang.org/cl/260637: flush ReverseProxy immediately if Content-Length is -1

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document net/http/httputil changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
net/http/httputil

TODO: https://golang.org/cl/260637: flush ReverseProxy immediately if Content-Length is -1

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document net http httputil changes for go as of filing this issue the contained the following html net http httputil todo a href flush reverseproxy immediately if content length is per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 55176,7964638281.0,IssuesEvent,2018-07-13 22:30:35,golang/go,https://api.github.com/repos/golang/go,closed,os/exec: document that ExtraFiles does not work on Windows,Documentation NeedsFix help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.10.3 windows/amd64 ### Does this issue reproduce with the latest release? 1.10.3 seems to be currently the latest release so: yep. ### What operating system and processor architecture are you using (`go env`)? windows 10 home, amd64, Intel i5-6200U ``` set GOARCH=amd64 set GOBIN=%GOPATH%\bin set GOCACHE=C:\Users\me\AppData\Local\go-build set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\Users\me\go set GORACE= set GOROOT=C:\Go set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build361648014=/tmp/go-build -gno-record-gcc-switches ``` **BTW**: Having `GOBIN=%GOPATH%\bin` causes a lot of packages (from github) to not compile for some reason. (It works if one overrides it with manually expanding GOPATH). ### What did you do? The package os.Exec mentions that some examples assume Unix and might not work on Windows but it doesn't mention that it doesn't support windows and by looking at the source code it oughta support it. ``` fork/exec prog.exe: not supported by windows ``` ```go cmd := exec.Command(normCmd) // direct access to datafile cmd.Stdin = rawfile // metadata-filtered observations on stdout obspipe, err := cmd.StdoutPipe() if err != nil { return err } // pass through stderr cmd.Stderr = os.Stderr // metadata on fd 3 metapipeCmd, metapipe, err := os.Pipe() if err != nil { return err } cmd.ExtraFiles = make([]*os.File, 1) cmd.ExtraFiles[0] = metapipeCmd // start the command if err := cmd.Start(); err != nil { // errors on windows log.Fatal(err) return err } ``` ### What did you expect to see? The program being run. ### What did you see instead? An error message.",1.0,"os/exec: document that ExtraFiles does not work on Windows - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? 1.10.3 windows/amd64 ### Does this issue reproduce with the latest release? 1.10.3 seems to be currently the latest release so: yep. ### What operating system and processor architecture are you using (`go env`)? windows 10 home, amd64, Intel i5-6200U ``` set GOARCH=amd64 set GOBIN=%GOPATH%\bin set GOCACHE=C:\Users\me\AppData\Local\go-build set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\Users\me\go set GORACE= set GOROOT=C:\Go set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build361648014=/tmp/go-build -gno-record-gcc-switches ``` **BTW**: Having `GOBIN=%GOPATH%\bin` causes a lot of packages (from github) to not compile for some reason. (It works if one overrides it with manually expanding GOPATH). ### What did you do? The package os.Exec mentions that some examples assume Unix and might not work on Windows but it doesn't mention that it doesn't support windows and by looking at the source code it oughta support it. ``` fork/exec prog.exe: not supported by windows ``` ```go cmd := exec.Command(normCmd) // direct access to datafile cmd.Stdin = rawfile // metadata-filtered observations on stdout obspipe, err := cmd.StdoutPipe() if err != nil { return err } // pass through stderr cmd.Stderr = os.Stderr // metadata on fd 3 metapipeCmd, metapipe, err := os.Pipe() if err != nil { return err } cmd.ExtraFiles = make([]*os.File, 1) cmd.ExtraFiles[0] = metapipeCmd // start the command if err := cmd.Start(); err != nil { // errors on windows log.Fatal(err) return err } ``` ### What did you expect to see? The program being run. ### What did you see instead? An error message.",1,os exec document that extrafiles does not work on windows please answer these questions before submitting your issue thanks what version of go are you using go version windows does this issue reproduce with the latest release seems to be currently the latest release so yep what operating system and processor architecture are you using go env windows home intel set goarch set gobin gopath bin set gocache c users me appdata local go build set goexe exe set gohostarch set gohostos windows set goos windows set gopath c users me go set gorace set goroot c go set gotmpdir set gotooldir c go pkg tool windows set gccgo gccgo set cc gcc set cxx g set cgo enabled set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags mthreads fmessage length fdebug prefix map c users me appdata local temp go tmp go build gno record gcc switches btw having gobin gopath bin causes a lot of packages from github to not compile for some reason it works if one overrides it with manually expanding gopath what did you do the package os exec mentions that some examples assume unix and might not work on windows but it doesn t mention that it doesn t support windows and by looking at the source code it oughta support it fork exec prog exe not supported by windows go cmd exec command normcmd direct access to datafile cmd stdin rawfile metadata filtered observations on stdout obspipe err cmd stdoutpipe if err nil return err pass through stderr cmd stderr os stderr metadata on fd metapipecmd metapipe err os pipe if err nil return err cmd extrafiles make os file cmd extrafiles metapipecmd start the command if err cmd start err nil errors on windows log fatal err return err what did you expect to see the program being run what did you see instead an error message ,1 369754,25866816397.0,IssuesEvent,2022-12-13 21:41:26,golang/go,https://api.github.com/repos/golang/go,closed,x/net/websocket: remove Gorilla recommendation in docs,Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? 1.18 ### Does this issue reproduce with the latest release? No Issue ### What operating system and processor architecture are you using (`go env`)? ### What did you do? Read the docs ### What did you expect to see? How to use the x/net/websocket library ### What did you see instead? https://github.com/golang/net/blob/e1ec361d0b39748d321472b2be7298211e05a3b6/websocket/websocket.go#L11 Gorilla recommendation which is now archived ",1.0,"x/net/websocket: remove Gorilla recommendation in docs - ### What version of Go are you using (`go version`)? 1.18 ### Does this issue reproduce with the latest release? No Issue ### What operating system and processor architecture are you using (`go env`)? ### What did you do? Read the docs ### What did you expect to see? How to use the x/net/websocket library ### What did you see instead? https://github.com/golang/net/blob/e1ec361d0b39748d321472b2be7298211e05a3b6/websocket/websocket.go#L11 Gorilla recommendation which is now archived ",1,x net websocket remove gorilla recommendation in docs what version of go are you using go version does this issue reproduce with the latest release no issue what operating system and processor architecture are you using go env what did you do read the docs what did you expect to see how to use the x net websocket library what did you see instead gorilla recommendation which is now archived ,1 57909,8213405542.0,IssuesEvent,2018-09-04 19:26:58,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: for go mod download, -dir option does not exist",Documentation NeedsFix modules,"### What version of Go are you using (`go version`)? go version go1.11 linux/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOOS=""linux"" ### What did you do? $ echo $PWD /home/mpl/src/perkeep.org $ echo $GOPATH /home/mpl $ echo $GO111MODULE on $ go mod download -dir github.com/gopherjs/gopherjs flag provided but not defined: -dir usage: go mod download [-dir] [-json] [modules] Run 'go help mod download' for details. ### What did you expect to see? I wanted to see what the -dir option does. The longer answer is I was trying to find out where go get/download stores the downloaded sources, since I hadn't found it in the documentation. I now see with a more thorough read that it is in GOPATH/pkg/mod ",1.0,"cmd/go: for go mod download, -dir option does not exist - ### What version of Go are you using (`go version`)? go version go1.11 linux/amd64 ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOOS=""linux"" ### What did you do? $ echo $PWD /home/mpl/src/perkeep.org $ echo $GOPATH /home/mpl $ echo $GO111MODULE on $ go mod download -dir github.com/gopherjs/gopherjs flag provided but not defined: -dir usage: go mod download [-dir] [-json] [modules] Run 'go help mod download' for details. ### What did you expect to see? I wanted to see what the -dir option does. The longer answer is I was trying to find out where go get/download stores the downloaded sources, since I hadn't found it in the documentation. I now see with a more thorough read that it is in GOPATH/pkg/mod ",1,cmd go for go mod download dir option does not exist what version of go are you using go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch goos linux what did you do echo pwd home mpl src perkeep org echo gopath home mpl echo on go mod download dir github com gopherjs gopherjs flag provided but not defined dir usage go mod download run go help mod download for details what did you expect to see i wanted to see what the dir option does the longer answer is i was trying to find out where go get download stores the downloaded sources since i hadn t found it in the documentation i now see with a more thorough read that it is in gopath pkg mod ,1 208349,16111351968.0,IssuesEvent,2021-04-27 21:45:00,golang/go,https://api.github.com/repos/golang/go,closed,testing: document that TestMain always runs before any benchmarks,Documentation NeedsFix help wanted,"The docs for `TestMain` say: ``` It is sometimes necessary for a test program to do extra setup or teardown before or after testing. ``` https://golang.org/pkg/testing/#hdr-Main But what if one needs to do extra setup before benchmarking? It appears that `TestMain` would also always run before benchmarks, but neither `TestMain` doc nor `M.Run` doc say anything about benchmarks.",1.0,"testing: document that TestMain always runs before any benchmarks - The docs for `TestMain` say: ``` It is sometimes necessary for a test program to do extra setup or teardown before or after testing. ``` https://golang.org/pkg/testing/#hdr-Main But what if one needs to do extra setup before benchmarking? It appears that `TestMain` would also always run before benchmarks, but neither `TestMain` doc nor `M.Run` doc say anything about benchmarks.",1,testing document that testmain always runs before any benchmarks the docs for testmain say it is sometimes necessary for a test program to do extra setup or teardown before or after testing but what if one needs to do extra setup before benchmarking it appears that testmain would also always run before benchmarks but neither testmain doc nor m run doc say anything about benchmarks ,1 252225,19008337855.0,IssuesEvent,2021-11-23 05:13:34,golang/go,https://api.github.com/repos/golang/go,closed,path.Base and path.Split do not properly split the file name on Windows as documented,Documentation,"### What version of Go are you using (`go version`)? 
go version go1.17.3 windows/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\heath\AppData\Local\go-build
set GOENV=C:\Users\heath\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\heath\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\heath\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17.3
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\heath\AppData\Local\Temp\go-build4257983573=/tmp/go-build -gno-record-gcc-switches
### What did you do? Using `path.Base()` and `path.Split()` on Windows, I found they do not return just the file name (or directory and filename separated) as documented. They work as documented on WSL2 (Ubunto 18.04, however). ```go package main import ( ""fmt"" ""os"" ""path"" ) func main() { fmt.Println(""base ="", path.Base(os.Args[0])) dir, file := path.Split(os.Args[0]) fmt.Printf(""dir = %q, file = %q\n"", dir, file) } ``` ### What did you expect to see? I expected the file name itself to be returned from `path.Base`, as well as the directory and file name in `dir` and `file` parameters from `path.Split`. ### What did you see instead? On Windows, the entire path was found in place of the file as shown in the output from the sample program below: ``` base = C:\Users\heath\AppData\Local\Temp\go-build2408382784\b001\exe\main.exe dir = """", file = ""C:\\Users\\heath\\AppData\\Local\\Temp\\go-build2408382784\\b001\\exe\\main.exe"" ``` On Ubuntu the content below is correct according to documentation and is what I expected: ``` base = main dir = ""/tmp/go-build2295857948/b001/exe/"", file = ""main"" ```",1.0,"path.Base and path.Split do not properly split the file name on Windows as documented - ### What version of Go are you using (`go version`)? 
go version go1.17.3 windows/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\heath\AppData\Local\go-build
set GOENV=C:\Users\heath\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\heath\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\heath\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17.3
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\heath\AppData\Local\Temp\go-build4257983573=/tmp/go-build -gno-record-gcc-switches
### What did you do? Using `path.Base()` and `path.Split()` on Windows, I found they do not return just the file name (or directory and filename separated) as documented. They work as documented on WSL2 (Ubunto 18.04, however). ```go package main import ( ""fmt"" ""os"" ""path"" ) func main() { fmt.Println(""base ="", path.Base(os.Args[0])) dir, file := path.Split(os.Args[0]) fmt.Printf(""dir = %q, file = %q\n"", dir, file) } ``` ### What did you expect to see? I expected the file name itself to be returned from `path.Base`, as well as the directory and file name in `dir` and `file` parameters from `path.Split`. ### What did you see instead? On Windows, the entire path was found in place of the file as shown in the output from the sample program below: ``` base = C:\Users\heath\AppData\Local\Temp\go-build2408382784\b001\exe\main.exe dir = """", file = ""C:\\Users\\heath\\AppData\\Local\\Temp\\go-build2408382784\\b001\\exe\\main.exe"" ``` On Ubuntu the content below is correct according to documentation and is what I expected: ``` base = main dir = ""/tmp/go-build2295857948/b001/exe/"", file = ""main"" ```",1,path base and path split do not properly split the file name on windows as documented what version of go are you using go version go version windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output set set goarch set gobin set gocache c users heath appdata local go build set goenv c users heath appdata roaming go env set goexe exe set goexperiment set goflags set gohostarch set gohostos windows set goinsecure set gomodcache c users heath go pkg mod set gonoproxy set gonosumdb set goos windows set gopath c users heath go set goprivate set goproxy set goroot c program files go set gosumdb sum golang org set gotmpdir set gotooldir c program files go pkg tool windows set govcs set goversion set gccgo gccgo set ar ar set cc gcc set cxx g set cgo enabled set gomod nul set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags mthreads fno caret diagnostics qunused arguments fmessage length fdebug prefix map c users heath appdata local temp go tmp go build gno record gcc switches what did you do using path base and path split on windows i found they do not return just the file name or directory and filename separated as documented they work as documented on ubunto however go package main import fmt os path func main fmt println base path base os args dir file path split os args fmt printf dir q file q n dir file what did you expect to see i expected the file name itself to be returned from path base as well as the directory and file name in dir and file parameters from path split what did you see instead on windows the entire path was found in place of the file as shown in the output from the sample program below base c users heath appdata local temp go exe main exe dir file c users heath appdata local temp go exe main exe on ubuntu the content below is correct according to documentation and is what i expected base main dir tmp go exe file main ,1 41574,10737407027.0,IssuesEvent,2019-10-29 13:02:30,golang/go,https://api.github.com/repos/golang/go,opened,x/build: misc/reboot.TestRepeatBootstrap flaky during toolchain3 on linux-ppc64le-*,Builders NeedsInvestigation arch-ppc64x,"The `linux-ppc64le` builders are frequently failing in `TestRepeatBootstrap`. The failure mode seems to always be a `compile` error when building `cmd/compile/internal/ssa` during the `Building Go toolchain3` step. Sometimes the `compile` command fails with `exit status 1` (https://build.golang.org/log/91e2d3f5fd454609faf1f004a756382ad5aa6e20). Sometimes it instead fails with `signal: killed` (https://build.golang.org/log/00d4e0a84ece047eaa53251c7c4fc0955bba8eea). Is it possible that this step is running out of RAM? CC @randall77 @bradfitz @dmitshur @laboger ",1.0,"x/build: misc/reboot.TestRepeatBootstrap flaky during toolchain3 on linux-ppc64le-* - The `linux-ppc64le` builders are frequently failing in `TestRepeatBootstrap`. The failure mode seems to always be a `compile` error when building `cmd/compile/internal/ssa` during the `Building Go toolchain3` step. Sometimes the `compile` command fails with `exit status 1` (https://build.golang.org/log/91e2d3f5fd454609faf1f004a756382ad5aa6e20). Sometimes it instead fails with `signal: killed` (https://build.golang.org/log/00d4e0a84ece047eaa53251c7c4fc0955bba8eea). Is it possible that this step is running out of RAM? CC @randall77 @bradfitz @dmitshur @laboger ",0,x build misc reboot testrepeatbootstrap flaky during on linux the linux builders are frequently failing in testrepeatbootstrap the failure mode seems to always be a compile error when building cmd compile internal ssa during the building go step sometimes the compile command fails with exit status sometimes it instead fails with signal killed is it possible that this step is running out of ram cc bradfitz dmitshur laboger ,0 148576,13240030536.0,IssuesEvent,2020-08-19 05:18:26,golang/go,https://api.github.com/repos/golang/go,opened,x/debug: change the repo description used in golang.org/pkg page.,Documentation,"![image](https://user-images.githubusercontent.com/4999471/90594870-808ac980-e1b9-11ea-887a-772397d5e77a.png) Here, the 'x/debug' repo is listed as a repo for 'an experimental debugger for Go'. This is outdated. Please update the repo description and this documentation.",1.0,"x/debug: change the repo description used in golang.org/pkg page. - ![image](https://user-images.githubusercontent.com/4999471/90594870-808ac980-e1b9-11ea-887a-772397d5e77a.png) Here, the 'x/debug' repo is listed as a repo for 'an experimental debugger for Go'. This is outdated. Please update the repo description and this documentation.",1,x debug change the repo description used in golang org pkg page here the x debug repo is listed as a repo for an experimental debugger for go this is outdated please update the repo description and this documentation ,1 84019,10347358426.0,IssuesEvent,2019-09-04 17:12:26,golang/go,https://api.github.com/repos/golang/go,closed,doc: errors: wrong unwrap example,Documentation," ### What version of Go are you using (`go version`)? 
go 1.13
Documentation provides this example of `Unwrap` call https://github.com/golang/go/blob/master/src/errors/errors.go#L19. But this example wont work because `fmt.Errorf` returned `error` interface https://play.golang.org/p/KaQv-yJl6yy ",1.0,"doc: errors: wrong unwrap example - ### What version of Go are you using (`go version`)? 
go 1.13
Documentation provides this example of `Unwrap` call https://github.com/golang/go/blob/master/src/errors/errors.go#L19. But this example wont work because `fmt.Errorf` returned `error` interface https://play.golang.org/p/KaQv-yJl6yy ",1,doc errors wrong unwrap example what version of go are you using go version go documentation provides this example of unwrap call but this example wont work because fmt errorf returned error interface ,1 97353,28210504181.0,IssuesEvent,2023-04-05 03:35:45,golang/go,https://api.github.com/repos/golang/go,closed,Testing packages.: unrecognized failures,Builders NeedsInvestigation,"``` #!watchflakes default <- repo == ""go"" && section == ""Testing packages."" && test == """" && !(log ~ `^Test "".*"" ran over .* limit`) ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/95fa11f21bd73b56b217cfe4789cc65c57015c4d)): — [watchflakes](https://go.dev/wiki/Watchflakes) ",1.0,"Testing packages.: unrecognized failures - ``` #!watchflakes default <- repo == ""go"" && section == ""Testing packages."" && test == """" && !(log ~ `^Test "".*"" ran over .* limit`) ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/95fa11f21bd73b56b217cfe4789cc65c57015c4d)): — [watchflakes](https://go.dev/wiki/Watchflakes) ",0,testing packages unrecognized failures watchflakes default repo go section testing packages test log test ran over limit issue created automatically to collect these failures example — ,0 185385,15020920258.0,IssuesEvent,2021-02-01 15:14:49,golang/go,https://api.github.com/repos/golang/go,closed,x/website: tutorial function name typo,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.7
### Does this issue reproduce with the latest release? This is not a 'Go' issue, but maybe a typo in the tutorial [Return greetings for multiple people](https://golang.org/doc/tutorial/greetings-multiple-people). ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
Windows , AMD Ryzen5 2600x
### What did you do? Walked through in the tutorial [Return greetings for multiple people](https://golang.org/doc/tutorial/greetings-multiple-people). ### What did you expect to see? The tutorial has this line: ""You have the **Hello** function return this map to the caller."". ### What did you see instead? But it should be: ""You have the **Hellos** function return this map to the caller."". Since the function that returns maps is named Hellos.",1.0,"x/website: tutorial function name typo - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.15.7
### Does this issue reproduce with the latest release? This is not a 'Go' issue, but maybe a typo in the tutorial [Return greetings for multiple people](https://golang.org/doc/tutorial/greetings-multiple-people). ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
Windows , AMD Ryzen5 2600x
### What did you do? Walked through in the tutorial [Return greetings for multiple people](https://golang.org/doc/tutorial/greetings-multiple-people). ### What did you expect to see? The tutorial has this line: ""You have the **Hello** function return this map to the caller."". ### What did you see instead? But it should be: ""You have the **Hellos** function return this map to the caller."". Since the function that returns maps is named Hellos.",1,x website tutorial function name typo please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version does this issue reproduce with the latest release this is not a go issue but maybe a typo in the tutorial what operating system and processor architecture are you using go env go env output go env windows amd what did you do walked through in the tutorial if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see the tutorial has this line you have the hello function return this map to the caller what did you see instead but it should be you have the hellos function return this map to the caller since the function that returns maps is named hellos ,1 353941,25142855577.0,IssuesEvent,2022-11-10 01:12:42,golang/go,https://api.github.com/repos/golang/go,opened,spec: `append` doesn't specify zero values when growing underlying array,Documentation,"When `append` is called on a slice and the underlying array is not large enough, a new underlying array is allocated, possibly increasing the slice's capacity significantly (typically doubling it). The spec doesn't specify the value of any slice elements past the slice length and up to the capacity.",1.0,"spec: `append` doesn't specify zero values when growing underlying array - When `append` is called on a slice and the underlying array is not large enough, a new underlying array is allocated, possibly increasing the slice's capacity significantly (typically doubling it). The spec doesn't specify the value of any slice elements past the slice length and up to the capacity.",1,spec append doesn t specify zero values when growing underlying array when append is called on a slice and the underlying array is not large enough a new underlying array is allocated possibly increasing the slice s capacity significantly typically doubling it the spec doesn t specify the value of any slice elements past the slice length and up to the capacity ,1 81105,23390557270.0,IssuesEvent,2022-08-11 17:24:13,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/relui: workflow parameters of slice types aren't visibly shown,Builders NeedsFix,"relui currently renders a recent ""announce-and-tweet-minor"" workflow from the Go 1.18.5 and 1.17.13 minor release: ![image](https://user-images.githubusercontent.com/1924134/182671788-9886ab98-dd4b-4585-ae1e-d3d40ca34295.png) The values for the string parameters ""Version"", ""Security Summary"", etc., are displayed, but not for the ""Release Coordinator Names"" and ""Security Fixes"" parameters, likely because their type is []string. (The parameter values are there in the database and were correctly used by the tasks; this is only a presentation issue.) CC @golang/release, @cherrymui.",1.0,"x/build/cmd/relui: workflow parameters of slice types aren't visibly shown - relui currently renders a recent ""announce-and-tweet-minor"" workflow from the Go 1.18.5 and 1.17.13 minor release: ![image](https://user-images.githubusercontent.com/1924134/182671788-9886ab98-dd4b-4585-ae1e-d3d40ca34295.png) The values for the string parameters ""Version"", ""Security Summary"", etc., are displayed, but not for the ""Release Coordinator Names"" and ""Security Fixes"" parameters, likely because their type is []string. (The parameter values are there in the database and were correctly used by the tasks; this is only a presentation issue.) CC @golang/release, @cherrymui.",0,x build cmd relui workflow parameters of slice types aren t visibly shown relui currently renders a recent announce and tweet minor workflow from the go and minor release the values for the string parameters version security summary etc are displayed but not for the release coordinator names and security fixes parameters likely because their type is string the parameter values are there in the database and were correctly used by the tasks this is only a presentation issue cc golang release cherrymui ,0 82521,10293662551.0,IssuesEvent,2019-08-27 16:55:24,golang/go,https://api.github.com/repos/golang/go,closed,errors: better document Go 1.13 Is/As/Unwrap features,Documentation NeedsDecision release-blocker,"See the current version of the Go 1.13 documentation for the errors package here: https://tip.golang.org/pkg/errors/ If I hadn't read the [error values design](https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md) and related discussion, I think I'd have a hard time understanding the new APIs. Some questions I might have include: * Is and As documentation refers to ""err's chain"". What is a chain? * Is, As, and Unwrap all refer to optional interface methods of the same names. When should errors implement those interfaces? * What is the relationship between Is, As, and Unwrap? * As an application developer, how should I be using Is, As, and Unwrap? How about as the author of a package others use?",1.0,"errors: better document Go 1.13 Is/As/Unwrap features - See the current version of the Go 1.13 documentation for the errors package here: https://tip.golang.org/pkg/errors/ If I hadn't read the [error values design](https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md) and related discussion, I think I'd have a hard time understanding the new APIs. Some questions I might have include: * Is and As documentation refers to ""err's chain"". What is a chain? * Is, As, and Unwrap all refer to optional interface methods of the same names. When should errors implement those interfaces? * What is the relationship between Is, As, and Unwrap? * As an application developer, how should I be using Is, As, and Unwrap? How about as the author of a package others use?",1,errors better document go is as unwrap features see the current version of the go documentation for the errors package here if i hadn t read the and related discussion i think i d have a hard time understanding the new apis some questions i might have include is and as documentation refers to err s chain what is a chain is as and unwrap all refer to optional interface methods of the same names when should errors implement those interfaces what is the relationship between is as and unwrap as an application developer how should i be using is as and unwrap how about as the author of a package others use ,1 3405,2762357609.0,IssuesEvent,2015-04-28 22:10:13,golang/go,https://api.github.com/repos/golang/go,closed,net/http: clarify docs on ResponseWriter.Write and Response.Write,Documentation,"by **opennota**: 
When writing to the http.ResponseWriter, the http.Response's method Write doesn't do
what is expected.

    func handler(w http.ResponseWriter, r *http.Request) {
    	resp, _ := client.Get("http://google.com/";)
    	resp.Write(w)
    }

This will write resp's headers to the *body* of the handler's response, with the
text/plain content type.

A method that *copies* a Response would be helpful.
",1.0,"net/http: clarify docs on ResponseWriter.Write and Response.Write - by **opennota**: 
When writing to the http.ResponseWriter, the http.Response's method Write doesn't do
what is expected.

    func handler(w http.ResponseWriter, r *http.Request) {
    	resp, _ := client.Get("http://google.com/";)
    	resp.Write(w)
    }

This will write resp's headers to the *body* of the handler's response, with the
text/plain content type.

A method that *copies* a Response would be helpful.
",1,net http clarify docs on responsewriter write and response write by opennota when writing to the http responsewriter the http response s method write doesn t do what is expected func handler w http responsewriter r http request resp client get quot a href resp write w this will write resp s headers to the body of the handler s response with the text plain content type a method that copies a response would be helpful ,1 33114,6156817559.0,IssuesEvent,2017-06-28 17:34:19,golang/go,https://api.github.com/repos/golang/go,closed,spec: grammar mistake,Documentation,"> If map entries are created during iteration, that entry may be produced during the iteration or may be skipped. `map entries are` should be `a map entry is`.",1.0,"spec: grammar mistake - > If map entries are created during iteration, that entry may be produced during the iteration or may be skipped. `map entries are` should be `a map entry is`.",1,spec grammar mistake if map entries are created during iteration that entry may be produced during the iteration or may be skipped map entries are should be a map entry is ,1 2239,2900205884.0,IssuesEvent,2015-06-17 15:21:30,golang/go,https://api.github.com/repos/golang/go,closed,x/build/builders: ARM builders,Builders,"
This bug is about creating ARM qemu full-system-emulation environments for running Go
builds. This is part of http://golang.org/s/builderplan

For ARM5,
The versatilepb machine (ARM5?) is quite slow can can run "make.bash" is about
25 minutes:
https://people.debian.org/~aurel32/qemu/armel/

We could cross-compile make.bash from x86 and just shard (a subset of?) run.bash on
qemu-system-arm -M versatilepb.

For ARM7+, it seems qemu in recent versions supports newer CPUs and supports multiple
cores as well? That might help.

In any case, this will be slow, and will depend on being able to shard tests out over
perhaps hundreds of CPUs (each running a full Linux kernel + tiny userspace which we
control, doing nothing but running our builders).

It'd be nice if the tiny userspace running inside the qemu-system-arm ran Docker, so
then we'd have a snapshotting filesystem which we could send around the network, which
we'll want for sharding.

We can use this bug to discuss and collect notes.
",1.0,"x/build/builders: ARM builders - 
This bug is about creating ARM qemu full-system-emulation environments for running Go
builds. This is part of http://golang.org/s/builderplan

For ARM5,
The versatilepb machine (ARM5?) is quite slow can can run "make.bash" is about
25 minutes:
https://people.debian.org/~aurel32/qemu/armel/

We could cross-compile make.bash from x86 and just shard (a subset of?) run.bash on
qemu-system-arm -M versatilepb.

For ARM7+, it seems qemu in recent versions supports newer CPUs and supports multiple
cores as well? That might help.

In any case, this will be slow, and will depend on being able to shard tests out over
perhaps hundreds of CPUs (each running a full Linux kernel + tiny userspace which we
control, doing nothing but running our builders).

It'd be nice if the tiny userspace running inside the qemu-system-arm ran Docker, so
then we'd have a snapshotting filesystem which we could send around the network, which
we'll want for sharding.

We can use this bug to discuss and collect notes.
",0,x build builders arm builders this bug is about creating arm qemu full system emulation environments for running go builds this is part of a href for the versatilepb machine is quite slow can can run quot make bash quot is about minutes a href we could cross compile make bash from and just shard a subset of run bash on qemu system arm m versatilepb for it seems qemu in recent versions supports newer cpus and supports multiple cores as well that might help in any case this will be slow and will depend on being able to shard tests out over perhaps hundreds of cpus each running a full linux kernel tiny userspace which we control doing nothing but running our builders it d be nice if the tiny userspace running inside the qemu system arm ran docker so then we d have a snapshotting filesystem which we could send around the network which we ll want for sharding we can use this bug to discuss and collect notes ,0 307839,23219161876.0,IssuesEvent,2022-08-02 16:29:09,golang/go,https://api.github.com/repos/golang/go,closed,doc: write Go 1.19 release notes,Documentation NeedsFix umbrella,"Tracking bug for writing the Go 1.19 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.19. When the Go 1.19 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #47694, https://github.com/golang/go/issues/44513, https://github.com/golang/go/issues/40700, https://github.com/golang/go/issues/37419, https://github.com/golang/go/issues/36878, https://github.com/golang/go/issues/17929, https://github.com/golang/go/issues/15810, https://github.com/golang/go/issues/5929, etc.",1.0,"doc: write Go 1.19 release notes - Tracking bug for writing the Go 1.19 Release Notes. The latest state on tip can be viewed at https://tip.golang.org/doc/go1.19. When the Go 1.19 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #47694, https://github.com/golang/go/issues/44513, https://github.com/golang/go/issues/40700, https://github.com/golang/go/issues/37419, https://github.com/golang/go/issues/36878, https://github.com/golang/go/issues/17929, https://github.com/golang/go/issues/15810, https://github.com/golang/go/issues/5929, etc.",1,doc write go release notes tracking bug for writing the go release notes the latest state on tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 136868,12736737203.0,IssuesEvent,2020-06-25 17:27:13,golang/go,https://api.github.com/repos/golang/go,closed,crypto/x509: documentation about SSL_CERT_FILE and SSL_CERT_DIR is incorrect,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/Users/xxx/gopath/bin""
GOCACHE=""/Users/xxx/Library/Caches/go-build""
GOENV=""/Users/xxx/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/xxx/gopath""
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=""/usr/local/go/src/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/2b/74fz3jhd4wz4vnbf4z7ywzww0000gp/T/go-build191944931=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I tried to use `SSL_CERT_FILE` to try to override the default system location on macOS. ### What did you expect to see? `x509.SystemCertPool` use my environment variable. ### What did you see instead? It did not. Per `crypto/x509`'s docs: > On UNIX systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations... macOS is very much a UNIX system (afaik it's verified UNIX, or at least was) and at any rate, it's [usually assumed to be included in the `_unix.go` convention](https://github.com/golang/go/issues/20322). At the very least, the docs should specify which operating systems allow the environment variable override. ",1.0,"crypto/x509: documentation about SSL_CERT_FILE and SSL_CERT_DIR is incorrect - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""/Users/xxx/gopath/bin""
GOCACHE=""/Users/xxx/Library/Caches/go-build""
GOENV=""/Users/xxx/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/xxx/gopath""
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=""/usr/local/go/src/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/2b/74fz3jhd4wz4vnbf4z7ywzww0000gp/T/go-build191944931=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? I tried to use `SSL_CERT_FILE` to try to override the default system location on macOS. ### What did you expect to see? `x509.SystemCertPool` use my environment variable. ### What did you see instead? It did not. Per `crypto/x509`'s docs: > On UNIX systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can be used to override the system default locations... macOS is very much a UNIX system (afaik it's verified UNIX, or at least was) and at any rate, it's [usually assumed to be included in the `_unix.go` convention](https://github.com/golang/go/issues/20322). At the very least, the docs should specify which operating systems allow the environment variable override. ",1,crypto documentation about ssl cert file and ssl cert dir is incorrect please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin users xxx gopath bin gocache users xxx library caches go build goenv users xxx library application support go env goexe goflags gohostarch gohostos darwin goinsecure gonoproxy gonosumdb goos darwin gopath users xxx gopath goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod usr local go src go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common 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 i tried to use ssl cert file to try to override the default system location on macos what did you expect to see systemcertpool use my environment variable what did you see instead it did not per crypto s docs on unix systems the environment variables ssl cert file and ssl cert dir can be used to override the system default locations macos is very much a unix system afaik it s verified unix or at least was and at any rate it s at the very least the docs should specify which operating systems allow the environment variable override ,1 49610,7523318375.0,IssuesEvent,2018-04-13 00:15:58,golang/go,https://api.github.com/repos/golang/go,opened,x/build: start using Gerrit hashtags for managing open CLs,Documentation NeedsFix,"In chat with @andybons @FiloSottile @bcmills and @ianlancetaylor yesterday, I proposed we start using Gerrit's ""hashtags"" support, now that our hosted Gerrit supports it (notedb support is active for us) and PolyGerrit (the new web UI) supports it. After discussion, we settled on using tags: ``` so, how about: ""wait-author"", ""wait-release"", ""wait-issue"", ""wait-$PERSON"" where $PERSON is some substring of a name/email in the reviewer set. and if somebody is named ""Issue Release"" and their email is issue@release.com, then you have to use their full email in $PERSON we can mass remove the ""wait-release"" labels when tree opens ``` While triaging today, I found we should also add support for: ``` wait-cl-NNNNN -- this CL is blocked until NNN is resolved ``` I started looking into adding hashtag support to maintner and gopherbot. Tracking that work here, then documenting all this on the wiki. ",1.0,"x/build: start using Gerrit hashtags for managing open CLs - In chat with @andybons @FiloSottile @bcmills and @ianlancetaylor yesterday, I proposed we start using Gerrit's ""hashtags"" support, now that our hosted Gerrit supports it (notedb support is active for us) and PolyGerrit (the new web UI) supports it. After discussion, we settled on using tags: ``` so, how about: ""wait-author"", ""wait-release"", ""wait-issue"", ""wait-$PERSON"" where $PERSON is some substring of a name/email in the reviewer set. and if somebody is named ""Issue Release"" and their email is issue@release.com, then you have to use their full email in $PERSON we can mass remove the ""wait-release"" labels when tree opens ``` While triaging today, I found we should also add support for: ``` wait-cl-NNNNN -- this CL is blocked until NNN is resolved ``` I started looking into adding hashtag support to maintner and gopherbot. Tracking that work here, then documenting all this on the wiki. ",1,x build start using gerrit hashtags for managing open cls in chat with andybons filosottile bcmills and ianlancetaylor yesterday i proposed we start using gerrit s hashtags support now that our hosted gerrit supports it notedb support is active for us and polygerrit the new web ui supports it after discussion we settled on using tags so how about wait author wait release wait issue wait person where person is some substring of a name email in the reviewer set and if somebody is named issue release and their email is issue release com then you have to use their full email in person we can mass remove the wait release labels when tree opens while triaging today i found we should also add support for wait cl nnnnn this cl is blocked until nnn is resolved i started looking into adding hashtag support to maintner and gopherbot tracking that work here then documenting all this on the wiki ,1 139927,12882288436.0,IssuesEvent,2020-07-12 16:12:40,golang/go,https://api.github.com/repos/golang/go,closed,spec: struct can implement an interface with an inherited method but attempting to call that method can cause an unexpected panic,Documentation NeedsInvestigation," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.4 linux/amd64
### Does this issue reproduce with the latest release? I believe go1.14.4 is the latest stable release, so yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/finnb/.cache/go-build""
GOENV=""/home/finnb/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/finnb/go:/home/finnb/git/finnbear/mazean""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/snap/go/5830""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/5830/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build362984802=/tmp/go-build -gno-record-gcc-switches""
### What did you do? **Playground link:** https://play.golang.org/p/Xf3mskprGZV ```go package main import ( ""fmt"" ) type Nilable interface { IsNil() bool } type Child struct { } func (child *Child) IsNil() bool { return child == nil } type Parent struct { Child } func main() { var something Nilable var child *Child something = child fmt.Println(something.IsNil()) var parent *Parent something = parent fmt.Println(something.IsNil()) // Panic here } ``` ### What did you expect to see? ``` true true ``` ### What did you see instead? ``` true panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4919f5] goroutine 1 [running]: main.(*Parent).IsNil(0x0, 0xc0000b6008) :1 +0x5 main.main() /tmp/sandbox080043792/prog.go:36 +0xad ``` I suspect what is happening is that calling `IsNil` on `parent` acts on `parent.Child`, thus dereferencing `Child` from a nil pointer `parent`, but this happens silently. I think one of the following should be done: 1) Assuming my theory is correct, the panic message should be improved to not act as if the issue occurred in the `(*Child) IsNil` receiver but in the intermediate step of accessing `parent.Child` 2) The documentation should be updated to warn about this behavior 3) In the unlikely event that this is a bug in Go, it should be fixed",1.0,"spec: struct can implement an interface with an inherited method but attempting to call that method can cause an unexpected panic - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.4 linux/amd64
### Does this issue reproduce with the latest release? I believe go1.14.4 is the latest stable release, so yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/finnb/.cache/go-build""
GOENV=""/home/finnb/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/finnb/go:/home/finnb/git/finnbear/mazean""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/snap/go/5830""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/snap/go/5830/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build362984802=/tmp/go-build -gno-record-gcc-switches""
### What did you do? **Playground link:** https://play.golang.org/p/Xf3mskprGZV ```go package main import ( ""fmt"" ) type Nilable interface { IsNil() bool } type Child struct { } func (child *Child) IsNil() bool { return child == nil } type Parent struct { Child } func main() { var something Nilable var child *Child something = child fmt.Println(something.IsNil()) var parent *Parent something = parent fmt.Println(something.IsNil()) // Panic here } ``` ### What did you expect to see? ``` true true ``` ### What did you see instead? ``` true panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4919f5] goroutine 1 [running]: main.(*Parent).IsNil(0x0, 0xc0000b6008) :1 +0x5 main.main() /tmp/sandbox080043792/prog.go:36 +0xad ``` I suspect what is happening is that calling `IsNil` on `parent` acts on `parent.Child`, thus dereferencing `Child` from a nil pointer `parent`, but this happens silently. I think one of the following should be done: 1) Assuming my theory is correct, the panic message should be improved to not act as if the issue occurred in the `(*Child) IsNil` receiver but in the intermediate step of accessing `parent.Child` 2) The documentation should be updated to warn about this behavior 3) In the unlikely event that this is a bug in Go, it should be fixed",1,spec struct can implement an interface with an inherited method but attempting to call that method can cause an unexpected panic please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version linux does this issue reproduce with the latest release i believe is the latest stable release so yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home finnb cache go build goenv home finnb config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux gopath home finnb go home finnb git finnbear mazean goprivate goproxy goroot snap go gosumdb sum golang org gotmpdir gotooldir snap go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do playground link go package main import fmt type nilable interface isnil bool type child struct func child child isnil bool return child nil type parent struct child func main var something nilable var child child something child fmt println something isnil var parent parent something parent fmt println something isnil panic here what did you expect to see true true what did you see instead true panic runtime error invalid memory address or nil pointer dereference goroutine main parent isnil main main tmp prog go i suspect what is happening is that calling isnil on parent acts on parent child thus dereferencing child from a nil pointer parent but this happens silently i think one of the following should be done assuming my theory is correct the panic message should be improved to not act as if the issue occurred in the child isnil receiver but in the intermediate step of accessing parent child the documentation should be updated to warn about this behavior in the unlikely event that this is a bug in go it should be fixed,1 24348,5051154438.0,IssuesEvent,2016-12-20 20:58:35,golang/go,https://api.github.com/repos/golang/go,closed,doc: asm.html has no discussion of mips architectures,Documentation NeedsFix,"The sections at the end of the document provide architecture-specific details. There needs to be a section for the MIPS. ",1.0,"doc: asm.html has no discussion of mips architectures - The sections at the end of the document provide architecture-specific details. There needs to be a section for the MIPS. ",1,doc asm html has no discussion of mips architectures the sections at the end of the document provide architecture specific details there needs to be a section for the mips ,1 426862,29667408152.0,IssuesEvent,2023-06-11 00:58:09,golang/go,https://api.github.com/repos/golang/go,reopened,math: Min()/Max() don't agree with builtin min()/max(),Documentation NeedsFix,"### What version of Go are you using (`go version`)? 
https://go.dev/play/?v=gotip
devel go1.21-05293d6b49 Mon Jun 5 14:01:09 2023 +0000
### What did you do? https://go.dev/play/p/Sf_G8Lt9dHy?v=gotip ``` x := math.NaN() y := math.Inf(-1) fmt.Println(min(x, y)) fmt.Println(math.Min(x, y)) ``` Reports different output. ### What did you expect to see? I expected all output to be `NaN`. ### What did you see instead? `min()`/`max()` are returning `NaN` and `math.Min()`/`math.Max()` are returning `-Inf`/`+Inf`. I think the output of the `math` versions is wrong as it should check for `NaN` before the infinities, but I don't have a copy of 754 right now and what min/max is under 754 is special (e.g. see minNum in IEEE 754-2008 vs. minimum & minimumNumber in IEEE 754-2019.",1.0,"math: Min()/Max() don't agree with builtin min()/max() - ### What version of Go are you using (`go version`)? 
https://go.dev/play/?v=gotip
devel go1.21-05293d6b49 Mon Jun 5 14:01:09 2023 +0000
### What did you do? https://go.dev/play/p/Sf_G8Lt9dHy?v=gotip ``` x := math.NaN() y := math.Inf(-1) fmt.Println(min(x, y)) fmt.Println(math.Min(x, y)) ``` Reports different output. ### What did you expect to see? I expected all output to be `NaN`. ### What did you see instead? `min()`/`max()` are returning `NaN` and `math.Min()`/`math.Max()` are returning `-Inf`/`+Inf`. I think the output of the `math` versions is wrong as it should check for `NaN` before the infinities, but I don't have a copy of 754 right now and what min/max is under 754 is special (e.g. see minNum in IEEE 754-2008 vs. minimum & minimumNumber in IEEE 754-2019.",1,math min max don t agree with builtin min max what version of go are you using go version devel mon jun what did you do x math nan y math inf fmt println min x y fmt println math min x y reports different output what did you expect to see i expected all output to be nan what did you see instead min max are returning nan and math min math max are returning inf inf i think the output of the math versions is wrong as it should check for nan before the infinities but i don t have a copy of right now and what min max is under is special e g see minnum in ieee vs minimum minimumnumber in ieee ,1 11042,3454718103.0,IssuesEvent,2015-12-17 16:59:58,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: docs are unclear that tests are run in parallel across packages,Documentation,"If you provide `go test` with more than one package, tests across packages are run in parallel by default (assuming you have more than one CPU). If you have tests across packages that contend for a singular resource (for example, listening on a particular TCP port) you can end up getting unexpected failures. The docs aren't very clear in this respect and I think some improvements can be made to them. This has bit me in the past and just came up again in the Gophers Slack community. In these cases we developers had to go to the `go` command's source code to understand what was happening. In my view, some of the issues: * `go test --help` is equivalent to `go help testflag` rather than `go help test`. I tend to add `--help` by default and so I was seeing the wrong (IMO) help output. * `go help testflag` mentions parallelism with its `-parallel` flag, but this only affects tests within a single package. The presence of this flag implies that tests that don't set `t.Parallel` will never be run in parallel, regardless of where they live. * `go help testflag` does not mention `go help build` at all, and users might not be aware that all the flags there also apply to `go test`, in particular the `-p` flag. (`go help test` does mention build flags, however, which is good.) * `go help build` mentions the `-p` flag, but it only talks about builds. It does not imply that the tests will also be run in parallel. I think most people assume that build and test are separate steps. I think it could also be cleaner that it's talking about packages specifically there. The core issue is that there are multiple levels of parallelism at play, and only one is mentioned in the test help.",1.0,"cmd/go: docs are unclear that tests are run in parallel across packages - If you provide `go test` with more than one package, tests across packages are run in parallel by default (assuming you have more than one CPU). If you have tests across packages that contend for a singular resource (for example, listening on a particular TCP port) you can end up getting unexpected failures. The docs aren't very clear in this respect and I think some improvements can be made to them. This has bit me in the past and just came up again in the Gophers Slack community. In these cases we developers had to go to the `go` command's source code to understand what was happening. In my view, some of the issues: * `go test --help` is equivalent to `go help testflag` rather than `go help test`. I tend to add `--help` by default and so I was seeing the wrong (IMO) help output. * `go help testflag` mentions parallelism with its `-parallel` flag, but this only affects tests within a single package. The presence of this flag implies that tests that don't set `t.Parallel` will never be run in parallel, regardless of where they live. * `go help testflag` does not mention `go help build` at all, and users might not be aware that all the flags there also apply to `go test`, in particular the `-p` flag. (`go help test` does mention build flags, however, which is good.) * `go help build` mentions the `-p` flag, but it only talks about builds. It does not imply that the tests will also be run in parallel. I think most people assume that build and test are separate steps. I think it could also be cleaner that it's talking about packages specifically there. The core issue is that there are multiple levels of parallelism at play, and only one is mentioned in the test help.",1,cmd go docs are unclear that tests are run in parallel across packages if you provide go test with more than one package tests across packages are run in parallel by default assuming you have more than one cpu if you have tests across packages that contend for a singular resource for example listening on a particular tcp port you can end up getting unexpected failures the docs aren t very clear in this respect and i think some improvements can be made to them this has bit me in the past and just came up again in the gophers slack community in these cases we developers had to go to the go command s source code to understand what was happening in my view some of the issues go test help is equivalent to go help testflag rather than go help test i tend to add help by default and so i was seeing the wrong imo help output go help testflag mentions parallelism with its parallel flag but this only affects tests within a single package the presence of this flag implies that tests that don t set t parallel will never be run in parallel regardless of where they live go help testflag does not mention go help build at all and users might not be aware that all the flags there also apply to go test in particular the p flag go help test does mention build flags however which is good go help build mentions the p flag but it only talks about builds it does not imply that the tests will also be run in parallel i think most people assume that build and test are separate steps i think it could also be cleaner that it s talking about packages specifically there the core issue is that there are multiple levels of parallelism at play and only one is mentioned in the test help ,1 33024,6150475087.0,IssuesEvent,2017-06-27 22:42:12,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: intermittent test failure on gonum suite with testing/quick,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.9beta2 (go version devel +eab99a8 Mon Jun 26 21:12:22 2017 +0000 darwin/amd64) I confirmed this bug does not exist in go1.8.3 ### What operating system and processor architecture are you using (`go env`)? brendan:~$ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/brendan/Documents/othergo"" GORACE="""" GOROOT=""/Users/brendan/gover/go"" GOTOOLDIR=""/Users/brendan/gover/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l6/mhj4qjrj4437b_lgfz9pm1rw0000gn/T/go-build536430216=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? ```` go get -u -t gonum.org/v1/gonum/blas/gonum cd $GOPATH/src/gonum.org/v1/gonum/blas/gonum/internal/math32 go test ./... ```` Approximately 1 in every 5 runs, this returns ```` brendan:~/Documents/othergo/src/gonum.org/v1/gonum/blas/gonum/internal/math32$ go test --- FAIL: TestHypot (0.00s) math_test.go:46: #91: failed on input struct { X float32; Y float32 }{X:2.214908e+38, Y:-1.091827e+38} FAIL exit status 1 ```` I ran this ~20 times with go1.8.3, and never saw this test failure (plus, we've been running travis on all of our commits with go1.8.3 and have not seen this failure). The function in question, `math32.Hypot` calls `math32.Sqrt`, which is implemented in assembly. This can be disabled with the ""noasm"" tag, and the failure still occurs. ```` brendan:~/Documents/othergo/src/gonum.org/v1/gonum/blas/gonum/internal/math32$ go test -tags=noasm --- FAIL: TestHypot (0.00s) math_test.go:46: #16: failed on input struct { X float32; Y float32 }{X:-1.917559e+38, Y:-3.838481e+36} FAIL exit status 1 ```` The release notes say there is a change to the `int64` and `uint64` random number generation, but as best as I can tell the source has not changed for `float32` generation. ",1.0,"cmd/compile: intermittent test failure on gonum suite with testing/quick - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.9beta2 (go version devel +eab99a8 Mon Jun 26 21:12:22 2017 +0000 darwin/amd64) I confirmed this bug does not exist in go1.8.3 ### What operating system and processor architecture are you using (`go env`)? brendan:~$ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/brendan/Documents/othergo"" GORACE="""" GOROOT=""/Users/brendan/gover/go"" GOTOOLDIR=""/Users/brendan/gover/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l6/mhj4qjrj4437b_lgfz9pm1rw0000gn/T/go-build536430216=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" PKG_CONFIG=""pkg-config"" ### What did you do? ```` go get -u -t gonum.org/v1/gonum/blas/gonum cd $GOPATH/src/gonum.org/v1/gonum/blas/gonum/internal/math32 go test ./... ```` Approximately 1 in every 5 runs, this returns ```` brendan:~/Documents/othergo/src/gonum.org/v1/gonum/blas/gonum/internal/math32$ go test --- FAIL: TestHypot (0.00s) math_test.go:46: #91: failed on input struct { X float32; Y float32 }{X:2.214908e+38, Y:-1.091827e+38} FAIL exit status 1 ```` I ran this ~20 times with go1.8.3, and never saw this test failure (plus, we've been running travis on all of our commits with go1.8.3 and have not seen this failure). The function in question, `math32.Hypot` calls `math32.Sqrt`, which is implemented in assembly. This can be disabled with the ""noasm"" tag, and the failure still occurs. ```` brendan:~/Documents/othergo/src/gonum.org/v1/gonum/blas/gonum/internal/math32$ go test -tags=noasm --- FAIL: TestHypot (0.00s) math_test.go:46: #16: failed on input struct { X float32; Y float32 }{X:-1.917559e+38, Y:-3.838481e+36} FAIL exit status 1 ```` The release notes say there is a change to the `int64` and `uint64` random number generation, but as best as I can tell the source has not changed for `float32` generation. ",1,cmd compile intermittent test failure on gonum suite with testing quick please answer these questions before submitting your issue thanks what version of go are you using go version go version devel mon jun darwin i confirmed this bug does not exist in what operating system and processor architecture are you using go env brendan go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users brendan documents othergo gorace goroot users brendan gover go gotooldir users brendan gover go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config what did you do go get u t gonum org gonum blas gonum cd gopath src gonum org gonum blas gonum internal go test approximately in every runs this returns brendan documents othergo src gonum org gonum blas gonum internal go test fail testhypot math test go failed on input struct x y x y fail exit status i ran this times with and never saw this test failure plus we ve been running travis on all of our commits with and have not seen this failure the function in question hypot calls sqrt which is implemented in assembly this can be disabled with the noasm tag and the failure still occurs brendan documents othergo src gonum org gonum blas gonum internal go test tags noasm fail testhypot math test go failed on input struct x y x y fail exit status the release notes say there is a change to the and random number generation but as best as i can tell the source has not changed for generation ,1 24919,5111745995.0,IssuesEvent,2017-01-06 08:06:48,golang/go,https://api.github.com/repos/golang/go,opened,doc: explain vendoring,Documentation,"[How to Write Go Code](https://golang.org/doc/code.html#remote) should mention vendoring feature under ""Remote packages"" section. We also need to replace all the mentions of GO15VENDOREXPERIMENT on the wiki with the proper official document.",1.0,"doc: explain vendoring - [How to Write Go Code](https://golang.org/doc/code.html#remote) should mention vendoring feature under ""Remote packages"" section. We also need to replace all the mentions of GO15VENDOREXPERIMENT on the wiki with the proper official document.",1,doc explain vendoring should mention vendoring feature under remote packages section we also need to replace all the mentions of on the wiki with the proper official document ,1 34264,6307134167.0,IssuesEvent,2017-07-21 23:26:50,golang/go,https://api.github.com/repos/golang/go,closed,doc: add VS Code editor guide,DevExp Documentation,"This is a tracking bug for https://github.com/golang/go/issues/20398 VSCode Go. The brief info card for VSCode Go: ``` VSCode Go https://github.com/Microsoft/vscode-go An extension for VS Code which provides support for the Go language. Editing Formatting on save (gofmt), automatic imports, identifier completion, vetting on save, linting on save. Navigation Godoc lookup, jumping to definition and referrers, looking up for interface implementations, searching for callers and callees. Testing and Debugging Running package tests, running single test case, generating test cases from package/file/function, Delve debugger integration. ``` The screencasts to be done: - Linting on save - Searching for callers and callees - Running package tests - Generating test cases",1.0,"doc: add VS Code editor guide - This is a tracking bug for https://github.com/golang/go/issues/20398 VSCode Go. The brief info card for VSCode Go: ``` VSCode Go https://github.com/Microsoft/vscode-go An extension for VS Code which provides support for the Go language. Editing Formatting on save (gofmt), automatic imports, identifier completion, vetting on save, linting on save. Navigation Godoc lookup, jumping to definition and referrers, looking up for interface implementations, searching for callers and callees. Testing and Debugging Running package tests, running single test case, generating test cases from package/file/function, Delve debugger integration. ``` The screencasts to be done: - Linting on save - Searching for callers and callees - Running package tests - Generating test cases",1,doc add vs code editor guide this is a tracking bug for vscode go the brief info card for vscode go vscode go an extension for vs code which provides support for the go language editing formatting on save gofmt automatic imports identifier completion vetting on save linting on save navigation godoc lookup jumping to definition and referrers looking up for interface implementations searching for callers and callees testing and debugging running package tests running single test case generating test cases from package file function delve debugger integration the screencasts to be done linting on save searching for callers and callees running package tests generating test cases,1 61738,8554322590.0,IssuesEvent,2018-11-08 05:42:37,golang/go,https://api.github.com/repos/golang/go,closed,time: document that a marshaled time does not include location name,Documentation Proposal Proposal-Accepted help wanted,"As is, `time.Time` is not transmittable/storable on its own where it will preserve its location. All of the Marshal/Unmarshal implementations and all the supported string formats encode only the offset or the timezone abbreviation. When parsed or unmarshalled, you often end up with a `time.Time` in a fixed offset, rather than the original location. In particular, this can lead to unexpected results when performing some operations around Daylight Savings Time because the fixed offset `time.Time` may or may not observe DST when the original location-laden `time.Time` would have. Depending on the server location, it's also possible to end up applying DST when it shouldn't apply because of `time.Parse`'s behavior to use `time.Local` if the local offset matches the parsed timestamp. As a hallmark example of the problem here is to ask: what month will it be if you add 2840 hours to the reference time used for string formatting? See: https://play.golang.org/p/XQiDRKpKtSa Overall, this subtlety breaks assumptions that encoded timestamps convey all the information on the original `time.Time`, and that a decoded `time.Time` will behave consistently no matter where it's decoded. While a workaround is possible by always separately storing/transmitting the location string in addition to the timestamp, the time package could make that more transparent or at least alert users that the encode/decode may behave unexpectedly with regard to precise timezone rules. The proposal is to do one or more of the following options. Note that as the author here, my current thinking is option 2 plus option 5 would be the best way forward, but I've listed more possibilities for completeness. 1. Add the IANA location to what `MarshalBinary` and `UnmarshalBinary` do This will allow `gob` to losslessly transmit timestamps that will behave the same after encoding/decoding. There are a couple considerations that may rule out this idea: - The change might be backward incompatible. I'm not sure if there are Go programs relying on the fact that currently the encoding format results in fixed-offset times after decode. - The ""improved"" parser would still need to handle encoded data from before the change - The IANA information might not be useful on systems that don't have tzdata (noting #21881) 2. Add a Format/Parse directive that includes the IANA location string This idea is less transparent than the Binary/Gob approach because it requires specifically using a format that includes location. This means it's backward compatible and introduces minimal additional API surface. This possibility still must tackle the problem of how to proceed on systems without available tzdata. 3. Add an exported struct field to `time.Time` to toggle encoding behavior Because the current JSON/text encoding mechanisms for `time.Time` specify RFC3339, they cannot be changed outright to include the actual location. However, a field could be added to time.Time to alter the encoding behavior. Because the default state of this field could be to encode as the existing format, backward compatibility would be preserved. The decoding routines would need to account for all possible formats and could set that field as necessary. The two major downsides to this approach I can think of: - Additional memory required by `time.Time` objects - That `==` comparisons would include this field, which seems beyond its intended purpose 4. Break compatibility in Go2 and include the IANA location in all `Marshal`/`Unmarshal` encodings The big benefit here would be to make `time.Time`, as an implementation of package `encoding`'s interfaces, to be more true to those interfaces. While package `encoding` doesn't currently specify whether or not implementations must _completely_ represent the receiver's contents, one might assume they do since generally the process is often treated such that `x = decode(encode(x))`. 5. Document this behavior It's worth warning people that existing encoding methods do not preserve the full location information and that if the program needs to do calendrical operations which may be affected by changes like DST, to transmit/store both the encoded `time.Time` and its location separately. In particular, since the docs don't specify any format or specifics about the data, one might assume the binary/Gob encoding preserves the full state of the `time.Time`, when it actually doesn't. While technically this fact is implied for the JSON/text encodings, it's probably a common misconception that the offset in RFC3339 adequately represents location via the offset. edit: added some formatting",1.0,"time: document that a marshaled time does not include location name - As is, `time.Time` is not transmittable/storable on its own where it will preserve its location. All of the Marshal/Unmarshal implementations and all the supported string formats encode only the offset or the timezone abbreviation. When parsed or unmarshalled, you often end up with a `time.Time` in a fixed offset, rather than the original location. In particular, this can lead to unexpected results when performing some operations around Daylight Savings Time because the fixed offset `time.Time` may or may not observe DST when the original location-laden `time.Time` would have. Depending on the server location, it's also possible to end up applying DST when it shouldn't apply because of `time.Parse`'s behavior to use `time.Local` if the local offset matches the parsed timestamp. As a hallmark example of the problem here is to ask: what month will it be if you add 2840 hours to the reference time used for string formatting? See: https://play.golang.org/p/XQiDRKpKtSa Overall, this subtlety breaks assumptions that encoded timestamps convey all the information on the original `time.Time`, and that a decoded `time.Time` will behave consistently no matter where it's decoded. While a workaround is possible by always separately storing/transmitting the location string in addition to the timestamp, the time package could make that more transparent or at least alert users that the encode/decode may behave unexpectedly with regard to precise timezone rules. The proposal is to do one or more of the following options. Note that as the author here, my current thinking is option 2 plus option 5 would be the best way forward, but I've listed more possibilities for completeness. 1. Add the IANA location to what `MarshalBinary` and `UnmarshalBinary` do This will allow `gob` to losslessly transmit timestamps that will behave the same after encoding/decoding. There are a couple considerations that may rule out this idea: - The change might be backward incompatible. I'm not sure if there are Go programs relying on the fact that currently the encoding format results in fixed-offset times after decode. - The ""improved"" parser would still need to handle encoded data from before the change - The IANA information might not be useful on systems that don't have tzdata (noting #21881) 2. Add a Format/Parse directive that includes the IANA location string This idea is less transparent than the Binary/Gob approach because it requires specifically using a format that includes location. This means it's backward compatible and introduces minimal additional API surface. This possibility still must tackle the problem of how to proceed on systems without available tzdata. 3. Add an exported struct field to `time.Time` to toggle encoding behavior Because the current JSON/text encoding mechanisms for `time.Time` specify RFC3339, they cannot be changed outright to include the actual location. However, a field could be added to time.Time to alter the encoding behavior. Because the default state of this field could be to encode as the existing format, backward compatibility would be preserved. The decoding routines would need to account for all possible formats and could set that field as necessary. The two major downsides to this approach I can think of: - Additional memory required by `time.Time` objects - That `==` comparisons would include this field, which seems beyond its intended purpose 4. Break compatibility in Go2 and include the IANA location in all `Marshal`/`Unmarshal` encodings The big benefit here would be to make `time.Time`, as an implementation of package `encoding`'s interfaces, to be more true to those interfaces. While package `encoding` doesn't currently specify whether or not implementations must _completely_ represent the receiver's contents, one might assume they do since generally the process is often treated such that `x = decode(encode(x))`. 5. Document this behavior It's worth warning people that existing encoding methods do not preserve the full location information and that if the program needs to do calendrical operations which may be affected by changes like DST, to transmit/store both the encoded `time.Time` and its location separately. In particular, since the docs don't specify any format or specifics about the data, one might assume the binary/Gob encoding preserves the full state of the `time.Time`, when it actually doesn't. While technically this fact is implied for the JSON/text encodings, it's probably a common misconception that the offset in RFC3339 adequately represents location via the offset. edit: added some formatting",1,time document that a marshaled time does not include location name as is time time is not transmittable storable on its own where it will preserve its location all of the marshal unmarshal implementations and all the supported string formats encode only the offset or the timezone abbreviation when parsed or unmarshalled you often end up with a time time in a fixed offset rather than the original location in particular this can lead to unexpected results when performing some operations around daylight savings time because the fixed offset time time may or may not observe dst when the original location laden time time would have depending on the server location it s also possible to end up applying dst when it shouldn t apply because of time parse s behavior to use time local if the local offset matches the parsed timestamp as a hallmark example of the problem here is to ask what month will it be if you add hours to the reference time used for string formatting see overall this subtlety breaks assumptions that encoded timestamps convey all the information on the original time time and that a decoded time time will behave consistently no matter where it s decoded while a workaround is possible by always separately storing transmitting the location string in addition to the timestamp the time package could make that more transparent or at least alert users that the encode decode may behave unexpectedly with regard to precise timezone rules the proposal is to do one or more of the following options note that as the author here my current thinking is option plus option would be the best way forward but i ve listed more possibilities for completeness add the iana location to what marshalbinary and unmarshalbinary do this will allow gob to losslessly transmit timestamps that will behave the same after encoding decoding there are a couple considerations that may rule out this idea the change might be backward incompatible i m not sure if there are go programs relying on the fact that currently the encoding format results in fixed offset times after decode the improved parser would still need to handle encoded data from before the change the iana information might not be useful on systems that don t have tzdata noting add a format parse directive that includes the iana location string this idea is less transparent than the binary gob approach because it requires specifically using a format that includes location this means it s backward compatible and introduces minimal additional api surface this possibility still must tackle the problem of how to proceed on systems without available tzdata add an exported struct field to time time to toggle encoding behavior because the current json text encoding mechanisms for time time specify they cannot be changed outright to include the actual location however a field could be added to time time to alter the encoding behavior because the default state of this field could be to encode as the existing format backward compatibility would be preserved the decoding routines would need to account for all possible formats and could set that field as necessary the two major downsides to this approach i can think of additional memory required by time time objects that comparisons would include this field which seems beyond its intended purpose break compatibility in and include the iana location in all marshal unmarshal encodings the big benefit here would be to make time time as an implementation of package encoding s interfaces to be more true to those interfaces while package encoding doesn t currently specify whether or not implementations must completely represent the receiver s contents one might assume they do since generally the process is often treated such that x decode encode x document this behavior it s worth warning people that existing encoding methods do not preserve the full location information and that if the program needs to do calendrical operations which may be affected by changes like dst to transmit store both the encoded time time and its location separately in particular since the docs don t specify any format or specifics about the data one might assume the binary gob encoding preserves the full state of the time time when it actually doesn t while technically this fact is implied for the json text encodings it s probably a common misconception that the offset in adequately represents location via the offset edit added some formatting,1 20058,4488308326.0,IssuesEvent,2016-08-30 06:40:11,golang/go,https://api.github.com/repos/golang/go,opened,doc: document assembly calling convention,Documentation,"We should probably specify the Go calling convention in doc/asm.html, at least to a degree. Might be especially useful as a reference when we get around to changing it. @cherrymui @dr2chase @nigeltao ",1.0,"doc: document assembly calling convention - We should probably specify the Go calling convention in doc/asm.html, at least to a degree. Might be especially useful as a reference when we get around to changing it. @cherrymui @dr2chase @nigeltao ",1,doc document assembly calling convention we should probably specify the go calling convention in doc asm html at least to a degree might be especially useful as a reference when we get around to changing it cherrymui nigeltao ,1 54912,7930420940.0,IssuesEvent,2018-07-06 18:46:41,golang/go,https://api.github.com/repos/golang/go,closed,doc: update the Go faq about versioning,Documentation,"At the moment the Go faq says : https://golang.org/doc/faq#get_version > Work is underway on an experimental package management tool, dep, to learn more about how tooling can help package management. More information can be found in the dep FAQ. I believe it should be updated to mention `vgo`",1.0,"doc: update the Go faq about versioning - At the moment the Go faq says : https://golang.org/doc/faq#get_version > Work is underway on an experimental package management tool, dep, to learn more about how tooling can help package management. More information can be found in the dep FAQ. I believe it should be updated to mention `vgo`",1,doc update the go faq about versioning at the moment the go faq says work is underway on an experimental package management tool dep to learn more about how tooling can help package management more information can be found in the dep faq i believe it should be updated to mention vgo ,1 39209,6730303586.0,IssuesEvent,2017-10-18 00:01:21,golang/go,https://api.github.com/repos/golang/go,closed,"spec: document package unsafe's path is ""unsafe""",Documentation NeedsFix,"The Go spec mentions package unsafe's package name is `unsafe`, but it never documents the package path that users can import to use it. Intuitively it's `""unsafe""`, but as package paths are formally distinct from package names, we should still explicitly document that.",1.0,"spec: document package unsafe's path is ""unsafe"" - The Go spec mentions package unsafe's package name is `unsafe`, but it never documents the package path that users can import to use it. Intuitively it's `""unsafe""`, but as package paths are formally distinct from package names, we should still explicitly document that.",1,spec document package unsafe s path is unsafe the go spec mentions package unsafe s package name is unsafe but it never documents the package path that users can import to use it intuitively it s unsafe but as package paths are formally distinct from package names we should still explicitly document that ,1 28991,5560226550.0,IssuesEvent,2017-03-24 18:52:48,golang/go,https://api.github.com/repos/golang/go,closed,spec: does not cover the case where a map composite literal contains multiple copies of the same key at runtime,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? [November 18, 2016](https://golang.org/ref/spec) ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? The Go spec states ""For map literals, all elements must have a key. It is an error to specify multiple elements with the same field name or constant key value."", however, it is silent as to what happens whem multiple elements with the same non-constant key value are present, as in this link: https://play.golang.org/p/53kQ9rF8a2 As you can see, it appears that the later one wins in this example, but I don't know if this always holds.",1.0,"spec: does not cover the case where a map composite literal contains multiple copies of the same key at runtime - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? [November 18, 2016](https://golang.org/ref/spec) ### What operating system and processor architecture are you using (`go env`)? N/A ### What did you do? The Go spec states ""For map literals, all elements must have a key. It is an error to specify multiple elements with the same field name or constant key value."", however, it is silent as to what happens whem multiple elements with the same non-constant key value are present, as in this link: https://play.golang.org/p/53kQ9rF8a2 As you can see, it appears that the later one wins in this example, but I don't know if this always holds.",1,spec does not cover the case where a map composite literal contains multiple copies of the same key at runtime please answer these questions before submitting your issue thanks what version of go are you using go version what operating system and processor architecture are you using go env n a what did you do the go spec states for map literals all elements must have a key it is an error to specify multiple elements with the same field name or constant key value however it is silent as to what happens whem multiple elements with the same non constant key value are present as in this link as you can see it appears that the later one wins in this example but i don t know if this always holds ,1 89067,25572078865.0,IssuesEvent,2022-11-30 18:33:00,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/relui: create proof of concept for release automation,Builders NeedsFix,"As part of an effort to improve the reliability and reduce the complexity of Go releases, we should automate more of the release process. A possible solution is a hosted release management tool (relui) that is responsible for the scheduling and operating of the release, much as `releasebot` handles this process on the CLI. We can improve the observability of the process by using a persistent web UI for coordinating releases. As a proof of concept, relui acts as the coordinator (and currently the task executor) for release tasks. ### Rough Architecture For the proof of concept, there will be a single application for both starting and running workflows. However, careful API boundaries should be maintained between the scheduler process and the runner processes to allow for separation in the future. In general, the runner process should only know how to execute specific tasks without broader context, and report back to the scheduler. Tasks should have an associated type, and the runner should decide whether or not it has an implementation for a given task type. Tasks, or BuildableTasks, have a shared configuration. All tasks have a type, a name, an optional task name to depend on, and an artifact URL. If a task depends on another named task, it will be provided with that task's artifact URL upon starting. Finally, workflows should be described through a configuration, in order to allow us to share steps between workflows, and separate concerns between the implementation and the definition of all steps that must be completed for a release. This is especially important for steps that may need to run on different platforms (outside of our tooling on GCP, such as the signing process). ### Rough initial workflow for a local workstation release: **Clone repo @ ref** In: - Repo - Ref Out: - Tarball of Go src - Tarball URI **Run make.bash** In: - Tarball URI of Go Src Out: - Tarball URI of Go src after make **Build Race Detector** In: - Tarball URI of Go src after make Out: - Tarball URI of Go src after race build **Clean (version.cache, pkg/bootstrap, race for other GOOS/GOARCH, pkg/GOOS_GOOARCH/cmd)** In: - Tarball URI of Go src after race build Out: - Tarball URI of Go src after cleanup **Run all.bash** In: - Tarball URI of Go Src after cleanup Out: - Tarball URI of Go src after all.bash **Finalize** In: - Tarball URI of Go Src after cleanup (not all.bash) Out: - Tarball URI of binary release ## Tasks (remaining as of 2020-10-05) - [ ] Subscribe to a PubSub Topic - [ ] Publish status upon accepting a task - [ ] Run FetchGitSource task - [ ] Create Status API - [ ] Datastore Integration ### relworker #### (bootstrap worker) Subscribe to a PubSub Topic A worker can connect to PubSub and subscribe to the configured topic. Messages should be subscribed to using the [Receive API](https://pkg.go.dev/cloud.google.com/go/pubsub#Subscription.Receive), which handles spawning goroutines for handling the message, as well as auto-extending the Ack deadline while a message is being processed. For now, we can just log that we got the message,can handle it, and Ack it. See: https://pkg.go.dev/cloud.google.com/go/pubsub#Subscription.Receive #### Publish status on accepting a task When the worker picks up a task, it should update the status of the task in relui as started. #### Run FetchGitSource task The FetchGitSource task should fetch the specified Git repo at the configured ref. The source should be tarred, record the artifact URL to relui, and mark the task as complete. On gitiles, there is an +archive URL for this task: Web: https://go.googlesource.com/go/+archive/refs/heads/master Archive: https://go.googlesource.com/go/+archive/refs/heads/master.tar.gz #### Handle non-transient errors on FetchGitSource If a permanent error occurs when executing a task, the message should be ACK’d to prevent retries, and a terminal status for the task should be reported back to relui. ### relui #### Create Status API (gRPC server) A worker can communicate the status of a task back to the coordinator as it progresses on a task. The initial API should at least be able to mark a task as started. 1. Host gRPC and HTTPS on the same port (with some caveats) 1. See caveats here: https://github.com/grpc/grpc-go/issues/2662#issuecomment-468497692 2. Host gRPC on same service but different port as HTTPS relui web 3. Use separate instances of relui for gRPC #### Datastore integration Currently, relui commits state to disk. It should have a persistent database for handling multiple instances, like Datastore. /cc @dmitshur @cagedmantis @andybons ",1.0,"x/build/cmd/relui: create proof of concept for release automation - As part of an effort to improve the reliability and reduce the complexity of Go releases, we should automate more of the release process. A possible solution is a hosted release management tool (relui) that is responsible for the scheduling and operating of the release, much as `releasebot` handles this process on the CLI. We can improve the observability of the process by using a persistent web UI for coordinating releases. As a proof of concept, relui acts as the coordinator (and currently the task executor) for release tasks. ### Rough Architecture For the proof of concept, there will be a single application for both starting and running workflows. However, careful API boundaries should be maintained between the scheduler process and the runner processes to allow for separation in the future. In general, the runner process should only know how to execute specific tasks without broader context, and report back to the scheduler. Tasks should have an associated type, and the runner should decide whether or not it has an implementation for a given task type. Tasks, or BuildableTasks, have a shared configuration. All tasks have a type, a name, an optional task name to depend on, and an artifact URL. If a task depends on another named task, it will be provided with that task's artifact URL upon starting. Finally, workflows should be described through a configuration, in order to allow us to share steps between workflows, and separate concerns between the implementation and the definition of all steps that must be completed for a release. This is especially important for steps that may need to run on different platforms (outside of our tooling on GCP, such as the signing process). ### Rough initial workflow for a local workstation release: **Clone repo @ ref** In: - Repo - Ref Out: - Tarball of Go src - Tarball URI **Run make.bash** In: - Tarball URI of Go Src Out: - Tarball URI of Go src after make **Build Race Detector** In: - Tarball URI of Go src after make Out: - Tarball URI of Go src after race build **Clean (version.cache, pkg/bootstrap, race for other GOOS/GOARCH, pkg/GOOS_GOOARCH/cmd)** In: - Tarball URI of Go src after race build Out: - Tarball URI of Go src after cleanup **Run all.bash** In: - Tarball URI of Go Src after cleanup Out: - Tarball URI of Go src after all.bash **Finalize** In: - Tarball URI of Go Src after cleanup (not all.bash) Out: - Tarball URI of binary release ## Tasks (remaining as of 2020-10-05) - [ ] Subscribe to a PubSub Topic - [ ] Publish status upon accepting a task - [ ] Run FetchGitSource task - [ ] Create Status API - [ ] Datastore Integration ### relworker #### (bootstrap worker) Subscribe to a PubSub Topic A worker can connect to PubSub and subscribe to the configured topic. Messages should be subscribed to using the [Receive API](https://pkg.go.dev/cloud.google.com/go/pubsub#Subscription.Receive), which handles spawning goroutines for handling the message, as well as auto-extending the Ack deadline while a message is being processed. For now, we can just log that we got the message,can handle it, and Ack it. See: https://pkg.go.dev/cloud.google.com/go/pubsub#Subscription.Receive #### Publish status on accepting a task When the worker picks up a task, it should update the status of the task in relui as started. #### Run FetchGitSource task The FetchGitSource task should fetch the specified Git repo at the configured ref. The source should be tarred, record the artifact URL to relui, and mark the task as complete. On gitiles, there is an +archive URL for this task: Web: https://go.googlesource.com/go/+archive/refs/heads/master Archive: https://go.googlesource.com/go/+archive/refs/heads/master.tar.gz #### Handle non-transient errors on FetchGitSource If a permanent error occurs when executing a task, the message should be ACK’d to prevent retries, and a terminal status for the task should be reported back to relui. ### relui #### Create Status API (gRPC server) A worker can communicate the status of a task back to the coordinator as it progresses on a task. The initial API should at least be able to mark a task as started. 1. Host gRPC and HTTPS on the same port (with some caveats) 1. See caveats here: https://github.com/grpc/grpc-go/issues/2662#issuecomment-468497692 2. Host gRPC on same service but different port as HTTPS relui web 3. Use separate instances of relui for gRPC #### Datastore integration Currently, relui commits state to disk. It should have a persistent database for handling multiple instances, like Datastore. /cc @dmitshur @cagedmantis @andybons ",0,x build cmd relui create proof of concept for release automation as part of an effort to improve the reliability and reduce the complexity of go releases we should automate more of the release process a possible solution is a hosted release management tool relui that is responsible for the scheduling and operating of the release much as releasebot handles this process on the cli we can improve the observability of the process by using a persistent web ui for coordinating releases as a proof of concept relui acts as the coordinator and currently the task executor for release tasks rough architecture for the proof of concept there will be a single application for both starting and running workflows however careful api boundaries should be maintained between the scheduler process and the runner processes to allow for separation in the future in general the runner process should only know how to execute specific tasks without broader context and report back to the scheduler tasks should have an associated type and the runner should decide whether or not it has an implementation for a given task type tasks or buildabletasks have a shared configuration all tasks have a type a name an optional task name to depend on and an artifact url if a task depends on another named task it will be provided with that task s artifact url upon starting finally workflows should be described through a configuration in order to allow us to share steps between workflows and separate concerns between the implementation and the definition of all steps that must be completed for a release this is especially important for steps that may need to run on different platforms outside of our tooling on gcp such as the signing process rough initial workflow for a local workstation release clone repo ref in repo ref out tarball of go src tarball uri run make bash in tarball uri of go src out tarball uri of go src after make build race detector in tarball uri of go src after make out tarball uri of go src after race build clean version cache pkg bootstrap race for other goos goarch pkg goos gooarch cmd in tarball uri of go src after race build out tarball uri of go src after cleanup run all bash in tarball uri of go src after cleanup out tarball uri of go src after all bash finalize in tarball uri of go src after cleanup not all bash out tarball uri of binary release tasks remaining as of subscribe to a pubsub topic publish status upon accepting a task run fetchgitsource task create status api datastore integration relworker bootstrap worker subscribe to a pubsub topic a worker can connect to pubsub and subscribe to the configured topic messages should be subscribed to using the which handles spawning goroutines for handling the message as well as auto extending the ack deadline while a message is being processed for now we can just log that we got the message can handle it and ack it see publish status on accepting a task when the worker picks up a task it should update the status of the task in relui as started run fetchgitsource task the fetchgitsource task should fetch the specified git repo at the configured ref the source should be tarred record the artifact url to relui and mark the task as complete on gitiles there is an archive url for this task web archive handle non transient errors on fetchgitsource if a permanent error occurs when executing a task the message should be ack’d to prevent retries and a terminal status for the task should be reported back to relui relui create status api grpc server a worker can communicate the status of a task back to the coordinator as it progresses on a task the initial api should at least be able to mark a task as started host grpc and https on the same port with some caveats see caveats here host grpc on same service but different port as https relui web use separate instances of relui for grpc datastore integration currently relui commits state to disk it should have a persistent database for handling multiple instances like datastore cc dmitshur cagedmantis andybons ,0 45100,7158495178.0,IssuesEvent,2018-01-27 01:13:00,golang/go,https://api.github.com/repos/golang/go,closed,os: document that StartProcess inherits the caller's thread state,Documentation,"One of the new features of the Go 1.10 runtime is that `LockOSThread` can be used to reliably modify OS thread state. One of the main points of doing this was to make it possible to start a new process with a modified thread state, but right now we don't document that new processes created with, e.g., `os.StartProcess` will actually inherit the caller's thread state. This has [led to confusion](https://github.com/golang/go/issues/20395#issuecomment-360810662) and we should document this.",1.0,"os: document that StartProcess inherits the caller's thread state - One of the new features of the Go 1.10 runtime is that `LockOSThread` can be used to reliably modify OS thread state. One of the main points of doing this was to make it possible to start a new process with a modified thread state, but right now we don't document that new processes created with, e.g., `os.StartProcess` will actually inherit the caller's thread state. This has [led to confusion](https://github.com/golang/go/issues/20395#issuecomment-360810662) and we should document this.",1,os document that startprocess inherits the caller s thread state one of the new features of the go runtime is that lockosthread can be used to reliably modify os thread state one of the main points of doing this was to make it possible to start a new process with a modified thread state but right now we don t document that new processes created with e g os startprocess will actually inherit the caller s thread state this has and we should document this ,1 219252,16823886235.0,IssuesEvent,2021-06-17 15:58:56,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: on malformed ""go mod edit -go"", suggest current version of go, not hardcoded 1.12",Documentation NeedsFix help wanted modules," ### What version of Go are you using (`go version`)? 
$ go version
go version devel +0f897f916a Tue May 28 02:52:39 2019 +0000 darwin/amd64
### Does this issue reproduce with the latest release? n/a, `go mod edit` suggests `-go 1.12` on go1.12.5. ### What did you do? I wasn't sure if there was a way to `go mod edit` to put the `go 1.12` directive in the ""right"" place in 1.12, prior to #31960 on tip, so I ran with a garbage argument to `-go`. This command has the same output in 1.12 and tip: ``` $ go mod edit -go=x go mod: invalid -go option; expecting something like ""-go 1.12"" ``` ### What did you expect to see? I expected the output to suggest `-go 1.13` when running with tip. ### What did you see instead? It suggested `-go 1.12`, which seems odd given that I am running what is going to be 1.13. I suppose there's an argument to suggest 1.12 as a ""downgrading"" case when go.mod already provides `go 1.13`, but the argument to use `-go 1.13` to upgrade from a `go 1.12` in go.mod seems just as valid.",1.0,"cmd/go: on malformed ""go mod edit -go"", suggest current version of go, not hardcoded 1.12 - ### What version of Go are you using (`go version`)? 
$ go version
go version devel +0f897f916a Tue May 28 02:52:39 2019 +0000 darwin/amd64
### Does this issue reproduce with the latest release? n/a, `go mod edit` suggests `-go 1.12` on go1.12.5. ### What did you do? I wasn't sure if there was a way to `go mod edit` to put the `go 1.12` directive in the ""right"" place in 1.12, prior to #31960 on tip, so I ran with a garbage argument to `-go`. This command has the same output in 1.12 and tip: ``` $ go mod edit -go=x go mod: invalid -go option; expecting something like ""-go 1.12"" ``` ### What did you expect to see? I expected the output to suggest `-go 1.13` when running with tip. ### What did you see instead? It suggested `-go 1.12`, which seems odd given that I am running what is going to be 1.13. I suppose there's an argument to suggest 1.12 as a ""downgrading"" case when go.mod already provides `go 1.13`, but the argument to use `-go 1.13` to upgrade from a `go 1.12` in go.mod seems just as valid.",1,cmd go on malformed go mod edit go suggest current version of go not hardcoded what version of go are you using go version go version go version devel tue may darwin does this issue reproduce with the latest release n a go mod edit suggests go on 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 i wasn t sure if there was a way to go mod edit to put the go directive in the right place in prior to on tip so i ran with a garbage argument to go this command has the same output in and tip go mod edit go x go mod invalid go option expecting something like go what did you expect to see i expected the output to suggest go when running with tip what did you see instead it suggested go which seems odd given that i am running what is going to be i suppose there s an argument to suggest as a downgrading case when go mod already provides go but the argument to use go to upgrade from a go in go mod seems just as valid ,1 20660,6910073803.0,IssuesEvent,2017-11-28 00:11:15,golang/go,https://api.github.com/repos/golang/go,opened,x/build: FreeBSD images don't shut down nicely,Builders HelpWanted OS-FreeBSD,"I noticed while testing my images for #19303 and #22854 that our FreeBSD images (at least 10.3) don't have shutdown in their path: ``` 2017/11/28 00:06:26 About to hit http://10.240.0.22 to see if buildlet is up yet... 2017/11/28 00:06:27 buildlet probe: 200 OK 2017/11/28 00:06:27 WorkDir: /tmp/workdir, 2017/11/28 00:06:27 done. 2017/11/28 00:06:27 SERIAL: 2017/11/28 00:06:27 Halting in 1 second. 2017/11/28 00:06:28 SERIAL: 2017/11/28 00:06:28 Halting machine. 2017/11/28 00:06:28 Shutdown: exec: ""shutdown"": executable file not found in $PATH 2017/11/28 00:06:28 Ending buildlet process post-halt eval: poweroff: not found Configuring syscons: blanktime. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Tue Nov 28 00:06:28 UTC 2017 FreeBSD/amd64 (buildlet) (ttyu0) login: ``` The cmd/buildlet code is trying to do: ```go case ""freebsd"": // Power off (-p), via halt (-o), now. err = exec.Command(""shutdown"", ""-p"", ""-o"", ""now"").Run() ``` Maybe it needs an explicit path. /cc @paulzhol ",1.0,"x/build: FreeBSD images don't shut down nicely - I noticed while testing my images for #19303 and #22854 that our FreeBSD images (at least 10.3) don't have shutdown in their path: ``` 2017/11/28 00:06:26 About to hit http://10.240.0.22 to see if buildlet is up yet... 2017/11/28 00:06:27 buildlet probe: 200 OK 2017/11/28 00:06:27 WorkDir: /tmp/workdir, 2017/11/28 00:06:27 done. 2017/11/28 00:06:27 SERIAL: 2017/11/28 00:06:27 Halting in 1 second. 2017/11/28 00:06:28 SERIAL: 2017/11/28 00:06:28 Halting machine. 2017/11/28 00:06:28 Shutdown: exec: ""shutdown"": executable file not found in $PATH 2017/11/28 00:06:28 Ending buildlet process post-halt eval: poweroff: not found Configuring syscons: blanktime. Starting sendmail_submit. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Tue Nov 28 00:06:28 UTC 2017 FreeBSD/amd64 (buildlet) (ttyu0) login: ``` The cmd/buildlet code is trying to do: ```go case ""freebsd"": // Power off (-p), via halt (-o), now. err = exec.Command(""shutdown"", ""-p"", ""-o"", ""now"").Run() ``` Maybe it needs an explicit path. /cc @paulzhol ",0,x build freebsd images don t shut down nicely i noticed while testing my images for and that our freebsd images at least don t have shutdown in their path about to hit to see if buildlet is up yet buildlet probe ok workdir tmp workdir done serial halting in second serial halting machine shutdown exec shutdown executable file not found in path ending buildlet process post halt eval poweroff not found configuring syscons blanktime starting sendmail submit starting sendmail msp queue starting cron starting background file system checks in seconds tue nov utc freebsd buildlet login the cmd buildlet code is trying to do go case freebsd power off p via halt o now err exec command shutdown p o now run maybe it needs an explicit path cc paulzhol ,0 253958,19183445048.0,IssuesEvent,2021-12-04 20:09:52,golang/go,https://api.github.com/repos/golang/go,opened,net: Resolver.LookupSRV first result param not documented well,Documentation,"https://pkg.go.dev/net#Resolver.LookupSRV has signature: ```go func (r *Resolver) LookupSRV(ctx context.Context, service, proto, name string) (string, []*SRV, error) ``` ... but the docs don't make it super clear what that `string` result is. There's a hint in the docs: > LookupSRV constructs the DNS name to look up following RFC 2782. That is, it looks up _service._proto.name. But that makes it sound like it's an implementation detail, not that the first result is indeed that DNS name. ",1.0,"net: Resolver.LookupSRV first result param not documented well - https://pkg.go.dev/net#Resolver.LookupSRV has signature: ```go func (r *Resolver) LookupSRV(ctx context.Context, service, proto, name string) (string, []*SRV, error) ``` ... but the docs don't make it super clear what that `string` result is. There's a hint in the docs: > LookupSRV constructs the DNS name to look up following RFC 2782. That is, it looks up _service._proto.name. But that makes it sound like it's an implementation detail, not that the first result is indeed that DNS name. ",1,net resolver lookupsrv first result param not documented well has signature go func r resolver lookupsrv ctx context context service proto name string string srv error but the docs don t make it super clear what that string result is there s a hint in the docs lookupsrv constructs the dns name to look up following rfc that is it looks up service proto name but that makes it sound like it s an implementation detail not that the first result is indeed that dns name ,1 28663,5530434699.0,IssuesEvent,2017-03-21 02:34:14,golang/go,https://api.github.com/repos/golang/go,closed,doc: source install page should mention make.bash again,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? None installed yet (1.4 bootstrap) ### What operating system and processor architecture are you using (`go env`)? OSX 10.11.6 ### What did you do? Try to build 1.4 bootstrap installation ### What did you expect to see? Successful build ### What did you see instead? Build produces some files including a go binary but fails during tests - # Testing packages. ok cmd/addr2line 0.765s ... ok unicode/utf16 0.005s ok unicode/utf8 0.009s ? unsafe [no test files] % echo $? 1 % I tried to cobble together the resulting binary and packages into a GOROOT that could build 1.7.4 but unsurprisingly came up short. In any case the 1.4 build should work correctly.",1.0,"doc: source install page should mention make.bash again - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? None installed yet (1.4 bootstrap) ### What operating system and processor architecture are you using (`go env`)? OSX 10.11.6 ### What did you do? Try to build 1.4 bootstrap installation ### What did you expect to see? Successful build ### What did you see instead? Build produces some files including a go binary but fails during tests - # Testing packages. ok cmd/addr2line 0.765s ... ok unicode/utf16 0.005s ok unicode/utf8 0.009s ? unsafe [no test files] % echo $? 1 % I tried to cobble together the resulting binary and packages into a GOROOT that could build 1.7.4 but unsurprisingly came up short. In any case the 1.4 build should work correctly.",1,doc source install page should mention make bash again please answer these questions before submitting your issue thanks what version of go are you using go version none installed yet bootstrap what operating system and processor architecture are you using go env osx what did you do try to build bootstrap installation what did you expect to see successful build what did you see instead build produces some files including a go binary but fails during tests testing packages ok cmd ok unicode ok unicode unsafe echo i tried to cobble together the resulting binary and packages into a goroot that could build but unsurprisingly came up short in any case the build should work correctly ,1 51022,7656272034.0,IssuesEvent,2018-05-10 15:45:53,golang/go,https://api.github.com/repos/golang/go,closed,net/http/pprof: URL path /debug/pprof does not list all the available endpoints,Documentation NeedsFix help wanted,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Whatever is in the Docker image `quay.io/coreos/hyperkube:v1.8.7_coreos.0`. Here is a possibly informative entry from its `/metrics`: kubernetes_build_info{buildDate=""2018-01-18T00:17:18Z"",compiler=""gc"",gitCommit=""768e049ab5230010251f30475e0e785e2e999566"",gitTreeState=""clean"",gitVersion=""v1.8.7+coreos.0"",goVersion=""go1.8.3"",major=""1"",minor=""8+"",platform=""linux/amd64""} ### Does this issue reproduce with the latest release? I think it does. ### What operating system and processor architecture are you using (`go env`)? That is a Docker container image. I ran it on Ubuntu 16.04.1, on an Intel processor. ### What did you do? `kubectl get --raw /debug/pprof --server https://10.233.110.91 --insecure-skip-tls-verify` ### What did you expect to see? I expected to see the complete list of `` that makes for a valid path `/debug/pprof/`. BTW, I can not find the complete list in any one central place. Different partial lists can be found: as shown here, in https://golang.org/pkg/net/http/pprof/ , in https://raywangblog.wordpress.com/2017/07/16/golang-profiling/ , and in https://blog.golang.org/profiling-go-programs . In another issue I finally saw a pointer to https://tip.golang.org/doc/diagnostics.html#profiling . But the full list should be in the main doc as well as what the runtime reports. ### What did you see instead? Fetching `/debug/pprof` got me the following list of choices: ``` 0block 64goroutine 18heap 0mutex 15threadcreate ``` Astonishingly, `profile` is missing from that list! So is `trace` (which _is_ mentioned in https://golang.org/pkg/net/http/pprof/ --- which, distressingly, does not say anything about `?debug=1`).",1.0,"net/http/pprof: URL path /debug/pprof does not list all the available endpoints - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Whatever is in the Docker image `quay.io/coreos/hyperkube:v1.8.7_coreos.0`. Here is a possibly informative entry from its `/metrics`: kubernetes_build_info{buildDate=""2018-01-18T00:17:18Z"",compiler=""gc"",gitCommit=""768e049ab5230010251f30475e0e785e2e999566"",gitTreeState=""clean"",gitVersion=""v1.8.7+coreos.0"",goVersion=""go1.8.3"",major=""1"",minor=""8+"",platform=""linux/amd64""} ### Does this issue reproduce with the latest release? I think it does. ### What operating system and processor architecture are you using (`go env`)? That is a Docker container image. I ran it on Ubuntu 16.04.1, on an Intel processor. ### What did you do? `kubectl get --raw /debug/pprof --server https://10.233.110.91 --insecure-skip-tls-verify` ### What did you expect to see? I expected to see the complete list of `` that makes for a valid path `/debug/pprof/`. BTW, I can not find the complete list in any one central place. Different partial lists can be found: as shown here, in https://golang.org/pkg/net/http/pprof/ , in https://raywangblog.wordpress.com/2017/07/16/golang-profiling/ , and in https://blog.golang.org/profiling-go-programs . In another issue I finally saw a pointer to https://tip.golang.org/doc/diagnostics.html#profiling . But the full list should be in the main doc as well as what the runtime reports. ### What did you see instead? Fetching `/debug/pprof` got me the following list of choices: ``` 0block 64goroutine 18heap 0mutex 15threadcreate ``` Astonishingly, `profile` is missing from that list! So is `trace` (which _is_ mentioned in https://golang.org/pkg/net/http/pprof/ --- which, distressingly, does not say anything about `?debug=1`).",1,net http pprof url path debug pprof does not list all the available endpoints please answer these questions before submitting your issue thanks what version of go are you using go version whatever is in the docker image quay io coreos hyperkube coreos here is a possibly informative entry from its metrics kubernetes build info builddate compiler gc gitcommit gittreestate clean gitversion coreos goversion major minor platform linux does this issue reproduce with the latest release i think it does what operating system and processor architecture are you using go env that is a docker container image i ran it on ubuntu on an intel processor what did you do kubectl get raw debug pprof server insecure skip tls verify what did you expect to see i expected to see the complete list of that makes for a valid path debug pprof btw i can not find the complete list in any one central place different partial lists can be found as shown here in in and in in another issue i finally saw a pointer to but the full list should be in the main doc as well as what the runtime reports what did you see instead fetching debug pprof got me the following list of choices block goroutine heap mutex threadcreate astonishingly profile is missing from that list so is trace which is mentioned in which distressingly does not say anything about debug ,1 75677,9881664688.0,IssuesEvent,2019-06-24 15:08:03,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/gorename: extra whitespace in help text,Documentation,"Noticed an extra whitespace as I was reading its help text. ``` gorename rejects renamings of concrete methods that would change the assignability relation between types and interfaces. If the interface change was intentional, initiate the renaming at the interface method. ``` It is between `interfaces.` and `If`. @gopherbot documentation",1.0,"x/tools/cmd/gorename: extra whitespace in help text - Noticed an extra whitespace as I was reading its help text. ``` gorename rejects renamings of concrete methods that would change the assignability relation between types and interfaces. If the interface change was intentional, initiate the renaming at the interface method. ``` It is between `interfaces.` and `If`. @gopherbot documentation",1,x tools cmd gorename extra whitespace in help text noticed an extra whitespace as i was reading its help text gorename rejects renamings of concrete methods that would change the assignability relation between types and interfaces if the interface change was intentional initiate the renaming at the interface method it is between interfaces and if gopherbot documentation,1 113733,11813127410.0,IssuesEvent,2020-03-19 21:38:35,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: explain automatic vendoring in 'go help modules',Documentation NeedsFix modules,"[`go help modules`](https://golang.org/cmd/go/#hdr-Modules_and_vendoring) states that the `go` command ignores `vendor` directories in module mode unless the `-mod=vendor` flag is given. This is not accurate. Since #33848 was implemented in Go 1.14, `-mod=vendor` may be enabled automatically. We should describe that. Thanks to @myitcv for pointing this out. cc @bcmills @matloob ",1.0,"cmd/go: explain automatic vendoring in 'go help modules' - [`go help modules`](https://golang.org/cmd/go/#hdr-Modules_and_vendoring) states that the `go` command ignores `vendor` directories in module mode unless the `-mod=vendor` flag is given. This is not accurate. Since #33848 was implemented in Go 1.14, `-mod=vendor` may be enabled automatically. We should describe that. Thanks to @myitcv for pointing this out. cc @bcmills @matloob ",1,cmd go explain automatic vendoring in go help modules states that the go command ignores vendor directories in module mode unless the mod vendor flag is given this is not accurate since was implemented in go mod vendor may be enabled automatically we should describe that thanks to myitcv for pointing this out cc bcmills matloob ,1 24895,5109451239.0,IssuesEvent,2017-01-05 20:51:06,golang/go,https://api.github.com/repos/golang/go,opened,doc: reproduce the screencast with the default GOPATH,Documentation,"""[How to write code](https://golang.org/doc/code.html#GOPATH)"" document includes a [screencast](https://www.youtube.com/watch?v=XCsL89YtqCs) to explain the workspaces and the go tool. We may need to reproduce it to avoid setting GOPATH. A similar cast is also required for the Windows users. Even though a large portion of our existing and potential users are Windows users, our core material is lacking references. /cc @adg @campoy @broady ",1.0,"doc: reproduce the screencast with the default GOPATH - ""[How to write code](https://golang.org/doc/code.html#GOPATH)"" document includes a [screencast](https://www.youtube.com/watch?v=XCsL89YtqCs) to explain the workspaces and the go tool. We may need to reproduce it to avoid setting GOPATH. A similar cast is also required for the Windows users. Even though a large portion of our existing and potential users are Windows users, our core material is lacking references. /cc @adg @campoy @broady ",1,doc reproduce the screencast with the default gopath document includes a to explain the workspaces and the go tool we may need to reproduce it to avoid setting gopath a similar cast is also required for the windows users even though a large portion of our existing and potential users are windows users our core material is lacking references cc adg campoy broady ,1 80573,23246921160.0,IssuesEvent,2022-08-03 21:12:42,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/releasebot: improve -dry-run -mode=prepare to support advance testing for more release types,Builders NeedsInvestigation,"Right now, it's possible to use `releasebot -dry-run -mode=prepare` (notably, with `-dry-run` flag) to run a release locally that doesn't publish any public artifacts, but only for the beta release type (e.g., `go1.15beta2`). For most other release types, it fails ""too early"" to produce useful information. For example, it doesn't take into account that the Gerrit CL updating the `VERSION` file isn't actually mailed, so trying to fetch its commit hash from Gerrit will give 404, and `release` won't be able to proceed. This is the tracking issue about improving that, so fewer ad-hoc changes need to be made to `releasebot` each time this ability is needed. It's broken out of https://github.com/golang/go/issues/29252#issuecomment-632352576. /cc @toothrot @cagedmantis @andybons",1.0,"x/build/cmd/releasebot: improve -dry-run -mode=prepare to support advance testing for more release types - Right now, it's possible to use `releasebot -dry-run -mode=prepare` (notably, with `-dry-run` flag) to run a release locally that doesn't publish any public artifacts, but only for the beta release type (e.g., `go1.15beta2`). For most other release types, it fails ""too early"" to produce useful information. For example, it doesn't take into account that the Gerrit CL updating the `VERSION` file isn't actually mailed, so trying to fetch its commit hash from Gerrit will give 404, and `release` won't be able to proceed. This is the tracking issue about improving that, so fewer ad-hoc changes need to be made to `releasebot` each time this ability is needed. It's broken out of https://github.com/golang/go/issues/29252#issuecomment-632352576. /cc @toothrot @cagedmantis @andybons",0,x build cmd releasebot improve dry run mode prepare to support advance testing for more release types right now it s possible to use releasebot dry run mode prepare notably with dry run flag to run a release locally that doesn t publish any public artifacts but only for the beta release type e g for most other release types it fails too early to produce useful information for example it doesn t take into account that the gerrit cl updating the version file isn t actually mailed so trying to fetch its commit hash from gerrit will give and release won t be able to proceed this is the tracking issue about improving that so fewer ad hoc changes need to be made to releasebot each time this ability is needed it s broken out of cc toothrot cagedmantis andybons,0 38126,6660478720.0,IssuesEvent,2017-10-02 00:34:49,golang/go,https://api.github.com/repos/golang/go,closed,bytes: docs do not always state that UTF-8 encoding is used,Documentation,"Not all functions in the bytes package that operate on strings and runes specify that UTF-8 encoding is used. From an initial glance, it appears the following functions are missing that information from their documentation: - ContainsRune - Count - Fields - Runes - Title - ToLower - ToLowerSpecial - ToTitle - ToTitleSpecial - ToUpper - ToUpperSpecial - TrimSpace Does it make sense to include that detail in each of the above functions?",1.0,"bytes: docs do not always state that UTF-8 encoding is used - Not all functions in the bytes package that operate on strings and runes specify that UTF-8 encoding is used. From an initial glance, it appears the following functions are missing that information from their documentation: - ContainsRune - Count - Fields - Runes - Title - ToLower - ToLowerSpecial - ToTitle - ToTitleSpecial - ToUpper - ToUpperSpecial - TrimSpace Does it make sense to include that detail in each of the above functions?",1,bytes docs do not always state that utf encoding is used not all functions in the bytes package that operate on strings and runes specify that utf encoding is used from an initial glance it appears the following functions are missing that information from their documentation containsrune count fields runes title tolower tolowerspecial totitle totitlespecial toupper toupperspecial trimspace does it make sense to include that detail in each of the above functions ,1 31214,8672707000.0,IssuesEvent,2018-11-29 23:03:47,golang/go,https://api.github.com/repos/golang/go,closed,"x/build/cmd/makemac: Mac VMs are failing to start due to ""Invalid configuration""",Builders,"Half of our Mac VMs aren't running. On our Mac VMware cluster, on the Linux VM that runs x/build/cmd/makemac in a systemd unit: ``` # journalctl -f -u makemac ... Feb 15 14:19:06 godns makemac[24540]: $ govc device.usb.add -vm mac_10_11_host10a Feb 15 14:19:07 godns makemac[24540]: $ govc vm.disk.attach -vm mac_10_11_host10a -link=true -persist=false -ds=Pure1-1 -disk osx_11_frozen/osx_11_frozen.vmdk Feb 15 14:19:07 godns makemac[24540]: $ govc vm.destroy mac_10_11_host10a Feb 15 14:19:08 godns makemac[24540]: 2018/02/15 14:19:08 Error creating 10.11: govc vm.disk.attach ...: exit status 1, govc: Invalid configuration for device '0'. Feb 15 14:19:13 godns makemac[24540]: 2018/02/15 14:19:13 Have capacity for 8 more Mac VMs; creating requested 10.10 ... Feb 15 14:19:14 godns makemac[24540]: $ govc vm.create -m 4096 -c 6 -on=false -net dvPortGroup-Private -g darwin14_64Guest -ds BOOT_8 mac_10_10_host08a Feb 15 14:19:16 godns makemac[24540]: $ govc vm.change -e smc.present=TRUE -e ich7m.present=TRUE -e firmware=efi -e guestinfo.key-darwin-amd64-10_10=xx -e guestinfo.name=mac_10_10_host08a -vm mac_10_10_host08a Feb 15 14:19:17 godns makemac[24540]: $ govc device.usb.add -vm mac_10_10_host08a Feb 15 14:19:18 godns makemac[24540]: $ govc vm.disk.attach -vm mac_10_10_host08a -link=true -persist=false -ds=Pure1-1 -disk osx_10_frozen/osx_10_frozen.vmdk Feb 15 14:19:18 godns makemac[24540]: $ govc vm.destroy mac_10_10_host08a Feb 15 14:19:18 godns makemac[24540]: 2018/02/15 14:19:18 Error creating 10.10: govc vm.disk.attach ...: exit status 1, govc: Invalid configuration for device '0'. ... ``` Notice all the `govc: Invalid configuration for device '0'.`. Why did this start failing? This has been running unmodified for about 18 months. Investigate. /cc @andybons @mdempsky @aclements ",1.0,"x/build/cmd/makemac: Mac VMs are failing to start due to ""Invalid configuration"" - Half of our Mac VMs aren't running. On our Mac VMware cluster, on the Linux VM that runs x/build/cmd/makemac in a systemd unit: ``` # journalctl -f -u makemac ... Feb 15 14:19:06 godns makemac[24540]: $ govc device.usb.add -vm mac_10_11_host10a Feb 15 14:19:07 godns makemac[24540]: $ govc vm.disk.attach -vm mac_10_11_host10a -link=true -persist=false -ds=Pure1-1 -disk osx_11_frozen/osx_11_frozen.vmdk Feb 15 14:19:07 godns makemac[24540]: $ govc vm.destroy mac_10_11_host10a Feb 15 14:19:08 godns makemac[24540]: 2018/02/15 14:19:08 Error creating 10.11: govc vm.disk.attach ...: exit status 1, govc: Invalid configuration for device '0'. Feb 15 14:19:13 godns makemac[24540]: 2018/02/15 14:19:13 Have capacity for 8 more Mac VMs; creating requested 10.10 ... Feb 15 14:19:14 godns makemac[24540]: $ govc vm.create -m 4096 -c 6 -on=false -net dvPortGroup-Private -g darwin14_64Guest -ds BOOT_8 mac_10_10_host08a Feb 15 14:19:16 godns makemac[24540]: $ govc vm.change -e smc.present=TRUE -e ich7m.present=TRUE -e firmware=efi -e guestinfo.key-darwin-amd64-10_10=xx -e guestinfo.name=mac_10_10_host08a -vm mac_10_10_host08a Feb 15 14:19:17 godns makemac[24540]: $ govc device.usb.add -vm mac_10_10_host08a Feb 15 14:19:18 godns makemac[24540]: $ govc vm.disk.attach -vm mac_10_10_host08a -link=true -persist=false -ds=Pure1-1 -disk osx_10_frozen/osx_10_frozen.vmdk Feb 15 14:19:18 godns makemac[24540]: $ govc vm.destroy mac_10_10_host08a Feb 15 14:19:18 godns makemac[24540]: 2018/02/15 14:19:18 Error creating 10.10: govc vm.disk.attach ...: exit status 1, govc: Invalid configuration for device '0'. ... ``` Notice all the `govc: Invalid configuration for device '0'.`. Why did this start failing? This has been running unmodified for about 18 months. Investigate. /cc @andybons @mdempsky @aclements ",0,x build cmd makemac mac vms are failing to start due to invalid configuration half of our mac vms aren t running on our mac vmware cluster on the linux vm that runs x build cmd makemac in a systemd unit journalctl f u makemac feb godns makemac govc device usb add vm mac feb godns makemac govc vm disk attach vm mac link true persist false ds disk osx frozen osx frozen vmdk feb godns makemac govc vm destroy mac feb godns makemac error creating govc vm disk attach exit status govc invalid configuration for device feb godns makemac have capacity for more mac vms creating requested feb godns makemac govc vm create m c on false net dvportgroup private g ds boot mac feb godns makemac govc vm change e smc present true e present true e firmware efi e guestinfo key darwin xx e guestinfo name mac vm mac feb godns makemac govc device usb add vm mac feb godns makemac govc vm disk attach vm mac link true persist false ds disk osx frozen osx frozen vmdk feb godns makemac govc vm destroy mac feb godns makemac error creating govc vm disk attach exit status govc invalid configuration for device notice all the govc invalid configuration for device why did this start failing this has been running unmodified for about months investigate cc andybons mdempsky aclements ,0 50057,7558926449.0,IssuesEvent,2018-04-20 00:53:32,golang/go,https://api.github.com/repos/golang/go,closed,net: calling (*UnixConn).File leads to performance degredation,Documentation NeedsFix help wanted,"### What version of Go are you using (`go version`)? ``` $ go version go version go1.9.2 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes, this is on 1.9.2. I haven't tried master. ### What operating system and processor architecture are you using (`go env`)? linux/amd64, Ubuntu 17.04 with 4.10.0-40-generic kernel ### What did you do? I was trying to track down a performance degradation when using unix socket credentials on an abstract socket (bind address starts with a null byte `\x00`). The following benchmark shows the discrepancy: ``` goos: linux goarch: amd64 pkg: github.com/stevvooe/ttrpc BenchmarkRoundTrip-8 50000 22078 ns/op 2593 B/op 43 allocs/op BenchmarkRoundTripUnixSocketCreds-8 10000 141333 ns/op 2593 B/op 43 allocs/op PASS ok github.com/stevvooe/ttrpc 3.142s ``` Notice that the benchmark that uses the unix socket credentials is much slower. The code in question is available here: https://github.com/stevvooe/ttrpc/blob/45d16b41b590938186c5c7cde8088607b3933231/unixcreds.go#L23-L35 After some experimentation, I found that removing the call to `(*UnixConn).File` got rid of the performance discrepancy. As an experiment, I applied the following patch to the `net` package to access the fd directly and pass that to `unix.GetsockoptUcred`: ```diff diff --git a/net/unixsock.go b/net/unixsock.go.fdfix index 057940a..df44b1b 100644 --- a/net/unixsock.go +++ b/net/unixsock.go.fdfix @@ -63,6 +63,10 @@ type UnixConn struct { conn } +func (c *UnixConn) Fd() uintptr { + return uintptr(c.conn.fd.pfd.Sysfd) +} + // SyscallConn returns a raw network connection. // This implements the syscall.Conn interface. func (c *UnixConn) SyscallConn() (syscall.RawConn, error) { ``` When I ran the benchmark with that change, passing `(*UnixConn).Fd` directly to `unix.GetsockoptUcred`, without calling `(*UnixConn).File`, I then got the following benchmark numbers: ``` goos: linux goarch: amd64 pkg: github.com/stevvooe/ttrpc BenchmarkRoundTripUnixSocketCreds-8 50000 21897 ns/op 2593 B/op 43 allocs/op PASS ok github.com/stevvooe/ttrpc 1.693s ``` While this probably isn't a great patch, as making that fd available can probably cause problems with the poller, hopefully this demonstrates the issue with call `(*UnixConn).File`. If you need a more minimal example, let me know. ### What did you expect to see? I expected no performance degradation when calling `(*UnixConn).File`. ### What did you see instead? A performance degradation after calling `(*UnixConn).File`.",1.0,"net: calling (*UnixConn).File leads to performance degredation - ### What version of Go are you using (`go version`)? ``` $ go version go version go1.9.2 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes, this is on 1.9.2. I haven't tried master. ### What operating system and processor architecture are you using (`go env`)? linux/amd64, Ubuntu 17.04 with 4.10.0-40-generic kernel ### What did you do? I was trying to track down a performance degradation when using unix socket credentials on an abstract socket (bind address starts with a null byte `\x00`). The following benchmark shows the discrepancy: ``` goos: linux goarch: amd64 pkg: github.com/stevvooe/ttrpc BenchmarkRoundTrip-8 50000 22078 ns/op 2593 B/op 43 allocs/op BenchmarkRoundTripUnixSocketCreds-8 10000 141333 ns/op 2593 B/op 43 allocs/op PASS ok github.com/stevvooe/ttrpc 3.142s ``` Notice that the benchmark that uses the unix socket credentials is much slower. The code in question is available here: https://github.com/stevvooe/ttrpc/blob/45d16b41b590938186c5c7cde8088607b3933231/unixcreds.go#L23-L35 After some experimentation, I found that removing the call to `(*UnixConn).File` got rid of the performance discrepancy. As an experiment, I applied the following patch to the `net` package to access the fd directly and pass that to `unix.GetsockoptUcred`: ```diff diff --git a/net/unixsock.go b/net/unixsock.go.fdfix index 057940a..df44b1b 100644 --- a/net/unixsock.go +++ b/net/unixsock.go.fdfix @@ -63,6 +63,10 @@ type UnixConn struct { conn } +func (c *UnixConn) Fd() uintptr { + return uintptr(c.conn.fd.pfd.Sysfd) +} + // SyscallConn returns a raw network connection. // This implements the syscall.Conn interface. func (c *UnixConn) SyscallConn() (syscall.RawConn, error) { ``` When I ran the benchmark with that change, passing `(*UnixConn).Fd` directly to `unix.GetsockoptUcred`, without calling `(*UnixConn).File`, I then got the following benchmark numbers: ``` goos: linux goarch: amd64 pkg: github.com/stevvooe/ttrpc BenchmarkRoundTripUnixSocketCreds-8 50000 21897 ns/op 2593 B/op 43 allocs/op PASS ok github.com/stevvooe/ttrpc 1.693s ``` While this probably isn't a great patch, as making that fd available can probably cause problems with the poller, hopefully this demonstrates the issue with call `(*UnixConn).File`. If you need a more minimal example, let me know. ### What did you expect to see? I expected no performance degradation when calling `(*UnixConn).File`. ### What did you see instead? A performance degradation after calling `(*UnixConn).File`.",1,net calling unixconn file leads to performance degredation what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes this is on i haven t tried master what operating system and processor architecture are you using go env linux ubuntu with generic kernel what did you do i was trying to track down a performance degradation when using unix socket credentials on an abstract socket bind address starts with a null byte the following benchmark shows the discrepancy goos linux goarch pkg github com stevvooe ttrpc benchmarkroundtrip ns op b op allocs op benchmarkroundtripunixsocketcreds ns op b op allocs op pass ok github com stevvooe ttrpc notice that the benchmark that uses the unix socket credentials is much slower the code in question is available here after some experimentation i found that removing the call to unixconn file got rid of the performance discrepancy as an experiment i applied the following patch to the net package to access the fd directly and pass that to unix getsockoptucred diff diff git a net unixsock go b net unixsock go fdfix index a net unixsock go b net unixsock go fdfix type unixconn struct conn func c unixconn fd uintptr return uintptr c conn fd pfd sysfd syscallconn returns a raw network connection this implements the syscall conn interface func c unixconn syscallconn syscall rawconn error when i ran the benchmark with that change passing unixconn fd directly to unix getsockoptucred without calling unixconn file i then got the following benchmark numbers goos linux goarch pkg github com stevvooe ttrpc benchmarkroundtripunixsocketcreds ns op b op allocs op pass ok github com stevvooe ttrpc while this probably isn t a great patch as making that fd available can probably cause problems with the poller hopefully this demonstrates the issue with call unixconn file if you need a more minimal example let me know what did you expect to see i expected no performance degradation when calling unixconn file what did you see instead a performance degradation after calling unixconn file ,1 29015,8249983941.0,IssuesEvent,2018-09-12 00:06:25,golang/go,https://api.github.com/repos/golang/go,opened,"x/build/internal/gophers: improve documentation, internal package design",Builders NeedsDecision,"## Problem > _Total mess, but a functional mess, and a starting point for the future._ > — Commit [`891b12dc`](https://github.com/golang/build/commit/891b12dcbdd4ee448d573a78681b2e785daa71ca) The `gophers` package is currently hard to use and hard to modify. It's not easy to read its [documentation](https://godoc.org/golang.org/x/build/internal/gophers) and start using it: ```Go // (no documentation) func GetPerson(id string) *Person ``` I've used and modified it multiple times, and each time, I had to read its internal code to figure out: - what kind of value can ""id"" be? - what is its exact format? - is leading '@' required for GH usernames? optional? unneeded? - is it case sensitive or not? - in what order/what type of information to add to the `addPerson(...)` lines? Despite being an internal package, `gophers` is an important package providing value to 4 other packages, and potentially becoming used in more places. It's no longer just for computing stats, but also for tracking package owners and assigning reviews. Being internal means we can change it easily (even break the API if needed) if we come to agreement on an improved design. ## Proposed Solution I think it can be made easier to use by: - documenting it (so its [godoc](https://godoc.org/golang.org/x/build/internal/gophers) is all you need to use it, no need to read code) For example: ```Go // GetPerson looks up a person by id and returns one if found, or nil otherwise. // // The id is case insensitive, and may be one of: // - full name (""Brad Fitzpatrick"") // - GitHub username (""@bradfitz"") // - Gerrit @ (""5065@62eb7196-b449-3ce5-99f1-c037f21e1705"") // - email (""bradfitz@golang.org"") func GetPerson(id string) *Person ``` @bradfitz If you prefer not to be used as an example, let me know, and we can use someone else (I'm happy to volunteer) or use a generic name. But I think a well known real user makes for a better example. Made easier to modify by: - making its internal `addPerson` logic more explicit rather than implicit For example, instead of what we have now: ```Go addPerson(""Filippo Valsorda"", """", ""6195@62eb7196-b449-3ce5-99f1-c037f21e1705"") addPerson(""Filippo Valsorda"", ""filippo@cloudflare.com"") addPerson(""Filippo Valsorda"", ""filippo@golang.org"", ""11715@62eb7196-b449-3ce5-99f1-c037f21e1705"") addPerson(""Filippo Valsorda"", ""filippo@golang.org"", ""hi@filippo.io"", ""@FiloSottile"") // what kind of changes should be done to modify the end result Person struct? ``` It could be something more explicit, along the lines of: ```Go add(Person{ Name: ""Filippo Valsorda"", GitHub: ""FiloSottile"", Gerrit: ""filippo@golang.org"" Gerrit: []int{6195, 11715}, // Gerrit account IDs. GitEmails: []string{ ""filippo@golang.org"", ""filippo@cloudflare.com"", ""hi@filippo.io"", }, gomote: ""valsorda"", // Gomote user. }) ``` The intention is to make it easy for people to manually add and modify their entries, with predictable results, while still being able to to use code generation (ala `gopherstats -mode=find-gerrit-gophers`) to add missing entries. This is just a quick draft proposal, not necessarily the final API design. If the general direction is well received but there are concerns or improvement suggestions, I'm happy to flesh it out and incorporate feedback. I wouldn't send a CL until I have a solid design. /cc @bradfitz @andybons",1.0,"x/build/internal/gophers: improve documentation, internal package design - ## Problem > _Total mess, but a functional mess, and a starting point for the future._ > — Commit [`891b12dc`](https://github.com/golang/build/commit/891b12dcbdd4ee448d573a78681b2e785daa71ca) The `gophers` package is currently hard to use and hard to modify. It's not easy to read its [documentation](https://godoc.org/golang.org/x/build/internal/gophers) and start using it: ```Go // (no documentation) func GetPerson(id string) *Person ``` I've used and modified it multiple times, and each time, I had to read its internal code to figure out: - what kind of value can ""id"" be? - what is its exact format? - is leading '@' required for GH usernames? optional? unneeded? - is it case sensitive or not? - in what order/what type of information to add to the `addPerson(...)` lines? Despite being an internal package, `gophers` is an important package providing value to 4 other packages, and potentially becoming used in more places. It's no longer just for computing stats, but also for tracking package owners and assigning reviews. Being internal means we can change it easily (even break the API if needed) if we come to agreement on an improved design. ## Proposed Solution I think it can be made easier to use by: - documenting it (so its [godoc](https://godoc.org/golang.org/x/build/internal/gophers) is all you need to use it, no need to read code) For example: ```Go // GetPerson looks up a person by id and returns one if found, or nil otherwise. // // The id is case insensitive, and may be one of: // - full name (""Brad Fitzpatrick"") // - GitHub username (""@bradfitz"") // - Gerrit @ (""5065@62eb7196-b449-3ce5-99f1-c037f21e1705"") // - email (""bradfitz@golang.org"") func GetPerson(id string) *Person ``` @bradfitz If you prefer not to be used as an example, let me know, and we can use someone else (I'm happy to volunteer) or use a generic name. But I think a well known real user makes for a better example. Made easier to modify by: - making its internal `addPerson` logic more explicit rather than implicit For example, instead of what we have now: ```Go addPerson(""Filippo Valsorda"", """", ""6195@62eb7196-b449-3ce5-99f1-c037f21e1705"") addPerson(""Filippo Valsorda"", ""filippo@cloudflare.com"") addPerson(""Filippo Valsorda"", ""filippo@golang.org"", ""11715@62eb7196-b449-3ce5-99f1-c037f21e1705"") addPerson(""Filippo Valsorda"", ""filippo@golang.org"", ""hi@filippo.io"", ""@FiloSottile"") // what kind of changes should be done to modify the end result Person struct? ``` It could be something more explicit, along the lines of: ```Go add(Person{ Name: ""Filippo Valsorda"", GitHub: ""FiloSottile"", Gerrit: ""filippo@golang.org"" Gerrit: []int{6195, 11715}, // Gerrit account IDs. GitEmails: []string{ ""filippo@golang.org"", ""filippo@cloudflare.com"", ""hi@filippo.io"", }, gomote: ""valsorda"", // Gomote user. }) ``` The intention is to make it easy for people to manually add and modify their entries, with predictable results, while still being able to to use code generation (ala `gopherstats -mode=find-gerrit-gophers`) to add missing entries. This is just a quick draft proposal, not necessarily the final API design. If the general direction is well received but there are concerns or improvement suggestions, I'm happy to flesh it out and incorporate feedback. I wouldn't send a CL until I have a solid design. /cc @bradfitz @andybons",0,x build internal gophers improve documentation internal package design problem total mess but a functional mess and a starting point for the future — commit the gophers package is currently hard to use and hard to modify it s not easy to read its and start using it go no documentation func getperson id string person i ve used and modified it multiple times and each time i had to read its internal code to figure out what kind of value can id be what is its exact format is leading required for gh usernames optional unneeded is it case sensitive or not in what order what type of information to add to the addperson lines despite being an internal package gophers is an important package providing value to other packages and potentially becoming used in more places it s no longer just for computing stats but also for tracking package owners and assigning reviews being internal means we can change it easily even break the api if needed if we come to agreement on an improved design proposed solution i think it can be made easier to use by documenting it so its is all you need to use it no need to read code for example go getperson looks up a person by id and returns one if found or nil otherwise the id is case insensitive and may be one of full name brad fitzpatrick github username bradfitz gerrit email bradfitz golang org func getperson id string person bradfitz if you prefer not to be used as an example let me know and we can use someone else i m happy to volunteer or use a generic name but i think a well known real user makes for a better example made easier to modify by making its internal addperson logic more explicit rather than implicit for example instead of what we have now go addperson filippo valsorda addperson filippo valsorda filippo cloudflare com addperson filippo valsorda filippo golang org addperson filippo valsorda filippo golang org hi filippo io filosottile what kind of changes should be done to modify the end result person struct it could be something more explicit along the lines of go add person name filippo valsorda github filosottile gerrit filippo golang org gerrit int gerrit account ids gitemails string filippo golang org filippo cloudflare com hi filippo io gomote valsorda gomote user the intention is to make it easy for people to manually add and modify their entries with predictable results while still being able to to use code generation ala gopherstats mode find gerrit gophers to add missing entries this is just a quick draft proposal not necessarily the final api design if the general direction is well received but there are concerns or improvement suggestions i m happy to flesh it out and incorporate feedback i wouldn t send a cl until i have a solid design cc bradfitz andybons,0 211476,16446718086.0,IssuesEvent,2021-05-20 20:32:32,golang/go,https://api.github.com/repos/golang/go,opened,doc/go1.17: document go/parser changes for Go 1.17,Documentation NeedsFix release-blocker,"`+pkg go/parser, const SkipObjectResolution = 64 +pkg go/parser, const SkipObjectResolution Mode` The `SkipObjectResolution` mode was added to allow skipping the object resolution phase of parsing. CC @griesemer ",1.0,"doc/go1.17: document go/parser changes for Go 1.17 - `+pkg go/parser, const SkipObjectResolution = 64 +pkg go/parser, const SkipObjectResolution Mode` The `SkipObjectResolution` mode was added to allow skipping the object resolution phase of parsing. CC @griesemer ",1,doc document go parser changes for go pkg go parser const skipobjectresolution pkg go parser const skipobjectresolution mode the skipobjectresolution mode was added to allow skipping the object resolution phase of parsing cc griesemer ,1 6739,3044312415.0,IssuesEvent,2015-08-10 08:31:31,golang/go,https://api.github.com/repos/golang/go,closed,build: ARM cross compilation issue with 1.5rc1,Documentation,"I am getting the error `Illegal instruction` when running a simple program (as simple as a ""hello world"" with no dependencies, even when only using print(""hello world"")) on linux/arm (raspberry pi B model) which I cross compiled on linux/amd64 with 1.5.rc1 no matter what value I set GOARM to (tested it with 5, 6 and 7). Running the program with gdb gives me this error: Program received signal SIGILL, Illegal instruction. runtime.check () at /src/runtime/runtime1.go:146 so I guess it is related to the float32 variables here: https://github.com/golang/go/blob/master/src/runtime/runtime1.go#L146 The very same program cross compiles just fine with 1.4.2 (using GOARM 5 and 6) and just gives me the usual error when trying `GOARM=7` runtime: this CPU has no VFPv3 floating point hardware, so it cannot run this GOARM=7 binary. Recompile using GOARM=6.",1.0,"build: ARM cross compilation issue with 1.5rc1 - I am getting the error `Illegal instruction` when running a simple program (as simple as a ""hello world"" with no dependencies, even when only using print(""hello world"")) on linux/arm (raspberry pi B model) which I cross compiled on linux/amd64 with 1.5.rc1 no matter what value I set GOARM to (tested it with 5, 6 and 7). Running the program with gdb gives me this error: Program received signal SIGILL, Illegal instruction. runtime.check () at /src/runtime/runtime1.go:146 so I guess it is related to the float32 variables here: https://github.com/golang/go/blob/master/src/runtime/runtime1.go#L146 The very same program cross compiles just fine with 1.4.2 (using GOARM 5 and 6) and just gives me the usual error when trying `GOARM=7` runtime: this CPU has no VFPv3 floating point hardware, so it cannot run this GOARM=7 binary. Recompile using GOARM=6.",1,build arm cross compilation issue with i am getting the error illegal instruction when running a simple program as simple as a hello world with no dependencies even when only using print hello world on linux arm raspberry pi b model which i cross compiled on linux with no matter what value i set goarm to tested it with and running the program with gdb gives me this error program received signal sigill illegal instruction runtime check at src runtime go so i guess it is related to the variables here the very same program cross compiles just fine with using goarm and and just gives me the usual error when trying goarm runtime this cpu has no floating point hardware so it cannot run this goarm binary recompile using goarm ,1 50950,6136422041.0,IssuesEvent,2017-06-26 09:20:28,golang/go,https://api.github.com/repos/golang/go,opened,syscall: various TestCloneNEWUSERAndRemap/TestEmptyCredGroups test failures,Testing,"``` $ go version go version devel +b4dd1d9 Sun Jun 25 15:57:18 2017 +0000 linux/amd64 ``` `syscall` tests in `exec_linux_test.go` have a fair amount of checks to make sure we skip the tests if we're in no condition to successfully run them, but there must be something missing because I'm seeing the following failures on a GNU/Linux system I use when I run `all.bash`. ``` $ cd src/syscall $ go test --- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups (0.00s) exec_linux_test.go:84: Cmd failed with err fork/exec /usr/bin/whoami: invalid argument, output: --- FAIL: TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups (0.00s) exec_linux_test.go:124: Unprivileged gid_map rewriting with GidMappingsEnableSetgroups must fail --- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s) exec_linux_test.go:132: fork/exec /usr/bin/whoami: invalid argument FAIL exit status 1 FAIL syscall 0.021s ``` This is on a CentOS 7.2 system with kernel `3.10.0-327.36.3.el7.x86_64` from an unprivileged user. The same tests are (correctly) **skipped** on other GNU/Linux systems I tested, which make me think something is missing from the ""skipping-test"" logic.",1.0,"syscall: various TestCloneNEWUSERAndRemap/TestEmptyCredGroups test failures - ``` $ go version go version devel +b4dd1d9 Sun Jun 25 15:57:18 2017 +0000 linux/amd64 ``` `syscall` tests in `exec_linux_test.go` have a fair amount of checks to make sure we skip the tests if we're in no condition to successfully run them, but there must be something missing because I'm seeing the following failures on a GNU/Linux system I use when I run `all.bash`. ``` $ cd src/syscall $ go test --- FAIL: TestCloneNEWUSERAndRemapNoRootDisableSetgroups (0.00s) exec_linux_test.go:84: Cmd failed with err fork/exec /usr/bin/whoami: invalid argument, output: --- FAIL: TestCloneNEWUSERAndRemapNoRootSetgroupsEnableSetgroups (0.00s) exec_linux_test.go:124: Unprivileged gid_map rewriting with GidMappingsEnableSetgroups must fail --- FAIL: TestEmptyCredGroupsDisableSetgroups (0.00s) exec_linux_test.go:132: fork/exec /usr/bin/whoami: invalid argument FAIL exit status 1 FAIL syscall 0.021s ``` This is on a CentOS 7.2 system with kernel `3.10.0-327.36.3.el7.x86_64` from an unprivileged user. The same tests are (correctly) **skipped** on other GNU/Linux systems I tested, which make me think something is missing from the ""skipping-test"" logic.",0,syscall various testclonenewuserandremap testemptycredgroups test failures go version go version devel sun jun linux syscall tests in exec linux test go have a fair amount of checks to make sure we skip the tests if we re in no condition to successfully run them but there must be something missing because i m seeing the following failures on a gnu linux system i use when i run all bash cd src syscall go test fail testclonenewuserandremapnorootdisablesetgroups exec linux test go cmd failed with err fork exec usr bin whoami invalid argument output fail testclonenewuserandremapnorootsetgroupsenablesetgroups exec linux test go unprivileged gid map rewriting with gidmappingsenablesetgroups must fail fail testemptycredgroupsdisablesetgroups exec linux test go fork exec usr bin whoami invalid argument fail exit status fail syscall this is on a centos system with kernel from an unprivileged user the same tests are correctly skipped on other gnu linux systems i tested which make me think something is missing from the skipping test logic ,0 131683,12488713066.0,IssuesEvent,2020-05-31 15:28:59,golang/go,https://api.github.com/repos/golang/go,opened,"x/tools/internal/gocommand: documentation doesn't state what Run{,Piped,Raw} do and what they returns",Documentation NeedsInvestigation,"There are 3 exported identifiers with the word ""Run"" in package [`golang.org/x/tools/internal/gocommand`](https://pkg.go.dev/golang.org/x/tools/internal/gocommand). None of them say what the identifiers do and what they return. Each one says ""it's like this other Run variant"". This makes it hard to know how to use the API of `gocommand` package. ```Go // RunPiped is like Run, but relies on the given stdout/stderr func (i *Invocation) RunPiped(ctx context.Context, stdout, stderr io.Writer) error // Run calls Runner.RunRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) Run(ctx context.Context, inv Invocation) (*bytes.Buffer, error) // RunRaw calls Invocation.runRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) RunRaw(ctx context.Context, inv Invocation) (*bytes.Buffer, *bytes.Buffer, error, error) ``` Documentation for `Invocation.runRaw` isn't readily visible because it's an unexported identifier, but it doesn't help: ```Go // RunRaw is like RunPiped, but also returns the raw stderr and error for callers // that want to do low-level error handling/recovery. func (i *Invocation) runRaw(ctx context.Context) (stdout *bytes.Buffer, stderr *bytes.Buffer, friendlyError error, rawError error) ``` The `Runner` type is documented as follows: ``` // An Runner will run go command invocations and serialize them if it sees a concurrency error. ``` Perhaps that should be made more visible on the methods, and their `*bytes.Buffer` and `error` results can be given names like `stdout` to help clarify what's what.",1.0,"x/tools/internal/gocommand: documentation doesn't state what Run{,Piped,Raw} do and what they returns - There are 3 exported identifiers with the word ""Run"" in package [`golang.org/x/tools/internal/gocommand`](https://pkg.go.dev/golang.org/x/tools/internal/gocommand). None of them say what the identifiers do and what they return. Each one says ""it's like this other Run variant"". This makes it hard to know how to use the API of `gocommand` package. ```Go // RunPiped is like Run, but relies on the given stdout/stderr func (i *Invocation) RunPiped(ctx context.Context, stdout, stderr io.Writer) error // Run calls Runner.RunRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) Run(ctx context.Context, inv Invocation) (*bytes.Buffer, error) // RunRaw calls Invocation.runRaw, serializing requests if they fight over go.mod changes. func (runner *Runner) RunRaw(ctx context.Context, inv Invocation) (*bytes.Buffer, *bytes.Buffer, error, error) ``` Documentation for `Invocation.runRaw` isn't readily visible because it's an unexported identifier, but it doesn't help: ```Go // RunRaw is like RunPiped, but also returns the raw stderr and error for callers // that want to do low-level error handling/recovery. func (i *Invocation) runRaw(ctx context.Context) (stdout *bytes.Buffer, stderr *bytes.Buffer, friendlyError error, rawError error) ``` The `Runner` type is documented as follows: ``` // An Runner will run go command invocations and serialize them if it sees a concurrency error. ``` Perhaps that should be made more visible on the methods, and their `*bytes.Buffer` and `error` results can be given names like `stdout` to help clarify what's what.",1,x tools internal gocommand documentation doesn t state what run piped raw do and what they returns there are exported identifiers with the word run in package none of them say what the identifiers do and what they return each one says it s like this other run variant this makes it hard to know how to use the api of gocommand package go runpiped is like run but relies on the given stdout stderr func i invocation runpiped ctx context context stdout stderr io writer error run calls runner runraw serializing requests if they fight over go mod changes func runner runner run ctx context context inv invocation bytes buffer error runraw calls invocation runraw serializing requests if they fight over go mod changes func runner runner runraw ctx context context inv invocation bytes buffer bytes buffer error error documentation for invocation runraw isn t readily visible because it s an unexported identifier but it doesn t help go runraw is like runpiped but also returns the raw stderr and error for callers that want to do low level error handling recovery func i invocation runraw ctx context context stdout bytes buffer stderr bytes buffer friendlyerror error rawerror error the runner type is documented as follows an runner will run go command invocations and serialize them if it sees a concurrency error perhaps that should be made more visible on the methods and their bytes buffer and error results can be given names like stdout to help clarify what s what ,1 226043,17295665395.0,IssuesEvent,2021-07-25 17:17:16,golang/go,https://api.github.com/repos/golang/go,closed,spec: typographical inconsistency in character literals,Documentation NeedsFix,"### What did you do? * Carefully read through https://golang.org/ref/spec#Rune_literals. ### What did you expect to see? * The Unicode code points around the text ""alert or bell"" should be sorted. * The Unicode code points around the text ""alert or bell"" should either use uppercase or lowercase hexadecimal digits. ### What did you see instead? * There ordering of the code points is not apparent. It is neither alphabetical nor by code point nor ""vertical first, then horizontal"". * U+000D is uppercase, U+000b is lowercase. These inconsistencies are not critical in any way, I just wondered whether there was some reason for this inconsistency and for ordering the code points in exactly this way.",1.0,"spec: typographical inconsistency in character literals - ### What did you do? * Carefully read through https://golang.org/ref/spec#Rune_literals. ### What did you expect to see? * The Unicode code points around the text ""alert or bell"" should be sorted. * The Unicode code points around the text ""alert or bell"" should either use uppercase or lowercase hexadecimal digits. ### What did you see instead? * There ordering of the code points is not apparent. It is neither alphabetical nor by code point nor ""vertical first, then horizontal"". * U+000D is uppercase, U+000b is lowercase. These inconsistencies are not critical in any way, I just wondered whether there was some reason for this inconsistency and for ordering the code points in exactly this way.",1,spec typographical inconsistency in character literals what did you do carefully read through what did you expect to see the unicode code points around the text alert or bell should be sorted the unicode code points around the text alert or bell should either use uppercase or lowercase hexadecimal digits what did you see instead there ordering of the code points is not apparent it is neither alphabetical nor by code point nor vertical first then horizontal u is uppercase u is lowercase these inconsistencies are not critical in any way i just wondered whether there was some reason for this inconsistency and for ordering the code points in exactly this way ,1 36229,6520997092.0,IssuesEvent,2017-08-28 18:46:23,golang/go,https://api.github.com/repos/golang/go,opened,docs: add support for languages other than English,Documentation,"Right now the docs are only in English. There's [some support](https://github.com/golang/go/wiki/NonEnglish) for languages other than English, but the wiki page is merely a footnote. Other projects—[like React](https://crowdin.com/project/react)—are attempting this as well. Not only does it give newcomers a (somewhat) easy way to contribute to Go, it also makes Go a more welcoming and inclusive place for non-English speakers. Obviously the English version would remain the ""master"" version of the docs. Ideally, golang.org would respect the `Accept-Language` header or support some sort of `en/`, `fr/`, etc. URL path option. I'm not sure how much of a proposal this needs to be, but it's something I'm willing to put further thought into if needed. (It's not a language change or anything, so I didn't write out a full proposal.)",1.0,"docs: add support for languages other than English - Right now the docs are only in English. There's [some support](https://github.com/golang/go/wiki/NonEnglish) for languages other than English, but the wiki page is merely a footnote. Other projects—[like React](https://crowdin.com/project/react)—are attempting this as well. Not only does it give newcomers a (somewhat) easy way to contribute to Go, it also makes Go a more welcoming and inclusive place for non-English speakers. Obviously the English version would remain the ""master"" version of the docs. Ideally, golang.org would respect the `Accept-Language` header or support some sort of `en/`, `fr/`, etc. URL path option. I'm not sure how much of a proposal this needs to be, but it's something I'm willing to put further thought into if needed. (It's not a language change or anything, so I didn't write out a full proposal.)",1,docs add support for languages other than english right now the docs are only in english there s for languages other than english but the wiki page is merely a footnote other projects— attempting this as well not only does it give newcomers a somewhat easy way to contribute to go it also makes go a more welcoming and inclusive place for non english speakers obviously the english version would remain the master version of the docs ideally golang org would respect the accept language header or support some sort of en fr etc url path option i m not sure how much of a proposal this needs to be but it s something i m willing to put further thought into if needed it s not a language change or anything so i didn t write out a full proposal ,1 42105,6964010233.0,IssuesEvent,2017-12-08 19:46:32,golang/go,https://api.github.com/repos/golang/go,closed,"net: after call of {TCP,UDP,IP,Unix}Conn/{TCP,Unix}Listener.File(), the deadline will be ineffective",Documentation WaitingForInfo,"https://github.com/golang/go/blob/c2f8ed267b3fdfd06ca1a50aaf405886e52a8122/src/net/fd_unix.go#L316 in the under demo code: the first goroutine, listener is not call (*net.TCPListener).File(), it timeout with setDeadline() works fine the second goroutine, listener call (*net.TCPListener).File(), after that, the timeout don't work the third goroutine, listener call (*net.TCPListener).File(), but then set it to non-blocking mode, timeout works fine too ```go package main import ( ""fmt"" ""net"" ""sync"" ""syscall"" ""time"" ) func main() { wg := new(sync.WaitGroup) wg.Add(2) go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2020"") l, _ := net.ListenTCP(""tcp"", addr) for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 1 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 1 error: %s\n"", err) break } fmt.Printf(""server 1 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2021"") l, _ := net.ListenTCP(""tcp"", addr) l.File() for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 2 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 2 error: %s\n"", err) break } fmt.Printf(""server 2 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2022"") l, _ := net.ListenTCP(""tcp"", addr) f, _ := l.File() syscall.SetNonblock(int(f.Fd()), true) for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 3 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 3 error: %s\n"", err) break } fmt.Printf(""server 3 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() wg.Wait() } ```",1.0,"net: after call of {TCP,UDP,IP,Unix}Conn/{TCP,Unix}Listener.File(), the deadline will be ineffective - https://github.com/golang/go/blob/c2f8ed267b3fdfd06ca1a50aaf405886e52a8122/src/net/fd_unix.go#L316 in the under demo code: the first goroutine, listener is not call (*net.TCPListener).File(), it timeout with setDeadline() works fine the second goroutine, listener call (*net.TCPListener).File(), after that, the timeout don't work the third goroutine, listener call (*net.TCPListener).File(), but then set it to non-blocking mode, timeout works fine too ```go package main import ( ""fmt"" ""net"" ""sync"" ""syscall"" ""time"" ) func main() { wg := new(sync.WaitGroup) wg.Add(2) go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2020"") l, _ := net.ListenTCP(""tcp"", addr) for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 1 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 1 error: %s\n"", err) break } fmt.Printf(""server 1 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2021"") l, _ := net.ListenTCP(""tcp"", addr) l.File() for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 2 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 2 error: %s\n"", err) break } fmt.Printf(""server 2 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() go func() { addr, _ := net.ResolveTCPAddr(""tcp"", "":2022"") l, _ := net.ListenTCP(""tcp"", addr) f, _ := l.File() syscall.SetNonblock(int(f.Fd()), true) for { l.SetDeadline(time.Now().Add(time.Second)) c, err := l.AcceptTCP() if err != nil { if nErr, ok := err.(net.Error); ok && nErr.Timeout() { fmt.Printf(""server 3 timeout at: %s\n"", time.Now()) continue } fmt.Printf(""server 3 error: %s\n"", err) break } fmt.Printf(""server 3 accept from: %s %s\n"", c.RemoteAddr().String(), time.Now()) } wg.Done() }() wg.Wait() } ```",1,net after call of tcp udp ip unix conn tcp unix listener file the deadline will be ineffective in the under demo code the first goroutine listener is not call net tcplistener file it timeout with setdeadline works fine the second goroutine listener call net tcplistener file after that the timeout don t work the third goroutine listener call net tcplistener file but then set it to non blocking mode timeout works fine too go package main import fmt net sync syscall time func main wg new sync waitgroup wg add go func addr net resolvetcpaddr tcp l net listentcp tcp addr for l setdeadline time now add time second c err l accepttcp if err nil if nerr ok err net error ok nerr timeout fmt printf server timeout at s n time now continue fmt printf server error s n err break fmt printf server accept from s s n c remoteaddr string time now wg done go func addr net resolvetcpaddr tcp l net listentcp tcp addr l file for l setdeadline time now add time second c err l accepttcp if err nil if nerr ok err net error ok nerr timeout fmt printf server timeout at s n time now continue fmt printf server error s n err break fmt printf server accept from s s n c remoteaddr string time now wg done go func addr net resolvetcpaddr tcp l net listentcp tcp addr f l file syscall setnonblock int f fd true for l setdeadline time now add time second c err l accepttcp if err nil if nerr ok err net error ok nerr timeout fmt printf server timeout at s n time now continue fmt printf server error s n err break fmt printf server accept from s s n c remoteaddr string time now wg done wg wait ,1 28668,5530757051.0,IssuesEvent,2017-03-21 04:08:10,golang/go,https://api.github.com/repos/golang/go,closed,encoding/gob: encoding of single values doesn't agree with documentation,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.7 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/mero"" GORACE="""" GOROOT=""/home/mero/go"" GOTOOLDIR=""/home/mero/go/pkg/tool/linux_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build316359239=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? https://play.golang.org/p/tXSmbPjlD2 ### What did you expect to see? Above program printing `[]byte{0x2,0x6,0x1}` (see comment for why) ### What did you see instead? Above program printing `[]byet{0x3, 0x6, 0x0, 0x1}` with an extra 0-byte. I tried very hard to find any mention of what this 0-byte means in the [documentation](http://godoc.org/encoding/gob) but couldn't find anything (though I can't conclusively say it isn't there :) ). This only happens for single primitive values (not for structs) and I think it's an artifact of how the state machine works (i.e. it emits an end-of-struct-tag, even though there never was one). As the 0-byte carries no information, this is probably a bug in the encoder, but as there probably is encoding of this in the wild and gob isn't version, it probably can't be fixed. In that case, the documentation should be updated to include this. ",1.0,"encoding/gob: encoding of single values doesn't agree with documentation - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go version go1.7 linux/amd64 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/mero"" GORACE="""" GOROOT=""/home/mero/go"" GOTOOLDIR=""/home/mero/go/pkg/tool/linux_amd64"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build316359239=/tmp/go-build -gno-record-gcc-switches"" CXX=""g++"" CGO_ENABLED=""1"" ### What did you do? https://play.golang.org/p/tXSmbPjlD2 ### What did you expect to see? Above program printing `[]byte{0x2,0x6,0x1}` (see comment for why) ### What did you see instead? Above program printing `[]byet{0x3, 0x6, 0x0, 0x1}` with an extra 0-byte. I tried very hard to find any mention of what this 0-byte means in the [documentation](http://godoc.org/encoding/gob) but couldn't find anything (though I can't conclusively say it isn't there :) ). This only happens for single primitive values (not for structs) and I think it's an artifact of how the state machine works (i.e. it emits an end-of-struct-tag, even though there never was one). As the 0-byte carries no information, this is probably a bug in the encoder, but as there probably is encoding of this in the wild and gob isn't version, it probably can't be fixed. In that case, the documentation should be updated to include this. ",1,encoding gob encoding of single values doesn t agree with documentation please answer these questions before submitting your issue thanks what version of go are you using go version go version linux what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos linux goos linux gopath home mero gorace goroot home mero go gotooldir home mero go pkg tool linux cc gcc gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches cxx g cgo enabled what did you do what did you expect to see above program printing byte see comment for why what did you see instead above program printing byet with an extra byte i tried very hard to find any mention of what this byte means in the but couldn t find anything though i can t conclusively say it isn t there this only happens for single primitive values not for structs and i think it s an artifact of how the state machine works i e it emits an end of struct tag even though there never was one as the byte carries no information this is probably a bug in the encoder but as there probably is encoding of this in the wild and gob isn t version it probably can t be fixed in that case the documentation should be updated to include this ,1 9436,6891284077.0,IssuesEvent,2017-11-22 16:33:54,golang/go,https://api.github.com/repos/golang/go,closed,cmd/cgo: replace _Cgo_use with runtime.KeepAlive?,Performance,"Can _Cgo_use and all associated machinery and runtime checks be replaced with calls to runtime.KeepAlive? Seems like it would generate simpler and faster code. @ianlancetaylor ",True,"cmd/cgo: replace _Cgo_use with runtime.KeepAlive? - Can _Cgo_use and all associated machinery and runtime checks be replaced with calls to runtime.KeepAlive? Seems like it would generate simpler and faster code. @ianlancetaylor ",0,cmd cgo replace cgo use with runtime keepalive can cgo use and all associated machinery and runtime checks be replaced with calls to runtime keepalive seems like it would generate simpler and faster code ianlancetaylor ,0 63653,8689964195.0,IssuesEvent,2018-12-03 20:10:41,golang/go,https://api.github.com/repos/golang/go,closed,net/http: reference CanonicalHeaderKey from Header docs,Documentation,"https://golang.org/pkg/net/http/#Header should say something about CanonicalHeaderKey ",1.0,"net/http: reference CanonicalHeaderKey from Header docs - https://golang.org/pkg/net/http/#Header should say something about CanonicalHeaderKey ",1,net http reference canonicalheaderkey from header docs should say something about canonicalheaderkey ,1 433971,30389035580.0,IssuesEvent,2023-07-13 05:02:01,golang/go,https://api.github.com/repos/golang/go,closed,x/vuln: outdated govulncheck documentation,Documentation vulncheck or vulndb," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.5 darwin/arm64
### Does this issue reproduce at the latest version of golang.org/x/vuln? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
### What did you do? Executed the following commands based on the latest documentation: https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck ``` go install golang.org/x/vuln/cmd/govulncheck@v0.2.0 govulncheck -v -test ./... ``` ### What did you expect to see? ``` govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback. Using go1.20.5 and govulncheck@v0.2.0 with vulnerability data from https://vuln.go.dev (last modified 2023-06-26 16:56:57 +0000 UTC). Scanning your code and 638 packages across 140 dependent modules for known vulnerabilities... No vulnerabilities found. ``` ### What did you see instead? ``` flag provided but not defined: -v Govulncheck reports known vulnerabilities in dependencies. Usage: govulncheck [flags] [patterns] govulncheck -mode=binary [flags] [binary] -C dir change to dir before running govulncheck -db url vulnerability database url (default ""https://vuln.go.dev/"") -json output JSON -mode string supports source or binary (default ""source"") -scan-level string set the scanning level desired, one of module, package or symbol (default ""symbol"") -show list enable display of additional information specified by list -tags list comma-separated list of build tags -test analyze test files (only valid for source mode) For details, see https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck. flag provided but not defined: -v ``` ",1.0,"x/vuln: outdated govulncheck documentation - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.5 darwin/arm64
### Does this issue reproduce at the latest version of golang.org/x/vuln? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
### What did you do? Executed the following commands based on the latest documentation: https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck ``` go install golang.org/x/vuln/cmd/govulncheck@v0.2.0 govulncheck -v -test ./... ``` ### What did you expect to see? ``` govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback. Using go1.20.5 and govulncheck@v0.2.0 with vulnerability data from https://vuln.go.dev (last modified 2023-06-26 16:56:57 +0000 UTC). Scanning your code and 638 packages across 140 dependent modules for known vulnerabilities... No vulnerabilities found. ``` ### What did you see instead? ``` flag provided but not defined: -v Govulncheck reports known vulnerabilities in dependencies. Usage: govulncheck [flags] [patterns] govulncheck -mode=binary [flags] [binary] -C dir change to dir before running govulncheck -db url vulnerability database url (default ""https://vuln.go.dev/"") -json output JSON -mode string supports source or binary (default ""source"") -scan-level string set the scanning level desired, one of module, package or symbol (default ""symbol"") -show list enable display of additional information specified by list -tags list comma-separated list of build tags -test analyze test files (only valid for source mode) For details, see https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck. flag provided but not defined: -v ``` ",1,x vuln outdated govulncheck documentation please answer these questions before submitting your issue thanks to add a new vulnerability to the go vulnerability database see to report an issue about a report see what version of go are you using go version go version go version darwin does this issue reproduce at the latest version of golang org x vuln yes what operating system and processor architecture are you using go env go env output go env what did you do executed the following commands based on the latest documentation go install golang org x vuln cmd govulncheck govulncheck v test what did you expect to see govulncheck is an experimental tool share feedback at using and govulncheck with vulnerability data from last modified utc scanning your code and packages across dependent modules for known vulnerabilities no vulnerabilities found what did you see instead flag provided but not defined v govulncheck reports known vulnerabilities in dependencies usage govulncheck govulncheck mode binary c dir change to dir before running govulncheck db url vulnerability database url default json output json mode string supports source or binary default source scan level string set the scanning level desired one of module package or symbol default symbol show list enable display of additional information specified by list tags list comma separated list of build tags test analyze test files only valid for source mode for details see flag provided but not defined v ,1 36948,18052318237.0,IssuesEvent,2021-09-19 23:51:06,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: suboptimal bits.Rotate* on arm64,Performance NeedsInvestigation arch-arm64,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.1 linux/amd64
### Does this issue reproduce with the latest release? Reproduces with 
$ gotip version
go version devel go1.18-771b8ea4f4c Sun Sep 19 02:43:09 2021 +0000 linux/amd64
### What operating system and processor architecture are you using (`go env`)? 
GOARCH=arm64
### What did you do? ```go func rotxor1(x, y uint64) uint64 { y = (y << 7) | (y >> 57) return x ^ y } func rotxor2(x, y uint64) uint64 { return x ^ bits.RotateLeft64(y, 7) } ``` ### What did you expect to see? Would have been nice to see a fused rotate-xor (#48002), but at least the generated asm should be the same. ### What did you see instead? For rotxor1: MOVD """".y+8(FP), R0 ROR $57, R0, R0 MOVD """".x(FP), R1 EOR R0, R1, R0 For rotxor2: MOVD """".y+8(FP), R0 MOVD $-7, R1 ROR R1, R0, R0 MOVD """".x(FP), R1 EOR R0, R1, R0 The compiler inserts a mov and allocates a register for the shift constant when the intrinsic is used. This is a regression introduced in Go 1.12. It's not limited to these tiny functions: I spotted this when inspecting the generated asm for SipHash.",True,"cmd/compile: suboptimal bits.Rotate* on arm64 - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.1 linux/amd64
### Does this issue reproduce with the latest release? Reproduces with 
$ gotip version
go version devel go1.18-771b8ea4f4c Sun Sep 19 02:43:09 2021 +0000 linux/amd64
### What operating system and processor architecture are you using (`go env`)? 
GOARCH=arm64
### What did you do? ```go func rotxor1(x, y uint64) uint64 { y = (y << 7) | (y >> 57) return x ^ y } func rotxor2(x, y uint64) uint64 { return x ^ bits.RotateLeft64(y, 7) } ``` ### What did you expect to see? Would have been nice to see a fused rotate-xor (#48002), but at least the generated asm should be the same. ### What did you see instead? For rotxor1: MOVD """".y+8(FP), R0 ROR $57, R0, R0 MOVD """".x(FP), R1 EOR R0, R1, R0 For rotxor2: MOVD """".y+8(FP), R0 MOVD $-7, R1 ROR R1, R0, R0 MOVD """".x(FP), R1 EOR R0, R1, R0 The compiler inserts a mov and allocates a register for the shift constant when the intrinsic is used. This is a regression introduced in Go 1.12. It's not limited to these tiny functions: I spotted this when inspecting the generated asm for SipHash.",0,cmd compile suboptimal bits rotate on what version of go are you using go version go version go version linux does this issue reproduce with the latest release reproduces with gotip version go version devel sun sep linux what operating system and processor architecture are you using go env goarch what did you do go func x y y y return x y func x y return x bits y what did you expect to see would have been nice to see a fused rotate xor but at least the generated asm should be the same what did you see instead for movd y fp ror movd x fp eor for movd y fp movd ror movd x fp eor the compiler inserts a mov and allocates a register for the shift constant when the intrinsic is used this is a regression introduced in go it s not limited to these tiny functions i spotted this when inspecting the generated asm for siphash ,0 94104,27114348085.0,IssuesEvent,2023-02-15 17:25:15,golang/go,https://api.github.com/repos/golang/go,closed,x/build: `linux-arm.*-aws` TryBots are often stragglers,Builders NeedsInvestigation,"On several CLs lately, I've seen nearly all of the builders complete within 10 minutes or so, but the `linux-arm-aws` and `linux-arm64-aws` TryBots always seem to take 15 minutes or more. It appears that these builders aren't currently sharded at all: https://cs.opensource.google/go/x/build/+/master:dashboard/builders.go;l=2417;drc=9ca9dc28e477c63197a65122b31a98146c49d07d https://cs.opensource.google/go/x/build/+/master:dashboard/builders.go;l=2434;drc=9ca9dc28e477c63197a65122b31a98146c49d07d Is there something we can do to bring the latency for these builders up to par with the other TryBots? (Perhaps enable sharding?) (CC @prattmic, who I think has done some recent latency measurements)",1.0,"x/build: `linux-arm.*-aws` TryBots are often stragglers - On several CLs lately, I've seen nearly all of the builders complete within 10 minutes or so, but the `linux-arm-aws` and `linux-arm64-aws` TryBots always seem to take 15 minutes or more. It appears that these builders aren't currently sharded at all: https://cs.opensource.google/go/x/build/+/master:dashboard/builders.go;l=2417;drc=9ca9dc28e477c63197a65122b31a98146c49d07d https://cs.opensource.google/go/x/build/+/master:dashboard/builders.go;l=2434;drc=9ca9dc28e477c63197a65122b31a98146c49d07d Is there something we can do to bring the latency for these builders up to par with the other TryBots? (Perhaps enable sharding?) (CC @prattmic, who I think has done some recent latency measurements)",0,x build linux arm aws trybots are often stragglers on several cls lately i ve seen nearly all of the builders complete within minutes or so but the linux arm aws and linux aws trybots always seem to take minutes or more it appears that these builders aren t currently sharded at all is there something we can do to bring the latency for these builders up to par with the other trybots perhaps enable sharding cc prattmic who i think has done some recent latency measurements ,0 3403,2762330881.0,IssuesEvent,2015-04-28 22:00:15,golang/go,https://api.github.com/repos/golang/go,closed,net/http: No easy way to get a server-side Request for testing.,Documentation,"(net/http).Request is populated vastly differently on the client and server sides. That's probably not fixable, given Go1 compatibility. But it causes problems when testing http handlers - httptest.ResponseRecorder needs a Request to go with it, and the obvious candidate (http.NewRequest) generates the client-side version, not the server-side version. You can get the server-side version by setting up an httptest.Server and making a request to it, but that involves a lot of boilerplate and some syscalls. It would be nice if there were a way (in the http or httptest package) to get a Request in the server-side format without having to go through the whole HTTP stack with a real server. ",1.0,"net/http: No easy way to get a server-side Request for testing. - (net/http).Request is populated vastly differently on the client and server sides. That's probably not fixable, given Go1 compatibility. But it causes problems when testing http handlers - httptest.ResponseRecorder needs a Request to go with it, and the obvious candidate (http.NewRequest) generates the client-side version, not the server-side version. You can get the server-side version by setting up an httptest.Server and making a request to it, but that involves a lot of boilerplate and some syscalls. It would be nice if there were a way (in the http or httptest package) to get a Request in the server-side format without having to go through the whole HTTP stack with a real server. ",1,net http no easy way to get a server side request for testing net http request is populated vastly differently on the client and server sides that s probably not fixable given compatibility but it causes problems when testing http handlers httptest responserecorder needs a request to go with it and the obvious candidate http newrequest generates the client side version not the server side version you can get the server side version by setting up an httptest server and making a request to it but that involves a lot of boilerplate and some syscalls it would be nice if there were a way in the http or httptest package to get a request in the server side format without having to go through the whole http stack with a real server ,1 256512,19425201120.0,IssuesEvent,2021-12-21 03:55:10,golang/go,https://api.github.com/repos/golang/go,closed,net/http: broken link to ResponseWriter trailers example,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.3 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/reilly/Library/Caches/go-build""
GOENV=""/Users/reilly/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/reilly/go/pkg/mod""
GONOPROXY=""github.com/EverlongProject""
GONOSUMDB=""github.com/EverlongProject""
GOOS=""darwin""
GOPATH=""/Users/reilly/go""
GOPRIVATE=""github.com/EverlongProject""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.17.3""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gz/4ytqr0r12q1fbx8ct_w3k_880000gn/T/go-build2936231312=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.3 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.3
uname -v: Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	12.1
BuildVersion:	21C52
lldb --version: lldb-1300.0.42.3
Swift version 5.5.2-dev
### What did you do? Tried to follow the ""example_ResponseWriter_trailers"" link just after the text ""the normal Go trailers mechanism is preferred"" in the ""Constants"" section of the doc. ### What did you expect to see? The relevant example ### What did you see instead? The top of the page. The link on the page is https://golang.org/pkg/net/http/#example_ResponseWriter_trailers. The actual anchor attached to the example is `#example-ResponseWriter-Trailers`.",1.0,"net/http: broken link to ResponseWriter trailers example - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.17.3 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/reilly/Library/Caches/go-build""
GOENV=""/Users/reilly/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/reilly/go/pkg/mod""
GONOPROXY=""github.com/EverlongProject""
GONOSUMDB=""github.com/EverlongProject""
GOOS=""darwin""
GOPATH=""/Users/reilly/go""
GOPRIVATE=""github.com/EverlongProject""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.17.3""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gz/4ytqr0r12q1fbx8ct_w3k_880000gn/T/go-build2936231312=/tmp/go-build -gno-record-gcc-switches -fno-common""
GOROOT/bin/go version: go version go1.17.3 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.17.3
uname -v: Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64
ProductName:	macOS
ProductVersion:	12.1
BuildVersion:	21C52
lldb --version: lldb-1300.0.42.3
Swift version 5.5.2-dev
### What did you do? Tried to follow the ""example_ResponseWriter_trailers"" link just after the text ""the normal Go trailers mechanism is preferred"" in the ""Constants"" section of the doc. ### What did you expect to see? The relevant example ### What did you see instead? The top of the page. The link on the page is https://golang.org/pkg/net/http/#example_ResponseWriter_trailers. The actual anchor attached to the example is `#example-ResponseWriter-Trailers`.",1,net http broken link to responsewriter trailers example what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users reilly library caches go build goenv users reilly library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users reilly go pkg mod gonoproxy github com everlongproject gonosumdb github com everlongproject goos darwin gopath users reilly go goprivate github com everlongproject goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders gz t go tmp go build gno record gcc switches fno common goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version sun nov pst root xnu release productname macos productversion buildversion lldb version lldb swift version dev what did you do tried to follow the example responsewriter trailers link just after the text the normal go trailers mechanism is preferred in the constants section of the doc if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see the relevant example what did you see instead the top of the page the link on the page is the actual anchor attached to the example is example responsewriter trailers ,1 58280,8244678824.0,IssuesEvent,2018-09-11 07:18:07,golang/go,https://api.github.com/repos/golang/go,opened,"doc: FAQ entry explaining Go is spelled Go, not Golang",Documentation,This seems to be a recurring point of confusion. Maybe a FAQ entry on correct usage would help.,1.0,"doc: FAQ entry explaining Go is spelled Go, not Golang - This seems to be a recurring point of confusion. Maybe a FAQ entry on correct usage would help.",1,doc faq entry explaining go is spelled go not golang this seems to be a recurring point of confusion maybe a faq entry on correct usage would help ,1 143626,11571361161.0,IssuesEvent,2020-02-20 21:23:36,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/go: TestExecutableGOROOT occasionally fails with ""text file busy""",NeedsInvestigation Testing,"Noticed on the build dashboard today: https://build.golang.org/log/b1c4550d9629753e0fc2909f97f5610c385b0846 @matloob ",1.0,"cmd/go: TestExecutableGOROOT occasionally fails with ""text file busy"" - Noticed on the build dashboard today: https://build.golang.org/log/b1c4550d9629753e0fc2909f97f5610c385b0846 @matloob ",0,cmd go testexecutablegoroot occasionally fails with text file busy noticed on the build dashboard today matloob ,0 56293,13785036086.0,IssuesEvent,2020-10-08 21:59:06,golang/go,https://api.github.com/repos/golang/go,closed,x/build: add builder for ios/arm64,Builders NeedsInvestigation new-builder,"[CL 254740](https://golang.org/cl/254740) has added GOOS=ios to the output of `go tool dist list`. `TestTryBotsCompileAllPorts` in x/build/dashobard is failing because we don't yet have a builder (real or misc-compile one) covering the new ios/arm64 pair. This is the tracking issue to add a builder. We may want to repurpose or clone the existing darwin-arm64-corellium builder for this. Need to think about how to best make this work for Go 1.16 and Go 1.15+1.14 (or maybe we don't try to support 1.15+1.14 because iOS is an experimental port). /cc @cagedmantis @toothrot @cherrymui",2.0,"x/build: add builder for ios/arm64 - [CL 254740](https://golang.org/cl/254740) has added GOOS=ios to the output of `go tool dist list`. `TestTryBotsCompileAllPorts` in x/build/dashobard is failing because we don't yet have a builder (real or misc-compile one) covering the new ios/arm64 pair. This is the tracking issue to add a builder. We may want to repurpose or clone the existing darwin-arm64-corellium builder for this. Need to think about how to best make this work for Go 1.16 and Go 1.15+1.14 (or maybe we don't try to support 1.15+1.14 because iOS is an experimental port). /cc @cagedmantis @toothrot @cherrymui",0,x build add builder for ios has added goos ios to the output of go tool dist list testtrybotscompileallports in x build dashobard is failing because we don t yet have a builder real or misc compile one covering the new ios pair this is the tracking issue to add a builder we may want to repurpose or clone the existing darwin corellium builder for this need to think about how to best make this work for go and go or maybe we don t try to support because ios is an experimental port cc cagedmantis toothrot cherrymui,0 123335,12196996575.0,IssuesEvent,2020-04-29 19:59:24,golang/go,https://api.github.com/repos/golang/go,closed,"strings, bytes: divergent documentation for FieldsFunc functions",Documentation NeedsFix,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read the documentation for [`strings.FieldsFunc`](https://golang.org/pkg/strings/#FieldsFunc) ### What did you see? I see that the documentation is out of date with respect to the following note. > FieldsFunc makes no guarantees about the order in which it calls f(c). If f does not return consistent results for a given c, FieldsFunc may crash. This was appropriate when `FieldsForFunc` was using a two-pass logic. However, when the function was optimized to address #19789, this note is not correct anymore. The new implementation does only one-pass over the input. Hence, we can safely remove this note. ",1.0,"strings, bytes: divergent documentation for FieldsFunc functions - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.14.2 linux/amd64
### Does this issue reproduce with the latest release? Yes ### What did you do? Read the documentation for [`strings.FieldsFunc`](https://golang.org/pkg/strings/#FieldsFunc) ### What did you see? I see that the documentation is out of date with respect to the following note. > FieldsFunc makes no guarantees about the order in which it calls f(c). If f does not return consistent results for a given c, FieldsFunc may crash. This was appropriate when `FieldsForFunc` was using a two-pass logic. However, when the function was optimized to address #19789, this note is not correct anymore. The new implementation does only one-pass over the input. Hence, we can safely remove this note. ",1,strings bytes divergent documentation for fieldsfunc functions what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what did you do read the documentation for what did you see i see that the documentation is out of date with respect to the following note fieldsfunc makes no guarantees about the order in which it calls f c if f does not return consistent results for a given c fieldsfunc may crash this was appropriate when fieldsforfunc was using a two pass logic however when the function was optimized to address this note is not correct anymore the new implementation does only one pass over the input hence we can safely remove this note ,1 81733,10255495303.0,IssuesEvent,2019-08-21 15:31:54,golang/go,https://api.github.com/repos/golang/go,closed,x/website: documents link is not aligned on tip.golang.org/doc/go1.6+,Documentation NeedsFix help wanted,"### What did you do? visit one of: https://tip.golang.org/doc/go1.6 ... https://tip.golang.org/doc/go1.13 ### What did you expect to see? see behavior on everything pre go1.6 docs ### What did you see instead? ![documents_not_aligned](https://user-images.githubusercontent.com/19241481/63279822-fc51ed80-c2a9-11e9-8daa-00033fc2e2f5.png) ",1.0,"x/website: documents link is not aligned on tip.golang.org/doc/go1.6+ - ### What did you do? visit one of: https://tip.golang.org/doc/go1.6 ... https://tip.golang.org/doc/go1.13 ### What did you expect to see? see behavior on everything pre go1.6 docs ### What did you see instead? ![documents_not_aligned](https://user-images.githubusercontent.com/19241481/63279822-fc51ed80-c2a9-11e9-8daa-00033fc2e2f5.png) ",1,x website documents link is not aligned on tip golang org doc what did you do visit one of what did you expect to see see behavior on everything pre docs what did you see instead ,1 30369,8526642622.0,IssuesEvent,2018-11-02 16:53:21,golang/go,https://api.github.com/repos/golang/go,closed,x/build: trybots not running due to maintner resource temporarily unavailable errors,Builders,"Trybots aren't running because maintner isn't noticing that there's new stuff on Gerrit, due to: ``` 2018/02/02 20:07:17 Temporary error from gerrit go.googlesource.com/example: running git remote -v in /cache/go.googlesource.com%2Fexample: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit go.googlesource.com/time: init: running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit go.googlesource.com/time: running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit go.googlesource.com/build: init: running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit go.googlesource.com/build: running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit code.googlesource.com/gocloud: init: running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit code.googlesource.com/gocloud: running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 gerrit go.googlesource.com/gddo: init: running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 Temporary error from gerrit go.googlesource.com/gddo: running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/scratch: init: running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/scratch: running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/proposal: init: running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/proposal: running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/tour: init: running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/tour: running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 gerrit go.googlesource.com/oauth2: init: running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 Temporary error from gerrit go.googlesource.com/oauth2: running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 gerrit go.googlesource.com/exp: init: running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 Temporary error from gerrit go.googlesource.com/exp: running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable^C ``` This smells just like #23686 in a different binary. Both of these were just updated for the LetsEncrypt ACME changes. So what changed in the meantime? What resource isn't available? /cc @andybons @ianlancetaylor ",1.0,"x/build: trybots not running due to maintner resource temporarily unavailable errors - Trybots aren't running because maintner isn't noticing that there's new stuff on Gerrit, due to: ``` 2018/02/02 20:07:17 Temporary error from gerrit go.googlesource.com/example: running git remote -v in /cache/go.googlesource.com%2Fexample: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit go.googlesource.com/time: init: running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit go.googlesource.com/time: running git remote -v in /cache/go.googlesource.com%2Ftime: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit go.googlesource.com/build: init: running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit go.googlesource.com/build: running git remote -v in /cache/go.googlesource.com%2Fbuild: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 gerrit code.googlesource.com/gocloud: init: running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:18 Temporary error from gerrit code.googlesource.com/gocloud: running git remote -v in /cache/code.googlesource.com%2Fgocloud: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 gerrit go.googlesource.com/gddo: init: running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:19 Temporary error from gerrit go.googlesource.com/gddo: running git remote -v in /cache/go.googlesource.com%2Fgddo: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/scratch: init: running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/scratch: running git remote -v in /cache/go.googlesource.com%2Fscratch: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/proposal: init: running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/proposal: running git remote -v in /cache/go.googlesource.com%2Fproposal: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 gerrit go.googlesource.com/tour: init: running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:20 Temporary error from gerrit go.googlesource.com/tour: running git remote -v in /cache/go.googlesource.com%2Ftour: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 gerrit go.googlesource.com/oauth2: init: running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 Temporary error from gerrit go.googlesource.com/oauth2: running git remote -v in /cache/go.googlesource.com%2Foauth2: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 gerrit go.googlesource.com/exp: init: running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 IS TEMP ERROR? *errors.errorString running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable 2018/02/02 20:07:21 Temporary error from gerrit go.googlesource.com/exp: running git remote -v in /cache/go.googlesource.com%2Fexp: fork/exec /usr/bin/git: resource temporarily unavailable^C ``` This smells just like #23686 in a different binary. Both of these were just updated for the LetsEncrypt ACME changes. So what changed in the meantime? What resource isn't available? /cc @andybons @ianlancetaylor ",0,x build trybots not running due to maintner resource temporarily unavailable errors trybots aren t running because maintner isn t noticing that there s new stuff on gerrit due to temporary error from gerrit go googlesource com example running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com time init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com time running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com build init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com build running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit code googlesource com gocloud init running git remote v in cache code googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache code googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit code googlesource com gocloud running git remote v in cache code googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com gddo init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com gddo running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com scratch init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com scratch running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com proposal init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com proposal running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com tour init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com tour running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable gerrit go googlesource com exp init running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable is temp error errors errorstring running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable temporary error from gerrit go googlesource com exp running git remote v in cache go googlesource com fork exec usr bin git resource temporarily unavailable c this smells just like in a different binary both of these were just updated for the letsencrypt acme changes so what changed in the meantime what resource isn t available cc andybons ianlancetaylor ,0 264940,20049473500.0,IssuesEvent,2022-02-03 03:21:56,golang/go,https://api.github.com/repos/golang/go,closed,"net/netip: ParsePrefix documentation typo ""2001::db8::/32""",Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go1.18beta2
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Not applicable ### What did you do? Read docs/code ### What did you expect to see? Valid CIDR notation ### What did you see instead? Invalid CIDR notation ""2001::db8::/32"" includes an invalid IPv6 address. The double colon may appear only once. This code panics: 
package main

import (
	""net/netip""
)

// This playground uses a development build of Go:
// devel go1.18-41f485b9a7 Mon Jan 31 13:43:52 2022 +0000

func main() {
	_ = netip.MustParsePrefix(""2001::db8::/32"")
}
https://github.com/golang/go/blob/41f485b9a7d8fd647c415be1d11b612063dff21c/src/net/netip/netip.go#L1291 ",1.0,"net/netip: ParsePrefix documentation typo ""2001::db8::/32"" - ### What version of Go are you using (`go version`)? 
$ go version
go1.18beta2
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? Not applicable ### What did you do? Read docs/code ### What did you expect to see? Valid CIDR notation ### What did you see instead? Invalid CIDR notation ""2001::db8::/32"" includes an invalid IPv6 address. The double colon may appear only once. This code panics: 
package main

import (
	""net/netip""
)

// This playground uses a development build of Go:
// devel go1.18-41f485b9a7 Mon Jan 31 13:43:52 2022 +0000

func main() {
	_ = netip.MustParsePrefix(""2001::db8::/32"")
}
https://github.com/golang/go/blob/41f485b9a7d8fd647c415be1d11b612063dff21c/src/net/netip/netip.go#L1291 ",1,net netip parseprefix documentation typo please answer these questions before submitting your issue thanks what version of go are you using go version go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env not applicable what did you do read docs code what did you expect to see valid cidr notation what did you see instead invalid cidr notation includes an invalid address the double colon may appear only once this code panics package main import net netip this playground uses a development build of go devel mon jan func main netip mustparseprefix ,1 111723,9539999734.0,IssuesEvent,2019-04-30 18:22:35,golang/go,https://api.github.com/repos/golang/go,closed,"encoding/gob: test frequently failing with ""signal: killed"" in longtest builder",NeedsInvestigation Soon Testing release-blocker,"The `encoding/gob` test is frequently failing in the `longtest` builder with output like: ``` signal: killed FAIL encoding/gob 13.202s ``` (That's the entire output.) First example I saw was in https://build.golang.org/log/608043bae4b6ccc72e79f266fd92fa51410517b1, but the failure mode doesn't obviously relate to the associated CL (https://golang.org/cl/172418). I haven't been able to replicate the failure locally so far. I don't know whether the failure is due to recent changes in the compiler (@mdempsky, @cuonglm) or in `cmd/go` (myself and @jayconrod). The transition from passing to failure was partially masked by #31263.",1.0,"encoding/gob: test frequently failing with ""signal: killed"" in longtest builder - The `encoding/gob` test is frequently failing in the `longtest` builder with output like: ``` signal: killed FAIL encoding/gob 13.202s ``` (That's the entire output.) First example I saw was in https://build.golang.org/log/608043bae4b6ccc72e79f266fd92fa51410517b1, but the failure mode doesn't obviously relate to the associated CL (https://golang.org/cl/172418). I haven't been able to replicate the failure locally so far. I don't know whether the failure is due to recent changes in the compiler (@mdempsky, @cuonglm) or in `cmd/go` (myself and @jayconrod). The transition from passing to failure was partially masked by #31263.",0,encoding gob test frequently failing with signal killed in longtest builder the encoding gob test is frequently failing in the longtest builder with output like signal killed fail encoding gob that s the entire output first example i saw was in but the failure mode doesn t obviously relate to the associated cl i haven t been able to replicate the failure locally so far i don t know whether the failure is due to recent changes in the compiler mdempsky cuonglm or in cmd go myself and jayconrod the transition from passing to failure was partially masked by ,0 84561,7926455140.0,IssuesEvent,2018-07-06 02:14:23,golang/go,https://api.github.com/repos/golang/go,closed,net/http: TestServerShutdownStateNew is flaky,NeedsFix Testing,"Two recent failures on linux-amd64-longtest: https://build.golang.org/log/ef73c0ec3463104a804cba25d4b550a403db26b9 https://build.golang.org/log/6e2a1f6b524c1c8d2f794bce1bae272c87a62ef7 ``` --- FAIL: TestServerShutdownStateNew (2.00s) serve_test.go:5603: shutdown too soon after 49.41µs serve_test.go:5617: timeout waiting for Read to unblock FAIL FAIL net/http 37.294s ``` The test accepts shutdowns between 0.5x and 1.5x the expected amount, which is 5s. The result of not even a millisecond seems to point that the test completely breaks, as opposed to this being a timing issue. Looking into it. /cc @bradfitz ",1.0,"net/http: TestServerShutdownStateNew is flaky - Two recent failures on linux-amd64-longtest: https://build.golang.org/log/ef73c0ec3463104a804cba25d4b550a403db26b9 https://build.golang.org/log/6e2a1f6b524c1c8d2f794bce1bae272c87a62ef7 ``` --- FAIL: TestServerShutdownStateNew (2.00s) serve_test.go:5603: shutdown too soon after 49.41µs serve_test.go:5617: timeout waiting for Read to unblock FAIL FAIL net/http 37.294s ``` The test accepts shutdowns between 0.5x and 1.5x the expected amount, which is 5s. The result of not even a millisecond seems to point that the test completely breaks, as opposed to this being a timing issue. Looking into it. /cc @bradfitz ",0,net http testservershutdownstatenew is flaky two recent failures on linux longtest fail testservershutdownstatenew serve test go shutdown too soon after serve test go timeout waiting for read to unblock fail fail net http the test accepts shutdowns between and the expected amount which is the result of not even a millisecond seems to point that the test completely breaks as opposed to this being a timing issue looking into it cc bradfitz ,0 193595,15381051584.0,IssuesEvent,2021-03-02 22:02:12,golang/go,https://api.github.com/repos/golang/go,closed,x/website: various mistakes in documentation on modules,Documentation NeedsFix,"I read the new documentation on modules (which is great, btw) and took notes of mistakes I encountered. https://golang.org/doc/modules/gomod-ref 1. Contradiction: The description for 'replacement-path' says: ""[...] If this is a module path, you must specify a \_replacement-version\_ value. [...]"" But the following example shows the replacement of a module path without a replacement version value: ""`replace example.com/othermodule => example.com/myfork/othermodule`"" 2. Section 'exclude', description of 'module-version"": ""If this version number is omitted, all versions of the module are replaced with the content on the right side of the arrow."" But an 'exclude' directive doesn't have an arrow. This sentence seems to be copy&pasted from the 'replace' directive and wrong. 3. Contradiction: ""These directives are ignored in modules that depend on the current module."" vs. later ""These directives are ignored in modules that are dependencies of the current module."" Which one is it? 4. Formatting: In the first example one line is not correctly indented. 5. Formatting: ""\_replacement-version\_"", ""\_replacement-path\_"". The underscores are probably not intended, but unsupported Markdown syntax. https://golang.org/doc/tutorial/create-module 6. ""This tutorial's sequence includes six brief topics [...]"" Followed by a numbered list of seven topics. s/six/seven/ https://golang.org/doc/tutorial/call-module-code 7. Broken link: ""Here, the replace directive [...]"" 8. Broken tutorial: ""In the hello directory, run go build to make Go locate the module and add it as a dependency to the go.mod file."" Starting with Go 1.16 'go build' doesn't add dependencies anymore, which breaks this tutorial (similar to #43672). https://golang.org/doc/tutorial/getting-started 9. Outdated description: ""3. On the Doc tab, under Index, [...]"" The former Doc tab is a menu item named 'Documentation' on the left side now. https://golang.org/doc/modules/managing-dependencies 10. Broken link: ""See package discovery."" 11. Typo: ""One you've discovered"" s/One/Once/ https://golang.org/doc/modules/version-numbers 12. Typo: ""For more, see Managingdependencies."" (missing space) https://golang.org/doc/modules/publishing 13. Typo: ""6. [...] with 1nformation about [...]"" s/1nformation/information/ 14. Broken links: ""go get command"" (twice) here: ""[ ... ] and run the go get command [...]"", and here: ""They can run the go get command [...] https://golang.org/doc/modules/major-version 15. Invalid syntax: ""Old import statement: `import example.com/mymodule/package1` New import statement: `import example.com/mymodule/v2/package1`"" Package paths must be in quotes. General 16. The anchors on most pages under doc/modules have temporary names: #tmp_0, #tmp_1, etc. ",1.0,"x/website: various mistakes in documentation on modules - I read the new documentation on modules (which is great, btw) and took notes of mistakes I encountered. https://golang.org/doc/modules/gomod-ref 1. Contradiction: The description for 'replacement-path' says: ""[...] If this is a module path, you must specify a \_replacement-version\_ value. [...]"" But the following example shows the replacement of a module path without a replacement version value: ""`replace example.com/othermodule => example.com/myfork/othermodule`"" 2. Section 'exclude', description of 'module-version"": ""If this version number is omitted, all versions of the module are replaced with the content on the right side of the arrow."" But an 'exclude' directive doesn't have an arrow. This sentence seems to be copy&pasted from the 'replace' directive and wrong. 3. Contradiction: ""These directives are ignored in modules that depend on the current module."" vs. later ""These directives are ignored in modules that are dependencies of the current module."" Which one is it? 4. Formatting: In the first example one line is not correctly indented. 5. Formatting: ""\_replacement-version\_"", ""\_replacement-path\_"". The underscores are probably not intended, but unsupported Markdown syntax. https://golang.org/doc/tutorial/create-module 6. ""This tutorial's sequence includes six brief topics [...]"" Followed by a numbered list of seven topics. s/six/seven/ https://golang.org/doc/tutorial/call-module-code 7. Broken link: ""Here, the replace directive [...]"" 8. Broken tutorial: ""In the hello directory, run go build to make Go locate the module and add it as a dependency to the go.mod file."" Starting with Go 1.16 'go build' doesn't add dependencies anymore, which breaks this tutorial (similar to #43672). https://golang.org/doc/tutorial/getting-started 9. Outdated description: ""3. On the Doc tab, under Index, [...]"" The former Doc tab is a menu item named 'Documentation' on the left side now. https://golang.org/doc/modules/managing-dependencies 10. Broken link: ""See package discovery."" 11. Typo: ""One you've discovered"" s/One/Once/ https://golang.org/doc/modules/version-numbers 12. Typo: ""For more, see Managingdependencies."" (missing space) https://golang.org/doc/modules/publishing 13. Typo: ""6. [...] with 1nformation about [...]"" s/1nformation/information/ 14. Broken links: ""go get command"" (twice) here: ""[ ... ] and run the go get command [...]"", and here: ""They can run the go get command [...] https://golang.org/doc/modules/major-version 15. Invalid syntax: ""Old import statement: `import example.com/mymodule/package1` New import statement: `import example.com/mymodule/v2/package1`"" Package paths must be in quotes. General 16. The anchors on most pages under doc/modules have temporary names: #tmp_0, #tmp_1, etc. ",1,x website various mistakes in documentation on modules i read the new documentation on modules which is great btw and took notes of mistakes i encountered contradiction the description for replacement path says if this is a module path you must specify a replacement version value but the following example shows the replacement of a module path without a replacement version value replace example com othermodule example com myfork othermodule section exclude description of module version if this version number is omitted all versions of the module are replaced with the content on the right side of the arrow but an exclude directive doesn t have an arrow this sentence seems to be copy pasted from the replace directive and wrong contradiction these directives are ignored in modules that depend on the current module vs later these directives are ignored in modules that are dependencies of the current module which one is it formatting in the first example one line is not correctly indented formatting replacement version replacement path the underscores are probably not intended but unsupported markdown syntax this tutorial s sequence includes six brief topics followed by a numbered list of seven topics s six seven broken link here the replace directive broken tutorial in the hello directory run go build to make go locate the module and add it as a dependency to the go mod file starting with go go build doesn t add dependencies anymore which breaks this tutorial similar to outdated description on the doc tab under index the former doc tab is a menu item named documentation on the left side now broken link see package discovery typo one you ve discovered s one once typo for more see managingdependencies missing space typo with about s information broken links go get command twice here and run the go get command and here they can run the go get command invalid syntax old import statement import example com mymodule new import statement import example com mymodule package paths must be in quotes general the anchors on most pages under doc modules have temporary names tmp tmp etc ,1 57036,8137873918.0,IssuesEvent,2018-08-20 13:14:43,golang/go,https://api.github.com/repos/golang/go,closed,net/http: imprecise description of the return values of HTTP serve functions,Documentation,"### What version of Go are you using (`go version`)? go version go1.10.3 darwin/amd64 In `net.http` package, there are following fucntions/methods related to serve HTTP: 1. [http.Serve](https://golang.org/pkg/net/http/#Serve) 1. [http.ListenAndServe](https://golang.org/pkg/net/http/#ListenAndServe) 1. [http.ListenAndServeTLS](https://golang.org/pkg/net/http/#ListenAndServeTLS) 1. [http.Server.Serve](https://golang.org/pkg/net/http/#Server.Serve) 1. [http.Server.ListenAndServe](https://golang.org/pkg/net/http/#Server.ListenAndServe) 1. [http.Server.ListenAndServeTLS](https://golang.org/pkg/net/http/#Server.ListenAndServeTLS) Except the first one, all docs for those functiosn/methods say something like `always returns a non-nil error`. But if such a function/method is terminated by a signal which is a common way to terminate a HTTP server, it will not return. For example, consider the following go code `http.go`: ```go package main import ( ""log"" ""net/http"" ) func main() { var srv http.Server srv.Addr = "":12345"" if err := srv.ListenAndServe(); err != http.ErrServerClosed { log.Printf(""http error: %s"", err) } } ``` A `SIGINT` signal will terminate the program and `http.ListenAndServe` will not return. ``` ➜ local go run http.go ^Csignal: interrupt ``` Only if `srv` is teriminated by [Server.Shutdown](https://golang.org/pkg/net/http/#Server.Shutdown), ` srv.ListenAndServe` will return. I think that the descripion `always returns a non-nil error` should mention this behaviour. Otherwise, people will tend to write [the following code](https://github.com/coreos/etcd/blob/master/contrib/raftexample/raft.go#L467): ```go err = (&http.Server{Handler: rc.transport.Handler()}).Serve(ln) select { case <-rc.httpstopc: default: log.Fatalf(""raftexample: Failed to serve rafthttp (%v)"", err) } ``` They are hoping that `Serve` will return. But it will not since `Shutdown` is not used in a way descripted in `Shutdown`'s example code. ",1.0,"net/http: imprecise description of the return values of HTTP serve functions - ### What version of Go are you using (`go version`)? go version go1.10.3 darwin/amd64 In `net.http` package, there are following fucntions/methods related to serve HTTP: 1. [http.Serve](https://golang.org/pkg/net/http/#Serve) 1. [http.ListenAndServe](https://golang.org/pkg/net/http/#ListenAndServe) 1. [http.ListenAndServeTLS](https://golang.org/pkg/net/http/#ListenAndServeTLS) 1. [http.Server.Serve](https://golang.org/pkg/net/http/#Server.Serve) 1. [http.Server.ListenAndServe](https://golang.org/pkg/net/http/#Server.ListenAndServe) 1. [http.Server.ListenAndServeTLS](https://golang.org/pkg/net/http/#Server.ListenAndServeTLS) Except the first one, all docs for those functiosn/methods say something like `always returns a non-nil error`. But if such a function/method is terminated by a signal which is a common way to terminate a HTTP server, it will not return. For example, consider the following go code `http.go`: ```go package main import ( ""log"" ""net/http"" ) func main() { var srv http.Server srv.Addr = "":12345"" if err := srv.ListenAndServe(); err != http.ErrServerClosed { log.Printf(""http error: %s"", err) } } ``` A `SIGINT` signal will terminate the program and `http.ListenAndServe` will not return. ``` ➜ local go run http.go ^Csignal: interrupt ``` Only if `srv` is teriminated by [Server.Shutdown](https://golang.org/pkg/net/http/#Server.Shutdown), ` srv.ListenAndServe` will return. I think that the descripion `always returns a non-nil error` should mention this behaviour. Otherwise, people will tend to write [the following code](https://github.com/coreos/etcd/blob/master/contrib/raftexample/raft.go#L467): ```go err = (&http.Server{Handler: rc.transport.Handler()}).Serve(ln) select { case <-rc.httpstopc: default: log.Fatalf(""raftexample: Failed to serve rafthttp (%v)"", err) } ``` They are hoping that `Serve` will return. But it will not since `Shutdown` is not used in a way descripted in `Shutdown`'s example code. ",1,net http imprecise description of the return values of http serve functions what version of go are you using go version go version darwin in net http package there are following fucntions methods related to serve http except the first one all docs for those functiosn methods say something like always returns a non nil error but if such a function method is terminated by a signal which is a common way to terminate a http server it will not return for example consider the following go code http go go package main import log net http func main var srv http server srv addr if err srv listenandserve err http errserverclosed log printf http error s err a sigint signal will terminate the program and http listenandserve will not return ➜ local go run http go csignal interrupt only if srv is teriminated by srv listenandserve will return i think that the descripion always returns a non nil error should mention this behaviour otherwise people will tend to write go err http server handler rc transport handler serve ln select case rc httpstopc default log fatalf raftexample failed to serve rafthttp v err they are hoping that serve will return but it will not since shutdown is not used in a way descripted in shutdown s example code ,1 52208,7752878849.0,IssuesEvent,2018-05-30 21:48:36,golang/go,https://api.github.com/repos/golang/go,closed,blog: one sentence typo of blog go-maps-in-action,Documentation NeedsFix help wanted,"in blog https://blog.golang.org/go-maps-in-action section `Iteration order` >When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. Since Go 1 the runtime randomizes map iteration order, as programmers relied on the stable iteration order of the previous implementation. If you require a stable iteration order you must maintain a separate data structure that specifies that order. This example uses a separate sorted slice of keys to print a map[int]string in key order: may be the sentence should be below ``` Since Go in the runtime randomizes map iteration order ```",1.0,"blog: one sentence typo of blog go-maps-in-action - in blog https://blog.golang.org/go-maps-in-action section `Iteration order` >When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. Since Go 1 the runtime randomizes map iteration order, as programmers relied on the stable iteration order of the previous implementation. If you require a stable iteration order you must maintain a separate data structure that specifies that order. This example uses a separate sorted slice of keys to print a map[int]string in key order: may be the sentence should be below ``` Since Go in the runtime randomizes map iteration order ```",1,blog one sentence typo of blog go maps in action in blog section iteration order when iterating over a map with a range loop the iteration order is not specified and is not guaranteed to be the same from one iteration to the next since go the runtime randomizes map iteration order as programmers relied on the stable iteration order of the previous implementation if you require a stable iteration order you must maintain a separate data structure that specifies that order this example uses a separate sorted slice of keys to print a map string in key order may be the sentence should be below since go in the runtime randomizes map iteration order ,1 350441,24985036169.0,IssuesEvent,2022-11-02 14:30:44,golang/go,https://api.github.com/repos/golang/go,closed,doc: add guidelines for comment directives,Documentation NeedsInvestigation Tools,"This issue shares some resemblance with https://github.com/golang/go/issues/13560. It is about properly documenting a pretty widespread convention regarding comment text. In Go, `//go:` is reserved for the Go toolchain. This is documented at https://golang.org/cmd/compile/. It is unofficially encouraged that other Go tools use a similar ""namespace"" prefix for their comment directives. For example, `//gccgo:` or `//llgo:` for other compilers, `//lint:` for staticcheck, `//go-sumtype:` for another tool, and so on. See https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/tNZazPenX5cJ, as well as those two tools or others for examples out in the wild. I think we should more formally define what this format should look like, so that one can programmatically tell if a comment line is a directive. For example, one could imagine `^[a-z-]+:` as a regular expression. This would help tools which use directives be more consistent, as well as tools which want to inspect all comments and directives in source code. For example, gofumpt does this now, and it [takes some effort](https://github.com/mvdan/gofumpt/blob/eb0da8cc37e367dd519fd5ce98361f758a8b0508/format/format.go#L213-L225) to tell if a comment is a directive. I don't really mind where this is documented, as long as it's somewhere relatively authoritative. The wording doesn't have to be strong - after all, a Go comment can contain any plaintext. But it should still encourage tools to follow the format, for the sake of consistency.",1.0,"doc: add guidelines for comment directives - This issue shares some resemblance with https://github.com/golang/go/issues/13560. It is about properly documenting a pretty widespread convention regarding comment text. In Go, `//go:` is reserved for the Go toolchain. This is documented at https://golang.org/cmd/compile/. It is unofficially encouraged that other Go tools use a similar ""namespace"" prefix for their comment directives. For example, `//gccgo:` or `//llgo:` for other compilers, `//lint:` for staticcheck, `//go-sumtype:` for another tool, and so on. See https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/tNZazPenX5cJ, as well as those two tools or others for examples out in the wild. I think we should more formally define what this format should look like, so that one can programmatically tell if a comment line is a directive. For example, one could imagine `^[a-z-]+:` as a regular expression. This would help tools which use directives be more consistent, as well as tools which want to inspect all comments and directives in source code. For example, gofumpt does this now, and it [takes some effort](https://github.com/mvdan/gofumpt/blob/eb0da8cc37e367dd519fd5ce98361f758a8b0508/format/format.go#L213-L225) to tell if a comment is a directive. I don't really mind where this is documented, as long as it's somewhere relatively authoritative. The wording doesn't have to be strong - after all, a Go comment can contain any plaintext. But it should still encourage tools to follow the format, for the sake of consistency.",1,doc add guidelines for comment directives this issue shares some resemblance with it is about properly documenting a pretty widespread convention regarding comment text in go go is reserved for the go toolchain this is documented at it is unofficially encouraged that other go tools use a similar namespace prefix for their comment directives for example gccgo or llgo for other compilers lint for staticcheck go sumtype for another tool and so on see as well as those two tools or others for examples out in the wild i think we should more formally define what this format should look like so that one can programmatically tell if a comment line is a directive for example one could imagine as a regular expression this would help tools which use directives be more consistent as well as tools which want to inspect all comments and directives in source code for example gofumpt does this now and it to tell if a comment is a directive i don t really mind where this is documented as long as it s somewhere relatively authoritative the wording doesn t have to be strong after all a go comment can contain any plaintext but it should still encourage tools to follow the format for the sake of consistency ,1 49548,26202662882.0,IssuesEvent,2023-01-03 19:04:19,golang/go,https://api.github.com/repos/golang/go,closed,x/net/http2: WINDOW_UPDATE sent rate too high and can't be configured,Performance help wanted NeedsFix,"### What version of Go are you using (`go version`)? golang:1.10.0 linux ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? container: rhel kubenet: ### What did you do? Currently golang http2 stack will send WINDOW_UPDATE back when receive a request with data. It means a client will recevie a response and WINDOW_UPDATE when it send a request with data to golang http2 server. sent one 'request' package and got two 'reponse' package, that will impact client performance in a high load traffic. In fact, golang stack use 2^31 as default window size for connection. It is very big and updated too frequently is unnecessary. ### What did you expect to see? Change this behavior or make it configurable like other language http2 stack. I think c++/java popular http2 stack have a configurable rate (default is 50%) used for sending WINDOS_UPDATE frame when the rate of left size/total is less than it. ### What did you see instead? ",True,"x/net/http2: WINDOW_UPDATE sent rate too high and can't be configured - ### What version of Go are you using (`go version`)? golang:1.10.0 linux ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? container: rhel kubenet: ### What did you do? Currently golang http2 stack will send WINDOW_UPDATE back when receive a request with data. It means a client will recevie a response and WINDOW_UPDATE when it send a request with data to golang http2 server. sent one 'request' package and got two 'reponse' package, that will impact client performance in a high load traffic. In fact, golang stack use 2^31 as default window size for connection. It is very big and updated too frequently is unnecessary. ### What did you expect to see? Change this behavior or make it configurable like other language http2 stack. I think c++/java popular http2 stack have a configurable rate (default is 50%) used for sending WINDOS_UPDATE frame when the rate of left size/total is less than it. ### What did you see instead? ",0,x net window update sent rate too high and can t be configured what version of go are you using go version golang linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env container rhel kubenet what did you do currently golang stack will send window update back when receive a request with data it means a client will recevie a response and window update when it send a request with data to golang server sent one request package and got two reponse package that will impact client performance in a high load traffic in fact golang stack use as default window size for connection it is very big and updated too frequently is unnecessary what did you expect to see change this behavior or make it configurable like other language stack i think c java popular stack have a configurable rate default is used for sending windos update frame when the rate of left size total is less than it what did you see instead ,0 35089,6412119574.0,IssuesEvent,2017-08-08 01:48:27,golang/go,https://api.github.com/repos/golang/go,closed,flag: global Usage func disregards FlagSet.SetOutput,Documentation NeedsDecision,"### What version of Go are you using (`go version`)? ``` go version go1.8.2 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/vpoturaev/golang"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p5/fnl90gfx5_5f9599s3hpthfw0000gq/T/go-build760766867=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ```go package main import ( ""flag"" ""io/ioutil"" ""os"" ) func main() { var i int flag.IntVar(&i, ""i"", 2, ""sample int"") flag.CommandLine.SetOutput(ioutil.Discard) os.Args = []string{""app"", ""-i=1"", ""-unknown""} flag.Parse() } ``` https://play.golang.org/p/05pwqQu-3- ### What did you expect to see? No output ### What did you see instead? STDERR: ``` Usage of app: ``` `/usr/local/Cellar/go/1.8.2/libexec/src/flag/flag.go` ```go var Usage = func() { fmt.Fprintf(os.Stderr, ""Usage of %s:\n"", os.Args[0]) PrintDefaults() } ``` `Usage` function disregards `f.Out()` in favour of `os.Stderr`. The correct code should be: ```go var Usage = func() { fmt.Fprintf(f.out(), ""Usage of %s:\n"", os.Args[0]) PrintDefaults() } ```",1.0,"flag: global Usage func disregards FlagSet.SetOutput - ### What version of Go are you using (`go version`)? ``` go version go1.8.2 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/vpoturaev/golang"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.8.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.8.2/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/p5/fnl90gfx5_5f9599s3hpthfw0000gq/T/go-build760766867=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ```go package main import ( ""flag"" ""io/ioutil"" ""os"" ) func main() { var i int flag.IntVar(&i, ""i"", 2, ""sample int"") flag.CommandLine.SetOutput(ioutil.Discard) os.Args = []string{""app"", ""-i=1"", ""-unknown""} flag.Parse() } ``` https://play.golang.org/p/05pwqQu-3- ### What did you expect to see? No output ### What did you see instead? STDERR: ``` Usage of app: ``` `/usr/local/Cellar/go/1.8.2/libexec/src/flag/flag.go` ```go var Usage = func() { fmt.Fprintf(os.Stderr, ""Usage of %s:\n"", os.Args[0]) PrintDefaults() } ``` `Usage` function disregards `f.Out()` in favour of `os.Stderr`. The correct code should be: ```go var Usage = func() { fmt.Fprintf(f.out(), ""Usage of %s:\n"", os.Args[0]) PrintDefaults() } ```",1,flag global usage func disregards flagset setoutput what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users vpoturaev golang gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do go package main import flag io ioutil os func main var i int flag intvar i i sample int flag commandline setoutput ioutil discard os args string app i unknown flag parse what did you expect to see no output what did you see instead stderr usage of app usr local cellar go libexec src flag flag go go var usage func fmt fprintf os stderr usage of s n os args printdefaults usage function disregards f out in favour of os stderr the correct code should be go var usage func fmt fprintf f out usage of s n os args printdefaults ,1 47491,5895124924.0,IssuesEvent,2017-05-18 05:34:32,golang/go,https://api.github.com/repos/golang/go,closed,net: TestInterfaceHardwareAddrWithGetmac fails if Hyper-V bridges are present,HelpWanted NeedsFix OS-Windows Testing,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version devel +ec091b6 Mon Mar 13 23:43:16 2017 +0000 windows/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\dev\gopath set GORACE= set GOROOT=C:\gotip set GOTOOLDIR=C:\gotip\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\cygwin\tmp\go-build067613091=/tmp/go-build -gno-record-gcc-switches set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config ``` ### What did you do? `all.bat` ### What did you expect to see? Test success ### What did you see instead? Test failure: ``` --- FAIL: TestInterfaceHardwareAddrWithGetmac (1.22s) net_windows_test.go:599: getmac lists ""Ethernet 3"", but it could not be found among Go interfaces map[vEthernet (DockerNAT):0x:1x:5x:1x:7x:1x vEthernet (Hyper-V Bridge):1x:1x:0x:0x:6x:7x Teredo Tunneling Pseudo-Interface:00:00:00:00:00:00:00:e0 isatap.fritz.box:00:00:00:00:00:00:00:e0 isatap.{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX}:00:00:00:00:00:00:00:e0] FAIL FAIL net 6.980s ``` I guess it's a similar problem as in https://github.com/golang/go/issues/14130#issuecomment-181284033 although that was closed already. For me ""Ethernet 3"" does appear in the output of `getmac /fo list /v`, but, it does not appear in `ipconfig`. I assume it's caused by the presence of a Hyper-V bridge, that's the only unusual thing about my network configuration. ``` C:\>getmac /fo list /v Connection Name: vEthernet (Hyper-V Bridge) Network Adapter: Hyper-V Virtual Ethernet Adapter #2 Physical Address: 1X-1X-0X-0X-6X-7X Transport Name: \Device\Tcpip_{2XXXAXXX-3XXX-4XXX-AXXX-4XXX4XXX7XXX} Connection Name: vEthernet (DockerNAT) Network Adapter: Hyper-V Virtual Ethernet Adapter #3 Physical Address: 0X-1X-5X-1X-7X-1X Transport Name: \Device\Tcpip_{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX} Connection Name: Ethernet 3 Network Adapter: Realtek PCIe GBE Family Controller Physical Address: 1X-1X-0X-0X-6X-7X Transport Name: N/A C:\>ipconfig Windows IP Configuration Ethernet adapter vEthernet (DockerNAT): Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 10.0.X.X Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter vEthernet (Hyper-V Bridge): Connection-specific DNS Suffix . : fritz.box IPv6 Address. . . . . . . . . . . : 2XXX:eXXX:3XXX... Temporary IPv6 Address. . . . . . : 2XXX:eXXX:3XXX... Temporary IPv6 Address. . . . . . : 2XXX:eXXX:3XXX... Link-local IPv6 Address . . . . . : fe80::[...]%4 IPv4 Address. . . . . . . . . . . : 172.30.X.X Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : fe80::[...]%4 172.30.X.X Tunnel adapter Teredo Tunneling Pseudo-Interface: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Tunnel adapter isatap.fritz.box: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : fritz.box Tunnel adapter isatap.{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : ```",1.0,"net: TestInterfaceHardwareAddrWithGetmac fails if Hyper-V bridges are present - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version devel +ec091b6 Mon Mar 13 23:43:16 2017 +0000 windows/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\dev\gopath set GORACE= set GOROOT=C:\gotip set GOTOOLDIR=C:\gotip\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\cygwin\tmp\go-build067613091=/tmp/go-build -gno-record-gcc-switches set CXX=g++ set CGO_ENABLED=1 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config ``` ### What did you do? `all.bat` ### What did you expect to see? Test success ### What did you see instead? Test failure: ``` --- FAIL: TestInterfaceHardwareAddrWithGetmac (1.22s) net_windows_test.go:599: getmac lists ""Ethernet 3"", but it could not be found among Go interfaces map[vEthernet (DockerNAT):0x:1x:5x:1x:7x:1x vEthernet (Hyper-V Bridge):1x:1x:0x:0x:6x:7x Teredo Tunneling Pseudo-Interface:00:00:00:00:00:00:00:e0 isatap.fritz.box:00:00:00:00:00:00:00:e0 isatap.{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX}:00:00:00:00:00:00:00:e0] FAIL FAIL net 6.980s ``` I guess it's a similar problem as in https://github.com/golang/go/issues/14130#issuecomment-181284033 although that was closed already. For me ""Ethernet 3"" does appear in the output of `getmac /fo list /v`, but, it does not appear in `ipconfig`. I assume it's caused by the presence of a Hyper-V bridge, that's the only unusual thing about my network configuration. ``` C:\>getmac /fo list /v Connection Name: vEthernet (Hyper-V Bridge) Network Adapter: Hyper-V Virtual Ethernet Adapter #2 Physical Address: 1X-1X-0X-0X-6X-7X Transport Name: \Device\Tcpip_{2XXXAXXX-3XXX-4XXX-AXXX-4XXX4XXX7XXX} Connection Name: vEthernet (DockerNAT) Network Adapter: Hyper-V Virtual Ethernet Adapter #3 Physical Address: 0X-1X-5X-1X-7X-1X Transport Name: \Device\Tcpip_{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX} Connection Name: Ethernet 3 Network Adapter: Realtek PCIe GBE Family Controller Physical Address: 1X-1X-0X-0X-6X-7X Transport Name: N/A C:\>ipconfig Windows IP Configuration Ethernet adapter vEthernet (DockerNAT): Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 10.0.X.X Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter vEthernet (Hyper-V Bridge): Connection-specific DNS Suffix . : fritz.box IPv6 Address. . . . . . . . . . . : 2XXX:eXXX:3XXX... Temporary IPv6 Address. . . . . . : 2XXX:eXXX:3XXX... Temporary IPv6 Address. . . . . . : 2XXX:eXXX:3XXX... Link-local IPv6 Address . . . . . : fe80::[...]%4 IPv4 Address. . . . . . . . . . . : 172.30.X.X Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : fe80::[...]%4 172.30.X.X Tunnel adapter Teredo Tunneling Pseudo-Interface: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Tunnel adapter isatap.fritz.box: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : fritz.box Tunnel adapter isatap.{1XXX5XXX-DXXX-4XXX-9XXX-CXXX1XXX4XXX}: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : ```",0,net testinterfacehardwareaddrwithgetmac fails if hyper v bridges are present please answer these questions before submitting your issue thanks what version of go are you using go version go version devel mon mar windows what operating system and processor architecture are you using go env set goarch set gobin set goexe exe set gohostarch set gohostos windows set goos windows set gopath c dev gopath set gorace set goroot c gotip set gotooldir c gotip pkg tool windows set gccgo gccgo set cc gcc set gogccflags mthreads fmessage length fdebug prefix map c cygwin tmp go tmp go build gno record gcc switches set cxx g set cgo enabled set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config what did you do all bat what did you expect to see test success what did you see instead test failure fail testinterfacehardwareaddrwithgetmac net windows test go getmac lists ethernet but it could not be found among go interfaces map fail fail net i guess it s a similar problem as in although that was closed already for me ethernet does appear in the output of getmac fo list v but it does not appear in ipconfig i assume it s caused by the presence of a hyper v bridge that s the only unusual thing about my network configuration c getmac fo list v connection name vethernet hyper v bridge network adapter hyper v virtual ethernet adapter physical address transport name device tcpip axxx connection name vethernet dockernat network adapter hyper v virtual ethernet adapter physical address transport name device tcpip dxxx connection name ethernet network adapter realtek pcie gbe family controller physical address transport name n a c ipconfig windows ip configuration ethernet adapter vethernet dockernat connection specific dns suffix address x x subnet mask default gateway ethernet adapter vethernet hyper v bridge connection specific dns suffix fritz box address exxx temporary address exxx temporary address exxx link local address address x x subnet mask default gateway x x tunnel adapter teredo tunneling pseudo interface media state media disconnected connection specific dns suffix tunnel adapter isatap fritz box media state media disconnected connection specific dns suffix fritz box tunnel adapter isatap dxxx media state media disconnected connection specific dns suffix ,0 340752,30540418448.0,IssuesEvent,2023-07-19 20:52:15,golang/go,https://api.github.com/repos/golang/go,closed,net: TestInterfaceArrivalAndDepartureZoneCache is broken on linux-arm64 [1.19 backport],Testing CherryPickApproved,"@heschi requested issue #61414 to be considered for backport to the next 1.19 minor release. > @gopherbot please backport ",1.0,"net: TestInterfaceArrivalAndDepartureZoneCache is broken on linux-arm64 [1.19 backport] - @heschi requested issue #61414 to be considered for backport to the next 1.19 minor release. > @gopherbot please backport ",0,net testinterfacearrivalanddeparturezonecache is broken on linux heschi requested issue to be considered for backport to the next minor release gopherbot please backport ,0 92420,26681829578.0,IssuesEvent,2023-01-26 18:20:26,golang/go,https://api.github.com/repos/golang/go,closed,x/build/perfdata/db: unrecognized failures,Builders NeedsInvestigation,"``` #!watchflakes post <- pkg == ""golang.org/x/build/perfdata/db"" && test == """" ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/682b81e72837eb8390949271d8a208541d6765cb)): signal: segmentation fault — [watchflakes](https://go.dev/wiki/Watchflakes) ",1.0,"x/build/perfdata/db: unrecognized failures - ``` #!watchflakes post <- pkg == ""golang.org/x/build/perfdata/db"" && test == """" ``` Issue created automatically to collect these failures. Example ([log](https://build.golang.org/log/682b81e72837eb8390949271d8a208541d6765cb)): signal: segmentation fault — [watchflakes](https://go.dev/wiki/Watchflakes) ",0,x build perfdata db unrecognized failures watchflakes post pkg golang org x build perfdata db test issue created automatically to collect these failures example signal segmentation fault — ,0 53016,13101393788.0,IssuesEvent,2020-08-04 03:36:09,golang/go,https://api.github.com/repos/golang/go,opened,x/build/cmd/release: evaluate builders used for upcoming major Go release,Builders recurring release-blocker,"At the start of each code freeze, we should evaluate the builders used to make the upcoming major Go release, and confirm they are the most appropriate choice out of what is available. The start of a code freeze is a safe time to introduce a builder change, as it will be tested during pre-release versions, starting with beta 1 and onwards. Making this a release blocker for Go 1.16 (and not okay after beta 1—it needs to be done before). Once completed, this issue should be moved to the next major release milestone. /cc @golang/osp-team",1.0,"x/build/cmd/release: evaluate builders used for upcoming major Go release - At the start of each code freeze, we should evaluate the builders used to make the upcoming major Go release, and confirm they are the most appropriate choice out of what is available. The start of a code freeze is a safe time to introduce a builder change, as it will be tested during pre-release versions, starting with beta 1 and onwards. Making this a release blocker for Go 1.16 (and not okay after beta 1—it needs to be done before). Once completed, this issue should be moved to the next major release milestone. /cc @golang/osp-team",0,x build cmd release evaluate builders used for upcoming major go release at the start of each code freeze we should evaluate the builders used to make the upcoming major go release and confirm they are the most appropriate choice out of what is available the start of a code freeze is a safe time to introduce a builder change as it will be tested during pre release versions starting with beta and onwards making this a release blocker for go and not okay after beta —it needs to be done before once completed this issue should be moved to the next major release milestone cc golang osp team,0 211099,16419425204.0,IssuesEvent,2021-05-19 10:43:22,golang/go,https://api.github.com/repos/golang/go,closed,@mislav Documentation changes are fine.,Documentation,"@mislav Documentation changes are fine. @dawidgolunski As far as I can tell `exec.LookPath` on Windows does not search the directory from which the application loaded at all. It searches the current directory, then the directories on the environment variable `path`. I could imagine a `exec.LookPathStrict` proposal. Do you want to write one (https://golang.org/s/proposal)? It could perhaps ignore `.` or any relative directory on the `PATH`/`path`. _Originally posted by @ianlancetaylor in https://github.com/golang/go/issues/38736#issuecomment-718870248_",1.0,"@mislav Documentation changes are fine. - @mislav Documentation changes are fine. @dawidgolunski As far as I can tell `exec.LookPath` on Windows does not search the directory from which the application loaded at all. It searches the current directory, then the directories on the environment variable `path`. I could imagine a `exec.LookPathStrict` proposal. Do you want to write one (https://golang.org/s/proposal)? It could perhaps ignore `.` or any relative directory on the `PATH`/`path`. _Originally posted by @ianlancetaylor in https://github.com/golang/go/issues/38736#issuecomment-718870248_",1, mislav documentation changes are fine mislav documentation changes are fine dawidgolunski as far as i can tell exec lookpath on windows does not search the directory from which the application loaded at all it searches the current directory then the directories on the environment variable path i could imagine a exec lookpathstrict proposal do you want to write one it could perhaps ignore or any relative directory on the path path originally posted by ianlancetaylor in ,1 20416,4543340215.0,IssuesEvent,2016-09-10 03:01:53,golang/go,https://api.github.com/repos/golang/go,closed,x/crypto/scrypt: fix scrypt example,Documentation HelpWanted,"The scrypt code example doesn't work, as `scrypt.Key` also returns an error. `dk := scrypt.Key([]byte(""some password""), salt, 16384, 8, 1, 32)` --> `dk, err := scrypt.Key([]byte(""some password""), salt, 16384, 8, 1, 32)` https://github.com/golang/crypto/blob/05d11b2ca14108dfc7f74f4f66b28c7fe92e1fd0/scrypt/scrypt.go#L221",1.0,"x/crypto/scrypt: fix scrypt example - The scrypt code example doesn't work, as `scrypt.Key` also returns an error. `dk := scrypt.Key([]byte(""some password""), salt, 16384, 8, 1, 32)` --> `dk, err := scrypt.Key([]byte(""some password""), salt, 16384, 8, 1, 32)` https://github.com/golang/crypto/blob/05d11b2ca14108dfc7f74f4f66b28c7fe92e1fd0/scrypt/scrypt.go#L221",1,x crypto scrypt fix scrypt example the scrypt code example doesn t work as scrypt key also returns an error dk scrypt key byte some password salt dk err scrypt key byte some password salt ,1 16867,9541583752.0,IssuesEvent,2019-04-30 22:57:52,golang/go,https://api.github.com/repos/golang/go,closed,net/http: consider adding configurable buffer sizes to Transport,FeatureRequest NeedsDecision Performance,"### What version of Go are you using (`go version`)? go version devel +6e3a2b3 Tue Nov 7 15:04:53 2017 +0200 linux/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/nsoffer/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/nsoffer/go"" GORACE="""" GOROOT=""/home/nsoffer/src/go"" GOTMPDIR="""" GOTOOLDIR=""/home/nsoffer/src/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""gcc++"" CGO_ENABLED=""1"" 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-build316051983=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? Test uploading files over https, note low throughput compared with similar Python program. For example programs and benchmarks, see https://github.com/nirs/http-bench/tree/go-bufsize ### What did you expect to see? Being able to control buffer size used by http.Client, similar to the way you can control the buffer size in ``io.CopyBuffer``. ### What did you see instead? Hardcoded value hidden deep in the code and my free time being wasted locating it :). For example, here is output from strace: ``` [pid 32264] read(3, ""\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0""..., 4096) = 4096 [pid 32264] write(4, ""\27\3\3\20\30\0\0\0\0\0\3l\""w\201\360W\307F=\215Zj&\6hj\253\343\20EN""..., 4125) = 4125 ``` ### Use case An example use case is uploading vm images to storage, for example, [ovirt-imageio](https://github.com/ovirt/ovirt-imageio). ### Initial proposal Add Transport.WriteBufSize and Transport.ReadBufSize: https://go-review.googlesource.com/#/c/go/+/76410/ Example usage: ``` t := &http.Transport{WriteBufSize: 128*1024} client := &http.Client{Transport: t} ``` I tested the maximum benefit of this change by uploading data from /dev/zero to a server discarding the data. Here is an example upload using the default buffer size: ``` $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 25.13 seconds (407.49m/s) real 0m25.135s user 0m5.167s sys 0m11.643s ``` With this change, using 128k buffer size: ``` $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 7.93 seconds (1291.51m/s) real 0m7.935s user 0m4.517s sys 0m2.603s ``` Tested on Lenovo T450s Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz In real world usage the difference will be smaller, depending on the local and remote storage and the network. Similar enhancement was added lately to Python, see: https://github.com/python/cpython/commit/ad455cd9243319b896c86074ffeb3bf78a82f4ec ",True,"net/http: consider adding configurable buffer sizes to Transport - ### What version of Go are you using (`go version`)? go version devel +6e3a2b3 Tue Nov 7 15:04:53 2017 +0200 linux/amd64 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/nsoffer/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/nsoffer/go"" GORACE="""" GOROOT=""/home/nsoffer/src/go"" GOTMPDIR="""" GOTOOLDIR=""/home/nsoffer/src/go/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""gcc++"" CGO_ENABLED=""1"" 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-build316051983=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? Test uploading files over https, note low throughput compared with similar Python program. For example programs and benchmarks, see https://github.com/nirs/http-bench/tree/go-bufsize ### What did you expect to see? Being able to control buffer size used by http.Client, similar to the way you can control the buffer size in ``io.CopyBuffer``. ### What did you see instead? Hardcoded value hidden deep in the code and my free time being wasted locating it :). For example, here is output from strace: ``` [pid 32264] read(3, ""\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0""..., 4096) = 4096 [pid 32264] write(4, ""\27\3\3\20\30\0\0\0\0\0\3l\""w\201\360W\307F=\215Zj&\6hj\253\343\20EN""..., 4125) = 4125 ``` ### Use case An example use case is uploading vm images to storage, for example, [ovirt-imageio](https://github.com/ovirt/ovirt-imageio). ### Initial proposal Add Transport.WriteBufSize and Transport.ReadBufSize: https://go-review.googlesource.com/#/c/go/+/76410/ Example usage: ``` t := &http.Transport{WriteBufSize: 128*1024} client := &http.Client{Transport: t} ``` I tested the maximum benefit of this change by uploading data from /dev/zero to a server discarding the data. Here is an example upload using the default buffer size: ``` $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 25.13 seconds (407.49m/s) real 0m25.135s user 0m5.167s sys 0m11.643s ``` With this change, using 128k buffer size: ``` $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 7.93 seconds (1291.51m/s) real 0m7.935s user 0m4.517s sys 0m2.603s ``` Tested on Lenovo T450s Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz In real world usage the difference will be smaller, depending on the local and remote storage and the network. Similar enhancement was added lately to Python, see: https://github.com/python/cpython/commit/ad455cd9243319b896c86074ffeb3bf78a82f4ec ",0,net http consider adding configurable buffer sizes to transport what version of go are you using go version go version devel tue nov linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache home nsoffer cache go build goexe gohostarch gohostos linux goos linux gopath home nsoffer go gorace goroot home nsoffer src go gotmpdir gotooldir home nsoffer src go pkg tool linux gccgo gccgo cc gcc cxx gcc cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do test uploading files over https note low throughput compared with similar python program for example programs and benchmarks see what did you expect to see being able to control buffer size used by http client similar to the way you can control the buffer size in io copybuffer what did you see instead hardcoded value hidden deep in the code and my free time being wasted locating it for example here is output from strace read write w use case an example use case is uploading vm images to storage for example initial proposal add transport writebufsize and transport readbufsize example usage t http transport writebufsize client http client transport t i tested the maximum benefit of this change by uploading data from dev zero to a server discarding the data here is an example upload using the default buffer size time upload uploaded in seconds s real user sys with this change using buffer size time upload uploaded in seconds s real user sys tested on lenovo intel r core tm cpu in real world usage the difference will be smaller depending on the local and remote storage and the network similar enhancement was added lately to python see ,0 36722,9881724655.0,IssuesEvent,2019-06-24 15:15:18,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gopherbot: remove NeedsDecision on proposals,Builders NeedsFix,"Per @golang/proposal-review, the bot should remove NeedsDecision on proposals. It's redundant and messes with searches.",1.0,"x/build/cmd/gopherbot: remove NeedsDecision on proposals - Per @golang/proposal-review, the bot should remove NeedsDecision on proposals. It's redundant and messes with searches.",0,x build cmd gopherbot remove needsdecision on proposals per golang proposal review the bot should remove needsdecision on proposals it s redundant and messes with searches ,0 270091,20573993202.0,IssuesEvent,2022-03-04 01:08:59,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: add proper documentation for workspace mode,Documentation NeedsFix GoCommand,"Add full docs for each of the go work subcommands, a doc for getting started on workspace mode, and a reference-style document.",1.0,"cmd/go: add proper documentation for workspace mode - Add full docs for each of the go work subcommands, a doc for getting started on workspace mode, and a reference-style document.",1,cmd go add proper documentation for workspace mode add full docs for each of the go work subcommands a doc for getting started on workspace mode and a reference style document ,1 23667,4964368251.0,IssuesEvent,2016-12-03 18:48:50,golang/go,https://api.github.com/repos/golang/go,opened,net: can Conn.Close block?,Documentation NeedsDecision,"The documentation for `net.Conn.Close` is: > Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. However, it does not mention anything about whether `Close` itself can block. Some `net.Conn` implementations have an implicit write buffer. Thus, when `Close` is called, it still needs to flush the buffer before returning. This means that `Close` is effectively an operation that involves IO. Since it involves IO, this means that `Close` may have to wait until the recipient acknowledges the incoming data (which could potentially be forever if the receiver's read buffer is full). If we extend the documentation for `net.Conn.Close`, would the following be reasonable? > Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. Close itself may block while it is flushing any internal write buffers, but must return an error when a previously set deadline has been exceeded. \cc @bradfitz @mikioh ",1.0,"net: can Conn.Close block? - The documentation for `net.Conn.Close` is: > Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. However, it does not mention anything about whether `Close` itself can block. Some `net.Conn` implementations have an implicit write buffer. Thus, when `Close` is called, it still needs to flush the buffer before returning. This means that `Close` is effectively an operation that involves IO. Since it involves IO, this means that `Close` may have to wait until the recipient acknowledges the incoming data (which could potentially be forever if the receiver's read buffer is full). If we extend the documentation for `net.Conn.Close`, would the following be reasonable? > Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. Close itself may block while it is flushing any internal write buffers, but must return an error when a previously set deadline has been exceeded. \cc @bradfitz @mikioh ",1,net can conn close block the documentation for net conn close is close closes the connection any blocked read or write operations will be unblocked and return errors however it does not mention anything about whether close itself can block some net conn implementations have an implicit write buffer thus when close is called it still needs to flush the buffer before returning this means that close is effectively an operation that involves io since it involves io this means that close may have to wait until the recipient acknowledges the incoming data which could potentially be forever if the receiver s read buffer is full if we extend the documentation for net conn close would the following be reasonable close closes the connection any blocked read or write operations will be unblocked and return errors close itself may block while it is flushing any internal write buffers but must return an error when a previously set deadline has been exceeded cc bradfitz mikioh ,1 32555,6086436434.0,IssuesEvent,2017-06-18 01:00:11,golang/go,https://api.github.com/repos/golang/go,closed,Website. Documentation,Documentation,"Please clarify the language for Go comments, Git comments in *Contribution Guide* https://golang.org/doc/contribute.html In my point of view, the Go project expected - English language.",1.0,"Website. Documentation - Please clarify the language for Go comments, Git comments in *Contribution Guide* https://golang.org/doc/contribute.html In my point of view, the Go project expected - English language.",1,website documentation please clarify the language for go comments git comments in contribution guide in my point of view the go project expected english language ,1 387185,26715071814.0,IssuesEvent,2023-01-28 11:53:30,golang/go,https://api.github.com/repos/golang/go,closed,doc: clarify fetching Go 1.4 from git,Documentation help wanted NeedsFix,"A decision seems to have been made to no longer provide version controlled 1.4.x source code for doing a clean Go bootstrap on macOS. Is this true? You need a special tarball? How should the the current state of affairs for source code bootstrapping be characterized? I think the comment that kinda shook me was: @ianlancetaylor `I suppose I am mildly in favor of doing a 1.4.4 release for better Darwin support going forward.` Currently to get close to a clean bootstrap you have to download a special tarball. A doc change was made to fix the bootstrap issue. But on my system that *special version* of 1.4.3 builds but doesn't pass tests. It will build 10.2 however. **What really gets me in the craw is the atavistic reversion to a tarball instead of using git and version control.** Yes, I know I could have used my existing Go 10.1 to compile 10.2. Is that what everyone else does now? Perhaps the pain level of maintaining the 1.4 bootstrap has been reached? Maybe it is time to retire the 1.4 bootstrap and just use archived binaries of previous versions of Go? I think there is some risk and complexity with that approach too, but it's a valid approach, and I could live with it. Whatever the decision is, it should be an explicit decision, not something the team slumps into because no one wants to maintain the bootstrap anymore. tl;dr version below. I recently got a new MacBook Pro. Previously I was running macOS 10.10 on my beloved MBP 17"" but the new laptop came with High Sierra, macOS 10.13.5 and the Go team had just issued 10.2. Time to update. I am a build from source kinda guy so I did the `git pull` and `all.bash`. Building Go cmd/dist using /Volumes/std/usr/leb/go1.4. failed MSpanList_Insert 0x783000 0xffd30d60dd0 0x0 fatal error: MSpanList_Insert Check to see if there is a newer bootstrap version. There is a 1.4.3. Get that. Build it. Same thing. Look around, it's a High Sierra issue and Go issue 16352 seems to have the answers. https://github.com/golang/go/issues/16352 https://github.com/golang/go/issues/17335 https://github.com/golang/go/issues/17182 So now I need to download a tarball to bootstrap? That's what the doc says. Oh, they fixed it with a tarball and a doc change. To build a bootstrap toolchain from source, use either the git branch release-branch.go1.4 or go1.4-bootstrap-20171003.tar.gz, which contains the Go 1.4 source code plus accumulated fixes to keep the tools running on newer operating systems. Download the tarball. Have some kind of issue but I update Xcode and all is OK. At least it builds this time but now it fails with a timezone issue. ok text/template/parse 0.015s --- FAIL: TestParseInLocation-11 (0.00s) format_test.go:202: ParseInLocation(Feb 01 2013 AST, Baghdad) = 2013-02-01 00:00:00 +0000 AST, want 2013-02-01 00:00:00 +0300 +03 Check that error out. It's a known issue because the timezone data changed and the test isn't fixed in the tarball. https://github.com/golang/go/issues/19457 I replace the `TestParseInLocation in the tarball with the one from 10.2 and it works. **Wow this was painful and when building 10.2 I still get an error on my machine.** --- FAIL: TestRespectSetgidDir (0.00s) build_test.go:225: moveOrCopyFile(""/var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"", ""/var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576""): want ""cp /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576 /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"", got ""mv /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576 /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"" FAIL FAIL cmd/go/internal/work 0.025s which is also supposedly fixed but has been failing on my previous laptop even with 10.10. I will try to figure out what is going on with that. Maybe something to do with being a member of multiple groups? IDK. That's a different issue and I get the feeling it may be specific to my setup.",1.0,"doc: clarify fetching Go 1.4 from git - A decision seems to have been made to no longer provide version controlled 1.4.x source code for doing a clean Go bootstrap on macOS. Is this true? You need a special tarball? How should the the current state of affairs for source code bootstrapping be characterized? I think the comment that kinda shook me was: @ianlancetaylor `I suppose I am mildly in favor of doing a 1.4.4 release for better Darwin support going forward.` Currently to get close to a clean bootstrap you have to download a special tarball. A doc change was made to fix the bootstrap issue. But on my system that *special version* of 1.4.3 builds but doesn't pass tests. It will build 10.2 however. **What really gets me in the craw is the atavistic reversion to a tarball instead of using git and version control.** Yes, I know I could have used my existing Go 10.1 to compile 10.2. Is that what everyone else does now? Perhaps the pain level of maintaining the 1.4 bootstrap has been reached? Maybe it is time to retire the 1.4 bootstrap and just use archived binaries of previous versions of Go? I think there is some risk and complexity with that approach too, but it's a valid approach, and I could live with it. Whatever the decision is, it should be an explicit decision, not something the team slumps into because no one wants to maintain the bootstrap anymore. tl;dr version below. I recently got a new MacBook Pro. Previously I was running macOS 10.10 on my beloved MBP 17"" but the new laptop came with High Sierra, macOS 10.13.5 and the Go team had just issued 10.2. Time to update. I am a build from source kinda guy so I did the `git pull` and `all.bash`. Building Go cmd/dist using /Volumes/std/usr/leb/go1.4. failed MSpanList_Insert 0x783000 0xffd30d60dd0 0x0 fatal error: MSpanList_Insert Check to see if there is a newer bootstrap version. There is a 1.4.3. Get that. Build it. Same thing. Look around, it's a High Sierra issue and Go issue 16352 seems to have the answers. https://github.com/golang/go/issues/16352 https://github.com/golang/go/issues/17335 https://github.com/golang/go/issues/17182 So now I need to download a tarball to bootstrap? That's what the doc says. Oh, they fixed it with a tarball and a doc change. To build a bootstrap toolchain from source, use either the git branch release-branch.go1.4 or go1.4-bootstrap-20171003.tar.gz, which contains the Go 1.4 source code plus accumulated fixes to keep the tools running on newer operating systems. Download the tarball. Have some kind of issue but I update Xcode and all is OK. At least it builds this time but now it fails with a timezone issue. ok text/template/parse 0.015s --- FAIL: TestParseInLocation-11 (0.00s) format_test.go:202: ParseInLocation(Feb 01 2013 AST, Baghdad) = 2013-02-01 00:00:00 +0000 AST, want 2013-02-01 00:00:00 +0300 +03 Check that error out. It's a known issue because the timezone data changed and the test isn't fixed in the tarball. https://github.com/golang/go/issues/19457 I replace the `TestParseInLocation in the tarball with the one from 10.2 and it works. **Wow this was painful and when building 10.2 I still get an error on my machine.** --- FAIL: TestRespectSetgidDir (0.00s) build_test.go:225: moveOrCopyFile(""/var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"", ""/var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576""): want ""cp /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576 /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"", got ""mv /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/pkgfile074436576 /var/folders/95/zwjzrdwc8xj7yg001s6slck80000gn/T/SetGroupID592840517/setgid"" FAIL FAIL cmd/go/internal/work 0.025s which is also supposedly fixed but has been failing on my previous laptop even with 10.10. I will try to figure out what is going on with that. Maybe something to do with being a member of multiple groups? IDK. That's a different issue and I get the feeling it may be specific to my setup.",1,doc clarify fetching go from git a decision seems to have been made to no longer provide version controlled x source code for doing a clean go bootstrap on macos is this true you need a special tarball how should the the current state of affairs for source code bootstrapping be characterized i think the comment that kinda shook me was ianlancetaylor i suppose i am mildly in favor of doing a release for better darwin support going forward currently to get close to a clean bootstrap you have to download a special tarball a doc change was made to fix the bootstrap issue but on my system that special version of builds but doesn t pass tests it will build however what really gets me in the craw is the atavistic reversion to a tarball instead of using git and version control yes i know i could have used my existing go to compile is that what everyone else does now perhaps the pain level of maintaining the bootstrap has been reached maybe it is time to retire the bootstrap and just use archived binaries of previous versions of go i think there is some risk and complexity with that approach too but it s a valid approach and i could live with it whatever the decision is it should be an explicit decision not something the team slumps into because no one wants to maintain the bootstrap anymore tl dr version below i recently got a new macbook pro previously i was running macos on my beloved mbp but the new laptop came with high sierra macos and the go team had just issued time to update i am a build from source kinda guy so i did the git pull and all bash building go cmd dist using volumes std usr leb failed mspanlist insert fatal error mspanlist insert check to see if there is a newer bootstrap version there is a get that build it same thing look around it s a high sierra issue and go issue seems to have the answers so now i need to download a tarball to bootstrap that s what the doc says oh they fixed it with a tarball and a doc change to build a bootstrap toolchain from source use either the git branch release branch or bootstrap tar gz which contains the go source code plus accumulated fixes to keep the tools running on newer operating systems download the tarball have some kind of issue but i update xcode and all is ok at least it builds this time but now it fails with a timezone issue ok text template parse fail testparseinlocation format test go parseinlocation feb ast baghdad ast want check that error out it s a known issue because the timezone data changed and the test isn t fixed in the tarball i replace the testparseinlocation in the tarball with the one from and it works wow this was painful and when building i still get an error on my machine fail testrespectsetgiddir build test go moveorcopyfile var folders t setgid var folders t want cp var folders t var folders t setgid got mv var folders t var folders t setgid fail fail cmd go internal work which is also supposedly fixed but has been failing on my previous laptop even with i will try to figure out what is going on with that maybe something to do with being a member of multiple groups idk that s a different issue and i get the feeling it may be specific to my setup ,1 182564,14917832723.0,IssuesEvent,2021-01-22 20:33:34,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: include a link to useful docs in the workspace load error notification,Documentation Tools gopls," This notification is pretty nice! But for users who are not familiar with modules and nested modules (is it official terminology?), this message may still sound cryptic. Link to any useful documentation would be helpful.",1.0,"x/tools/gopls: include a link to useful docs in the workspace load error notification - This notification is pretty nice! But for users who are not familiar with modules and nested modules (is it official terminology?), this message may still sound cryptic. Link to any useful documentation would be helpful.",1,x tools gopls include a link to useful docs in the workspace load error notification img width alt screen shot at pm src this notification is pretty nice but for users who are not familiar with modules and nested modules is it official terminology this message may still sound cryptic link to any useful documentation would be helpful ,1 262034,19759202042.0,IssuesEvent,2022-01-16 05:15:59,golang/go,https://api.github.com/repos/golang/go,closed,strings: typo in comment,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
1.17.5 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/hlushch/Library/Caches/go-build""
GOENV=""/Users/hlushch/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/hlushch/Projects/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/hlushch/Projects/go/""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.17.5/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.17.5/libexec/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.17.5""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nz/cqlmbdfs23schf6ndmr7gz440000gn/T/go-build2546855830=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Went to L20C51 in src/strings/builder.go ### What did you expect to see? No extra whitespace ### What did you see instead? Unneeded whitespace ",1.0,"strings: typo in comment - ### What version of Go are you using (`go version`)? 
$ go version
1.17.5 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/hlushch/Library/Caches/go-build""
GOENV=""/Users/hlushch/Library/Application Support/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOINSECURE=""""
GOMODCACHE=""/Users/hlushch/Projects/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/hlushch/Projects/go/""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/Cellar/go/1.17.5/libexec""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.17.5/libexec/pkg/tool/darwin_amd64""
GOVCS=""""
GOVERSION=""go1.17.5""
GCCGO=""gccgo""
AR=""ar""
CC=""clang""
CXX=""clang++""
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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nz/cqlmbdfs23schf6ndmr7gz440000gn/T/go-build2546855830=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Went to L20C51 in src/strings/builder.go ### What did you expect to see? No extra whitespace ### What did you see instead? Unneeded whitespace ",1,strings typo in comment please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users hlushch library caches go build goenv users hlushch library application support go env goexe goexperiment goflags gohostarch gohostos darwin goinsecure gomodcache users hlushch projects go pkg mod gonoproxy gonosumdb goos darwin gopath users hlushch projects go goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin govcs goversion gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod dev null cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic arch pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders nz t go tmp go build gno record gcc switches fno common what did you do went to in src strings builder go what did you expect to see no extra whitespace what did you see instead unneeded whitespace ,1 119675,12036834257.0,IssuesEvent,2020-04-13 20:34:51,golang/go,https://api.github.com/repos/golang/go,closed,errors: example code for errors.As has extraneous code,Documentation NeedsInvestigation,"The example code for `errors.As` (viewed at https://pkg.go.dev/errors?tab=doc#As) is the [entire contents of the `wrap_test.go` file](https://github.com/golang/go/blob/go1.14.1/src/errors/wrap_test.go). It should be just `func ExampleAs() { ... }` I presume. In talking this over with @FiloSottile, this may be a more systemic issue which can be improved in `godoc`. For example, we have the same issue with the [chacha20poly1305.NewX](https://pkg.go.dev/golang.org/x/crypto/chacha20poly1305?tab=doc#NewX) example code. However, perhaps we should fix the example for the errors package for now either way. While we're in there, perhaps we should check if there are any improvements to the documentation for errors as tracked in https://github.com/golang/go/issues/31716. /cc @jba @mpvl ",1.0,"errors: example code for errors.As has extraneous code - The example code for `errors.As` (viewed at https://pkg.go.dev/errors?tab=doc#As) is the [entire contents of the `wrap_test.go` file](https://github.com/golang/go/blob/go1.14.1/src/errors/wrap_test.go). It should be just `func ExampleAs() { ... }` I presume. In talking this over with @FiloSottile, this may be a more systemic issue which can be improved in `godoc`. For example, we have the same issue with the [chacha20poly1305.NewX](https://pkg.go.dev/golang.org/x/crypto/chacha20poly1305?tab=doc#NewX) example code. However, perhaps we should fix the example for the errors package for now either way. While we're in there, perhaps we should check if there are any improvements to the documentation for errors as tracked in https://github.com/golang/go/issues/31716. /cc @jba @mpvl ",1,errors example code for errors as has extraneous code the example code for errors as viewed at is the it should be just func exampleas i presume in talking this over with filosottile this may be a more systemic issue which can be improved in godoc for example we have the same issue with the example code however perhaps we should fix the example for the errors package for now either way while we re in there perhaps we should check if there are any improvements to the documentation for errors as tracked in cc jba mpvl ,1 173234,14405922071.0,IssuesEvent,2020-12-03 19:26:31,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document path and path/filepath changes for Go 1.16,Documentation NeedsInvestigation release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
path

TODO: https://golang.org/cl/264397: validate patterns in Match, Glob

path/filepath

TODO: https://golang.org/cl/264397: validate patterns in Match, Glob

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document path and path/filepath changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:
path

TODO: https://golang.org/cl/264397: validate patterns in Match, Glob

path/filepath

TODO: https://golang.org/cl/264397: validate patterns in Match, Glob

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document path and path filepath changes for go as of filing this issue the contained the following html path todo a href validate patterns in match glob path filepath todo a href validate patterns in match glob per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 46754,7278778137.0,IssuesEvent,2018-02-22 00:33:50,golang/go,https://api.github.com/repos/golang/go,opened,transfer label descriptions from wiki to labels themselves,Documentation,"Now that GitHub [added descriptions to labels](https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more), it would probably be helpful to transfer the label descriptions from https://github.com/golang/go/wiki/IssueLabels to the labels themselves. I think it would make it easier for more people to discover what the labels mean. If we do this, I think the wiki page should be removed, to avoid having to maintain same information in two places. This issue is to consider/discuss this opportunity.",1.0,"transfer label descriptions from wiki to labels themselves - Now that GitHub [added descriptions to labels](https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more), it would probably be helpful to transfer the label descriptions from https://github.com/golang/go/wiki/IssueLabels to the labels themselves. I think it would make it easier for more people to discover what the labels mean. If we do this, I think the wiki page should be removed, to avoid having to maintain same information in two places. This issue is to consider/discuss this opportunity.",1,transfer label descriptions from wiki to labels themselves now that github it would probably be helpful to transfer the label descriptions from to the labels themselves i think it would make it easier for more people to discover what the labels mean if we do this i think the wiki page should be removed to avoid having to maintain same information in two places this issue is to consider discuss this opportunity ,1 96546,27881290096.0,IssuesEvent,2023-03-21 19:37:51,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/release: Go installer failing on macos ventura ,Builders WaitingForInfo NeedsInvestigation," Version : go1.20.1 , impossible for me to install Go on my computer, each time this message appears. ",1.0,"x/build/cmd/release: Go installer failing on macos ventura - Version : go1.20.1 , impossible for me to install Go on my computer, each time this message appears. ",0,x build cmd release go installer failing on macos ventura version impossible for me to install go on my computer each time this message appears img width alt capture d’écran à src ,0 95612,10883718213.0,IssuesEvent,2019-11-18 06:03:44,golang/go,https://api.github.com/repos/golang/go,closed,wiki: recommended Ubuntu port still does not have security fix release,Documentation NeedsInvestigation help wanted,"Per https://github.com/golang/go/wiki/Ubuntu, the recommended Ubuntu 18.04 apt source is `longsleep/golang-backports`. As of 5pm Pacific on October 22, that port does not have the Go 1.13.2 or Go 1.13.3 releases. I'm not sure if this is the right place - if someone on the Go team maintains that package - but it seems bad that a recommended resource is not up to date several days after a security release. It would be nice to maybe see instructions about what goes into the `.deb` file so we can reproduce it/upload on our own.",1.0,"wiki: recommended Ubuntu port still does not have security fix release - Per https://github.com/golang/go/wiki/Ubuntu, the recommended Ubuntu 18.04 apt source is `longsleep/golang-backports`. As of 5pm Pacific on October 22, that port does not have the Go 1.13.2 or Go 1.13.3 releases. I'm not sure if this is the right place - if someone on the Go team maintains that package - but it seems bad that a recommended resource is not up to date several days after a security release. It would be nice to maybe see instructions about what goes into the `.deb` file so we can reproduce it/upload on our own.",1,wiki recommended ubuntu port still does not have security fix release per the recommended ubuntu apt source is longsleep golang backports as of pacific on october that port does not have the go or go releases i m not sure if this is the right place if someone on the go team maintains that package but it seems bad that a recommended resource is not up to date several days after a security release it would be nice to maybe see instructions about what goes into the deb file so we can reproduce it upload on our own ,1 6074,3000686612.0,IssuesEvent,2015-07-24 04:41:01,golang/go,https://api.github.com/repos/golang/go,opened,doc: document the way the tools work,Documentation,"Nowhere is it explained how go build constructs software: how the compiler and linker run, where files are placed, how test builds its code, and so on. There should be an implementation and explanation document outlining this process. Such a document would also help someone who must use Go from within an existing software construction system. ",1.0,"doc: document the way the tools work - Nowhere is it explained how go build constructs software: how the compiler and linker run, where files are placed, how test builds its code, and so on. There should be an implementation and explanation document outlining this process. Such a document would also help someone who must use Go from within an existing software construction system. ",1,doc document the way the tools work nowhere is it explained how go build constructs software how the compiler and linker run where files are placed how test builds its code and so on there should be an implementation and explanation document outlining this process such a document would also help someone who must use go from within an existing software construction system ,1 120215,12061456437.0,IssuesEvent,2020-04-15 23:51:39,golang/go,https://api.github.com/repos/golang/go,closed,Need for Improvements on Documentation of io.Copy,Documentation WaitingForInfo,"Hey Guys, Recently I've been studying a lot about system calls and I noticed that The standard library uses many of then to increase performance, like on io.Copy when if Reader is a file, Writer a TCPConn and the OS is linux, freebsd or windows, it uses sendfile or splice. Another example is this issue to be implemented https://github.com/golang/go/issues/36817. But I feel these different paths are not clear enough on documentation. Example: On io.Copy: https://github.com/golang/go/blob/34e38ac99f025549599ea7e1ad2e80026ae16174/src/io/io.go#L363-L367 On net.TCPConn.ReadFrom: https://github.com/golang/go/blob/34e38ac99f025549599ea7e1ad2e80026ae16174/src/net/tcpsock.go#L98-L99 If the programmer doesn't read all the code, he never will realize what the code is doing. Like he will never know that his solution isn't copying the file to userspace but it's just sending from page cache to socket. I would like to know if we can describe these cases on io.Copy comments or create a wiki about this topic? What is the best approach to spread this knowledge? Thanks a lot :) and it's my first issue on this project, if I've done something wrong let me know ;)",1.0,"Need for Improvements on Documentation of io.Copy - Hey Guys, Recently I've been studying a lot about system calls and I noticed that The standard library uses many of then to increase performance, like on io.Copy when if Reader is a file, Writer a TCPConn and the OS is linux, freebsd or windows, it uses sendfile or splice. Another example is this issue to be implemented https://github.com/golang/go/issues/36817. But I feel these different paths are not clear enough on documentation. Example: On io.Copy: https://github.com/golang/go/blob/34e38ac99f025549599ea7e1ad2e80026ae16174/src/io/io.go#L363-L367 On net.TCPConn.ReadFrom: https://github.com/golang/go/blob/34e38ac99f025549599ea7e1ad2e80026ae16174/src/net/tcpsock.go#L98-L99 If the programmer doesn't read all the code, he never will realize what the code is doing. Like he will never know that his solution isn't copying the file to userspace but it's just sending from page cache to socket. I would like to know if we can describe these cases on io.Copy comments or create a wiki about this topic? What is the best approach to spread this knowledge? Thanks a lot :) and it's my first issue on this project, if I've done something wrong let me know ;)",1,need for improvements on documentation of io copy hey guys recently i ve been studying a lot about system calls and i noticed that the standard library uses many of then to increase performance like on io copy when if reader is a file writer a tcpconn and the os is linux freebsd or windows it uses sendfile or splice another example is this issue to be implemented but i feel these different paths are not clear enough on documentation example on io copy on net tcpconn readfrom if the programmer doesn t read all the code he never will realize what the code is doing like he will never know that his solution isn t copying the file to userspace but it s just sending from page cache to socket i would like to know if we can describe these cases on io copy comments or create a wiki about this topic what is the best approach to spread this knowledge thanks a lot and it s my first issue on this project if i ve done something wrong let me know ,1 11594,3508093615.0,IssuesEvent,2016-01-08 16:20:33,golang/go,https://api.github.com/repos/golang/go,closed,net: inconsistent documentation for Listen addrs.,Documentation,"See http://golang.org/pkg/net/. The example in the Overview section says: The Listen function creates servers: ln, err := net.Listen(""tcp"", "":8080"") The comment for `Listen` says: See Dial for the syntax of laddr. The comment for `Dial` says: For TCP and UDP networks, addresses have the form host:port. This contradicts the example in the Overview section, which elides the host. Assuming the Overview example is correct, the comment for `Dial` comment should be updated to describe what happens if the host and/or port is omitted.",1.0,"net: inconsistent documentation for Listen addrs. - See http://golang.org/pkg/net/. The example in the Overview section says: The Listen function creates servers: ln, err := net.Listen(""tcp"", "":8080"") The comment for `Listen` says: See Dial for the syntax of laddr. The comment for `Dial` says: For TCP and UDP networks, addresses have the form host:port. This contradicts the example in the Overview section, which elides the host. Assuming the Overview example is correct, the comment for `Dial` comment should be updated to describe what happens if the host and/or port is omitted.",1,net inconsistent documentation for listen addrs see the example in the overview section says the listen function creates servers ln err net listen tcp the comment for listen says see dial for the syntax of laddr the comment for dial says for tcp and udp networks addresses have the form host port this contradicts the example in the overview section which elides the host assuming the overview example is correct the comment for dial comment should be updated to describe what happens if the host and or port is omitted ,1 5033,2900264605.0,IssuesEvent,2015-06-17 15:36:49,golang/go,https://api.github.com/repos/golang/go,closed,doc: extract examples from tests,Documentation,"I suggest digging tests and extract meaningful examples from them. If approved, I can produce a set of CLs for that.",1.0,"doc: extract examples from tests - I suggest digging tests and extract meaningful examples from them. If approved, I can produce a set of CLs for that.",1,doc extract examples from tests i suggest digging tests and extract meaningful examples from them if approved i can produce a set of cls for that ,1 55271,30662695877.0,IssuesEvent,2023-07-25 15:59:42,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: duplicated analysis work,gopls Tools gopls/performance,"The following log events were observed in a single run of ""gopls check"" (with staticcheck and nilness enabled) that was instrumented to report start/end calls to Analyze: ```go t0 := time.Now() log.Println(""Analyze start"", analyzers, pkgs, t0) defer func() { log.Println(""Analyze end"", analyzers, pkgs, t0, time.Since(t0)) // repeat t0 so we can tie start/end together }() ``` Observe that two concurrent Analyze calls request that the same package be analyzed with two different sets of analyzers. ``` ec2$ (cd ~/w/xtools && go build -o x ./gopls ) && time ~/w/xtools/x --profile.cpu=prof check ./internal/customizations/unit_test.go 2023/07/21 11:38:11 Analyze start [structtag stdmethods lostcancel unusedresult unusedparams copylocks unusedwrite timeformat buildtag bools embed shift sortslice loopclosure simplifyslice useany cgocall errorsas simplifyrange printf fieldalignment atomicalign unsafeptr assign testinggoroutine nilness ifaceassert composites nilfunc unmarshal directive stringintconv atomic simplifycompositelit deepequalerrors httpresponse unreachable asmdecl shadow tests QF1012 SA9002 S1007 ST1019 ST1021 ST1003 SA9005 SA1015 QF1010 SA9004 SA1029 SA4006 ST1000 QF1005 SA1019 SA1021 ST1013 SA1026 QF1002 ST1005 SA4030 SA9007 S1034 SA4016 SA1014 SA5002 SA1007 SA4021 SA4005 SA5001 SA1025 S1035 S1010 SA5000 SA1024 S1011 SA4014 SA6005 SA6001 S1018 SA2001 SA4009 SA5008 ST1016 S1028 S1006 QF1007 SA9003 SA4010 ST1012 QF1003 SA1000 S1005 ST1022 SA5004 S1000 S1023 QF1011 S1029 SA4024 SA1020 S1009 SA2002 SA4011 SA1030 SA4022 QF1006 S1038 SA4000 SA5007 S1020 S1031 S1021 S1032 SA1010 QF1004 ST1001 SA4029 SA1001 SA1012 S1016 SA1013 SA4012 SA4025 ST1023 S1003 SA1008 SA4013 S1017 SA4019 SA1023 SA4026 QF1008 SA9008 S1037 SA6003 SA1016 SA4008 ST1011 ST1018 SA1003 SA4001 QF1001 ST1017 S1002 S1040 SA1028 SA4018 SA1027 SA1004 SA3001 SA5003 S1039 SA1017 S1036 S1024 QF1009 ST1020 S1008 SA4015 SA2003 S1001 SA4003 SA4028 SA1006 SA4023 SA1011 SA5005 SA5010 S1030 SA6000 S1004 SA4017 SA9006 SA4004 SA2000 SA1002 SA6002 SA5012 SA1005 SA9001 SA3000 ST1008 SA1018 S1033 ST1006 SA4031 SA4020 ST1015 S1019 S1012 SA4027 S1025 nonewvars noresultvalues undeclaredname unusedvariable fillreturns] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:11.38853 -0400 EDT m=+0.728676834 2023/07/21 11:38:12 Analyze start [bools embed shift sortslice loopclosure simplifyslice unsafeptr useany cgocall errorsas simplifyrange printf fieldalignment atomicalign assign testinggoroutine nilness ifaceassert composites nilfunc unmarshal directive stringintconv atomic simplifycompositelit deepequalerrors httpresponse unreachable asmdecl shadow tests structtag stdmethods lostcancel unusedresult unusedparams copylocks unusedwrite timeformat buildtag SA4000 SA5007 S1020 S1031 S1021 S1032 SA1010 QF1004 ST1001 SA4029 SA1001 SA1012 S1016 SA1013 SA4012 SA4025 ST1023 S1003 SA1008 SA4013 S1017 SA4019 SA1023 SA4026 QF1008 SA9008 S1037 SA6003 SA1016 SA4008 ST1011 ST1018 SA1003 SA4001 QF1001 ST1017 S1002 S1040 SA1028 SA4018 SA1027 SA1004 SA3001 SA5003 S1039 SA1017 S1036 S1024 QF1009 ST1020 S1008 SA4015 SA2003 S1001 SA4003 SA4028 SA1006 SA4023 SA1011 S1030 SA6000 S1004 SA4017 SA9006 SA4004 SA5005 SA5010 SA2000 SA1002 SA6002 SA5012 SA1005 SA9001 SA3000 S1033 ST1006 SA4031 SA4020 ST1015 S1019 ST1008 SA1018 S1012 SA4027 S1025 SA9002 S1007 ST1019 ST1021 ST1003 SA9005 QF1012 SA1015 QF1010 SA9004 SA1029 SA4006 ST1000 QF1005 SA1019 SA1021 ST1013 SA1026 QF1002 ST1005 S1034 SA4016 SA1014 SA5002 SA1007 SA4021 SA4030 SA9007 SA4005 SA5001 SA1025 SA5000 SA1024 S1011 SA4014 SA6005 SA6001 S1035 S1010 SA4009 SA5008 ST1016 S1028 S1006 QF1007 S1018 SA2001 ST1012 QF1003 SA1000 S1005 ST1022 SA5004 SA9003 SA4010 S1000 S1023 SA4024 SA1020 S1009 SA2002 SA4011 SA1030 QF1011 S1029 SA4022 QF1006 S1038 noresultvalues undeclaredname unusedvariable fillreturns nonewvars] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:12.39064 -0400 EDT m=+1.730787501 2023/07/21 11:38:14 Analyze end [] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:11.38853 -0400 EDT m=+0.728676834 3.175811292s 2023/07/21 11:38:14 Analyze end [] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:12.39064 -0400 EDT m=+1.730787501 2.341551917s ``` The different sets arise from the two calls to source.Analyze, from diagnosePkg and codeAction, providing different values of the ""includeConvenience"" boolean, which varies the set. However, the facty subset of both sets is the same, so in principle they should be able to work synergistically. Even if the flag is always true, the concurrent calls both create a DAG of analysisNodes for a batch of work, and execute it in parallel, and both encounter the slow ec2 package (1s, see #61506), so both make cache misses, even though they want the same computation. The only sharing is of completed analysis summaries via the file cache; there is no de-duplication of inflight requests (i.e. the first thread doesn't ""lick the cookie""). This is problematic for large packages like ec2 because they are expensive to recompute, and more likely to be recomputed because their inflight duration is longer, increasing the odds of a concurrent request. One solution would be to dedup using singleflight or a promise cache, but the logic could be tricky. Another would to somehow stagger the requests (codeAction and diagnosePkg) during initial indexing to make concurrent requests for large packages less likely; once the cache is populated subsequent operation is fast. It's worth noting that this causes at worst a factor of 2x slowdown, which is a lot, but still much less than the current difference between actual and ideal performance of buildssa (see #61506).",True,"x/tools/gopls: duplicated analysis work - The following log events were observed in a single run of ""gopls check"" (with staticcheck and nilness enabled) that was instrumented to report start/end calls to Analyze: ```go t0 := time.Now() log.Println(""Analyze start"", analyzers, pkgs, t0) defer func() { log.Println(""Analyze end"", analyzers, pkgs, t0, time.Since(t0)) // repeat t0 so we can tie start/end together }() ``` Observe that two concurrent Analyze calls request that the same package be analyzed with two different sets of analyzers. ``` ec2$ (cd ~/w/xtools && go build -o x ./gopls ) && time ~/w/xtools/x --profile.cpu=prof check ./internal/customizations/unit_test.go 2023/07/21 11:38:11 Analyze start [structtag stdmethods lostcancel unusedresult unusedparams copylocks unusedwrite timeformat buildtag bools embed shift sortslice loopclosure simplifyslice useany cgocall errorsas simplifyrange printf fieldalignment atomicalign unsafeptr assign testinggoroutine nilness ifaceassert composites nilfunc unmarshal directive stringintconv atomic simplifycompositelit deepequalerrors httpresponse unreachable asmdecl shadow tests QF1012 SA9002 S1007 ST1019 ST1021 ST1003 SA9005 SA1015 QF1010 SA9004 SA1029 SA4006 ST1000 QF1005 SA1019 SA1021 ST1013 SA1026 QF1002 ST1005 SA4030 SA9007 S1034 SA4016 SA1014 SA5002 SA1007 SA4021 SA4005 SA5001 SA1025 S1035 S1010 SA5000 SA1024 S1011 SA4014 SA6005 SA6001 S1018 SA2001 SA4009 SA5008 ST1016 S1028 S1006 QF1007 SA9003 SA4010 ST1012 QF1003 SA1000 S1005 ST1022 SA5004 S1000 S1023 QF1011 S1029 SA4024 SA1020 S1009 SA2002 SA4011 SA1030 SA4022 QF1006 S1038 SA4000 SA5007 S1020 S1031 S1021 S1032 SA1010 QF1004 ST1001 SA4029 SA1001 SA1012 S1016 SA1013 SA4012 SA4025 ST1023 S1003 SA1008 SA4013 S1017 SA4019 SA1023 SA4026 QF1008 SA9008 S1037 SA6003 SA1016 SA4008 ST1011 ST1018 SA1003 SA4001 QF1001 ST1017 S1002 S1040 SA1028 SA4018 SA1027 SA1004 SA3001 SA5003 S1039 SA1017 S1036 S1024 QF1009 ST1020 S1008 SA4015 SA2003 S1001 SA4003 SA4028 SA1006 SA4023 SA1011 SA5005 SA5010 S1030 SA6000 S1004 SA4017 SA9006 SA4004 SA2000 SA1002 SA6002 SA5012 SA1005 SA9001 SA3000 ST1008 SA1018 S1033 ST1006 SA4031 SA4020 ST1015 S1019 S1012 SA4027 S1025 nonewvars noresultvalues undeclaredname unusedvariable fillreturns] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:11.38853 -0400 EDT m=+0.728676834 2023/07/21 11:38:12 Analyze start [bools embed shift sortslice loopclosure simplifyslice unsafeptr useany cgocall errorsas simplifyrange printf fieldalignment atomicalign assign testinggoroutine nilness ifaceassert composites nilfunc unmarshal directive stringintconv atomic simplifycompositelit deepequalerrors httpresponse unreachable asmdecl shadow tests structtag stdmethods lostcancel unusedresult unusedparams copylocks unusedwrite timeformat buildtag SA4000 SA5007 S1020 S1031 S1021 S1032 SA1010 QF1004 ST1001 SA4029 SA1001 SA1012 S1016 SA1013 SA4012 SA4025 ST1023 S1003 SA1008 SA4013 S1017 SA4019 SA1023 SA4026 QF1008 SA9008 S1037 SA6003 SA1016 SA4008 ST1011 ST1018 SA1003 SA4001 QF1001 ST1017 S1002 S1040 SA1028 SA4018 SA1027 SA1004 SA3001 SA5003 S1039 SA1017 S1036 S1024 QF1009 ST1020 S1008 SA4015 SA2003 S1001 SA4003 SA4028 SA1006 SA4023 SA1011 S1030 SA6000 S1004 SA4017 SA9006 SA4004 SA5005 SA5010 SA2000 SA1002 SA6002 SA5012 SA1005 SA9001 SA3000 S1033 ST1006 SA4031 SA4020 ST1015 S1019 ST1008 SA1018 S1012 SA4027 S1025 SA9002 S1007 ST1019 ST1021 ST1003 SA9005 QF1012 SA1015 QF1010 SA9004 SA1029 SA4006 ST1000 QF1005 SA1019 SA1021 ST1013 SA1026 QF1002 ST1005 S1034 SA4016 SA1014 SA5002 SA1007 SA4021 SA4030 SA9007 SA4005 SA5001 SA1025 SA5000 SA1024 S1011 SA4014 SA6005 SA6001 S1035 S1010 SA4009 SA5008 ST1016 S1028 S1006 QF1007 S1018 SA2001 ST1012 QF1003 SA1000 S1005 ST1022 SA5004 SA9003 SA4010 S1000 S1023 SA4024 SA1020 S1009 SA2002 SA4011 SA1030 QF1011 S1029 SA4022 QF1006 S1038 noresultvalues undeclaredname unusedvariable fillreturns nonewvars] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:12.39064 -0400 EDT m=+1.730787501 2023/07/21 11:38:14 Analyze end [] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:11.38853 -0400 EDT m=+0.728676834 3.175811292s 2023/07/21 11:38:14 Analyze end [] map[github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations_test [github.com/aws/aws-sdk-go-v2/service/ec2/internal/customizations.test]:{}] 2023-07-21 11:38:12.39064 -0400 EDT m=+1.730787501 2.341551917s ``` The different sets arise from the two calls to source.Analyze, from diagnosePkg and codeAction, providing different values of the ""includeConvenience"" boolean, which varies the set. However, the facty subset of both sets is the same, so in principle they should be able to work synergistically. Even if the flag is always true, the concurrent calls both create a DAG of analysisNodes for a batch of work, and execute it in parallel, and both encounter the slow ec2 package (1s, see #61506), so both make cache misses, even though they want the same computation. The only sharing is of completed analysis summaries via the file cache; there is no de-duplication of inflight requests (i.e. the first thread doesn't ""lick the cookie""). This is problematic for large packages like ec2 because they are expensive to recompute, and more likely to be recomputed because their inflight duration is longer, increasing the odds of a concurrent request. One solution would be to dedup using singleflight or a promise cache, but the logic could be tricky. Another would to somehow stagger the requests (codeAction and diagnosePkg) during initial indexing to make concurrent requests for large packages less likely; once the cache is populated subsequent operation is fast. It's worth noting that this causes at worst a factor of 2x slowdown, which is a lot, but still much less than the current difference between actual and ideal performance of buildssa (see #61506).",0,x tools gopls duplicated analysis work the following log events were observed in a single run of gopls check with staticcheck and nilness enabled that was instrumented to report start end calls to analyze go time now log println analyze start analyzers pkgs defer func log println analyze end analyzers pkgs time since repeat so we can tie start end together observe that two concurrent analyze calls request that the same package be analyzed with two different sets of analyzers cd w xtools go build o x gopls time w xtools x profile cpu prof check internal customizations unit test go analyze start map edt m analyze start map edt m analyze end map edt m analyze end map edt m the different sets arise from the two calls to source analyze from diagnosepkg and codeaction providing different values of the includeconvenience boolean which varies the set however the facty subset of both sets is the same so in principle they should be able to work synergistically even if the flag is always true the concurrent calls both create a dag of analysisnodes for a batch of work and execute it in parallel and both encounter the slow package see so both make cache misses even though they want the same computation the only sharing is of completed analysis summaries via the file cache there is no de duplication of inflight requests i e the first thread doesn t lick the cookie this is problematic for large packages like because they are expensive to recompute and more likely to be recomputed because their inflight duration is longer increasing the odds of a concurrent request one solution would be to dedup using singleflight or a promise cache but the logic could be tricky another would to somehow stagger the requests codeaction and diagnosepkg during initial indexing to make concurrent requests for large packages less likely once the cache is populated subsequent operation is fast it s worth noting that this causes at worst a factor of slowdown which is a lot but still much less than the current difference between actual and ideal performance of buildssa see ,0 188040,15114472669.0,IssuesEvent,2021-02-09 02:00:41,golang/go,https://api.github.com/repos/golang/go,closed,runtime/metrics: typos in documentation,Documentation NeedsFix,"There are some typos in the documentation of the new ""runtime/metrics"" package * `encouranged` should be `encouraged` * `""kind.""` should be `""kind"".` * `the a tag` should be `the tag`",1.0,"runtime/metrics: typos in documentation - There are some typos in the documentation of the new ""runtime/metrics"" package * `encouranged` should be `encouraged` * `""kind.""` should be `""kind"".` * `the a tag` should be `the tag`",1,runtime metrics typos in documentation there are some typos in the documentation of the new runtime metrics package encouranged should be encouraged kind should be kind the a tag should be the tag ,1 45678,7195418698.0,IssuesEvent,2018-02-04 16:58:10,golang/go,https://api.github.com/repos/golang/go,opened,strconv: Unquote example looks like a unit test instead of an example,Documentation NeedsFix help wanted,"The Unquote example (https://golang.org/pkg/strconv/#Unquote) looks like a unit test instead of an example. That is a sea of backslashes and quotes. I think we could make a more readable example. ",1.0,"strconv: Unquote example looks like a unit test instead of an example - The Unquote example (https://golang.org/pkg/strconv/#Unquote) looks like a unit test instead of an example. That is a sea of backslashes and quotes. I think we could make a more readable example. ",1,strconv unquote example looks like a unit test instead of an example the unquote example looks like a unit test instead of an example that is a sea of backslashes and quotes i think we could make a more readable example ,1 5669,2962848810.0,IssuesEvent,2015-07-10 05:23:25,golang/go,https://api.github.com/repos/golang/go,closed,"doc: Release notes 1.5: ""go tool compile"" - is that native only or x-compile too?",Documentation,"http://tip.golang.org/doc/go1.5 Compiler and tools Independent of but encouraged by the move to Go, the names of the tools have changed. The old names 6g, 8g and so on are gone; instead there is just one binary, accessible as go tool compile, that compiles Go source into binaries suitable for the architecture and operating system specified by $GOARCH and $GOOS. Similarly, there is now one linker (go tool link) and one assembler (go tool asm). The linker was translated automatically from the old C implementation, but the assembler is a new native Go implementation discussed in more detail below. Similar to the drop of the names 6g, 8g, and so on, the output of the compiler and assembler are now given a plain .o suffix rather than .8, .6, etc. -> I would find it useful if you can point out: does the compiler only target the native plattform, or will ""go tool compile"" target all plattforms go supports or ... ? As 3 commands gets replaced with one, it is not clear what that one command can exactly do.",1.0,"doc: Release notes 1.5: ""go tool compile"" - is that native only or x-compile too? - http://tip.golang.org/doc/go1.5 Compiler and tools Independent of but encouraged by the move to Go, the names of the tools have changed. The old names 6g, 8g and so on are gone; instead there is just one binary, accessible as go tool compile, that compiles Go source into binaries suitable for the architecture and operating system specified by $GOARCH and $GOOS. Similarly, there is now one linker (go tool link) and one assembler (go tool asm). The linker was translated automatically from the old C implementation, but the assembler is a new native Go implementation discussed in more detail below. Similar to the drop of the names 6g, 8g, and so on, the output of the compiler and assembler are now given a plain .o suffix rather than .8, .6, etc. -> I would find it useful if you can point out: does the compiler only target the native plattform, or will ""go tool compile"" target all plattforms go supports or ... ? As 3 commands gets replaced with one, it is not clear what that one command can exactly do.",1,doc release notes go tool compile is that native only or x compile too compiler and tools independent of but encouraged by the move to go the names of the tools have changed the old names and so on are gone instead there is just one binary accessible as go tool compile that compiles go source into binaries suitable for the architecture and operating system specified by goarch and goos similarly there is now one linker go tool link and one assembler go tool asm the linker was translated automatically from the old c implementation but the assembler is a new native go implementation discussed in more detail below similar to the drop of the names and so on the output of the compiler and assembler are now given a plain o suffix rather than etc i would find it useful if you can point out does the compiler only target the native plattform or will go tool compile target all plattforms go supports or as commands gets replaced with one it is not clear what that one command can exactly do ,1 9499,3288577372.0,IssuesEvent,2015-10-29 15:39:36,golang/go,https://api.github.com/repos/golang/go,closed,os/signal: code example for Notify tries to catch os.Kill which doesn't work,Documentation HelpWanted,"In the code example for os/signal/#Notify, signal.Notify(c, os.Interrupt, os.Kill) tries to catch os.Kill signal, which doesn't work on Linux platforms. Steps to reproduce: Code is taken from the doc. ``` $ cat kill.go package main import ( ""fmt"" ""os"" ""os/signal"" ) func main() { c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt, os.Kill) s := <-c fmt.Println(""Got signal "", s) } $ go build kill.go $ ./kill & [1] 10300 $ kill -KILL $! $ [1]+ Killed ./kill ``` Ctrl-C / -s SIGINT works fine but SIGKILL is not caught.",1.0,"os/signal: code example for Notify tries to catch os.Kill which doesn't work - In the code example for os/signal/#Notify, signal.Notify(c, os.Interrupt, os.Kill) tries to catch os.Kill signal, which doesn't work on Linux platforms. Steps to reproduce: Code is taken from the doc. ``` $ cat kill.go package main import ( ""fmt"" ""os"" ""os/signal"" ) func main() { c := make(chan os.Signal, 1) signal.Notify(c, os.Interrupt, os.Kill) s := <-c fmt.Println(""Got signal "", s) } $ go build kill.go $ ./kill & [1] 10300 $ kill -KILL $! $ [1]+ Killed ./kill ``` Ctrl-C / -s SIGINT works fine but SIGKILL is not caught.",1,os signal code example for notify tries to catch os kill which doesn t work in the code example for os signal notify signal notify c os interrupt os kill tries to catch os kill signal which doesn t work on linux platforms steps to reproduce code is taken from the doc cat kill go package main import fmt os os signal func main c make chan os signal signal notify c os interrupt os kill s c fmt println got signal s go build kill go kill kill kill killed kill ctrl c s sigint works fine but sigkill is not caught ,1 39218,6730758602.0,IssuesEvent,2017-10-18 03:08:28,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: example usage for Out is incorrect,Documentation,"Hi, Small thing, but please change example usage code for sql.Out from: `_, err := db.ExecContext(ctx, ""ProcName"", sql.Named(""Arg1"", Out{Dest: &outArg}))` to: `_, err := db.ExecContext(ctx, ""ProcName"", sql.Named(""Arg1"", sql.Out{Dest: &outArg}))` [Line 288 in database/sql/sql.go](https://golang.org/src/database/sql/sql.go?s=7393:7789#L288) ### What version of Go are you using (`go version`)? Go 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? linux/amd64 (Windows Subsystem for Linux) ### What did you do? I copied the code in the example usage of the new Out parameter and the compiler complained about unknown type `Out` ### What did you expect to see? N/A ### What did you see instead? Compile error ",1.0,"database/sql: example usage for Out is incorrect - Hi, Small thing, but please change example usage code for sql.Out from: `_, err := db.ExecContext(ctx, ""ProcName"", sql.Named(""Arg1"", Out{Dest: &outArg}))` to: `_, err := db.ExecContext(ctx, ""ProcName"", sql.Named(""Arg1"", sql.Out{Dest: &outArg}))` [Line 288 in database/sql/sql.go](https://golang.org/src/database/sql/sql.go?s=7393:7789#L288) ### What version of Go are you using (`go version`)? Go 1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? linux/amd64 (Windows Subsystem for Linux) ### What did you do? I copied the code in the example usage of the new Out parameter and the compiler complained about unknown type `Out` ### What did you expect to see? N/A ### What did you see instead? Compile error ",1,database sql example usage for out is incorrect hi small thing but please change example usage code for sql out from err db execcontext ctx procname sql named out dest outarg to err db execcontext ctx procname sql named sql out dest outarg what version of go are you using go version go does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env linux windows subsystem for linux what did you do i copied the code in the example usage of the new out parameter and the compiler complained about unknown type out what did you expect to see n a what did you see instead compile error ,1 34832,6383544013.0,IssuesEvent,2017-08-03 00:43:11,golang/go,https://api.github.com/repos/golang/go,closed,"net: update documentation, example for error values",Documentation NeedsFix,"Suggested in a review of net: fix inconsistent errors (https://go-review.googlesource.com/#/c/9236/): In a different CL, could you write some documentation about what kinds of errors people can expect, and perhaps an Example function showing how to work with them? See https://groups.google.com/d/msg/golang-nuts/iNVNBXdZK8Q/irnIrgLD2q4J for the kinds of issues programmers want to understand. ",1.0,"net: update documentation, example for error values - Suggested in a review of net: fix inconsistent errors (https://go-review.googlesource.com/#/c/9236/): In a different CL, could you write some documentation about what kinds of errors people can expect, and perhaps an Example function showing how to work with them? See https://groups.google.com/d/msg/golang-nuts/iNVNBXdZK8Q/irnIrgLD2q4J for the kinds of issues programmers want to understand. ",1,net update documentation example for error values suggested in a review of net fix inconsistent errors in a different cl could you write some documentation about what kinds of errors people can expect and perhaps an example function showing how to work with them see for the kinds of issues programmers want to understand ,1 74437,20161739767.0,IssuesEvent,2022-02-09 22:20:30,golang/go,https://api.github.com/repos/golang/go,opened,"x/build/cmd/relui: in prod deployment, make secrets in secret manager available to relui command",Builders NeedsInvestigation,"The production relui deployment ([deployment-prod.yaml](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=1;drc=9076251d2245d34b4f6884d256c8237d40e257c7) in x/build/cmd/relui) runs the `relui` command, and currently provides some static flags and environment variables (see [here](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=26-27;drc=9076251d2245d34b4f6884d256c8237d40e257c7) and [here](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=31-36?q=deployment-prod.yaml)). For upcoming production workflows (e.g., #47402 and #47404), the `relui` binary will need to be also provided secrets from secret manager. Specifically, we want: - [`secret.NameTwitterAPISecret`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameTwitterAPISecret) for workflows involving posting a tweet - [`secret.NameGobotPassword`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameGobotPassword) for workflows involving sending Gerrit CLs - [`secret.NameSendGridAPIKey`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameSendGridAPIKey) for workflows involving sending email Based on sources like https://kubernetes.io/docs/concepts/configuration/secret/, Kubernetes has support for arranging this. It can be implemented as files in a mounted volume (whose location can either be well-known by the relui command, or provided to it via a flag or env var), or via environment variables that relui can access. This is the tracking issue for making these secrets available to the relui process in the production environment (a part of #47407). CC @golang/release.",1.0,"x/build/cmd/relui: in prod deployment, make secrets in secret manager available to relui command - The production relui deployment ([deployment-prod.yaml](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=1;drc=9076251d2245d34b4f6884d256c8237d40e257c7) in x/build/cmd/relui) runs the `relui` command, and currently provides some static flags and environment variables (see [here](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=26-27;drc=9076251d2245d34b4f6884d256c8237d40e257c7) and [here](https://cs.opensource.google/go/x/build/+/master:cmd/relui/deployment-prod.yaml;l=31-36?q=deployment-prod.yaml)). For upcoming production workflows (e.g., #47402 and #47404), the `relui` binary will need to be also provided secrets from secret manager. Specifically, we want: - [`secret.NameTwitterAPISecret`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameTwitterAPISecret) for workflows involving posting a tweet - [`secret.NameGobotPassword`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameGobotPassword) for workflows involving sending Gerrit CLs - [`secret.NameSendGridAPIKey`](https://pkg.go.dev/golang.org/x/build/internal/secret.NameSendGridAPIKey) for workflows involving sending email Based on sources like https://kubernetes.io/docs/concepts/configuration/secret/, Kubernetes has support for arranging this. It can be implemented as files in a mounted volume (whose location can either be well-known by the relui command, or provided to it via a flag or env var), or via environment variables that relui can access. This is the tracking issue for making these secrets available to the relui process in the production environment (a part of #47407). CC @golang/release.",0,x build cmd relui in prod deployment make secrets in secret manager available to relui command the production relui deployment in x build cmd relui runs the relui command and currently provides some static flags and environment variables see and for upcoming production workflows e g and the relui binary will need to be also provided secrets from secret manager specifically we want for workflows involving posting a tweet for workflows involving sending gerrit cls for workflows involving sending email based on sources like kubernetes has support for arranging this it can be implemented as files in a mounted volume whose location can either be well known by the relui command or provided to it via a flag or env var or via environment variables that relui can access this is the tracking issue for making these secrets available to the relui process in the production environment a part of cc golang release ,0 86702,10514759996.0,IssuesEvent,2019-09-28 03:23:42,golang/go,https://api.github.com/repos/golang/go,closed,regexp: add examples for all methods on regex.Regexp,Documentation NeedsFix,"Something I've been wanting to do for a while is provide complete example coverage for methods defined on regexp.Regex. There are 36 methods, 11 of which have examples. Unless this isn't desired, I'd like to finish the other 25. ",1.0,"regexp: add examples for all methods on regex.Regexp - Something I've been wanting to do for a while is provide complete example coverage for methods defined on regexp.Regex. There are 36 methods, 11 of which have examples. Unless this isn't desired, I'd like to finish the other 25. ",1,regexp add examples for all methods on regex regexp something i ve been wanting to do for a while is provide complete example coverage for methods defined on regexp regex there are methods of which have examples unless this isn t desired i d like to finish the other ,1 196842,14893002135.0,IssuesEvent,2021-01-21 04:17:32,golang/go,https://api.github.com/repos/golang/go,closed,internal/execabs: disable tests on js-wasm,NeedsFix Testing release-blocker,"`os/exec.{LookPath,Command}` is disabled on js-wasm so `internal/execabs` won't work on the platform.",1.0,"internal/execabs: disable tests on js-wasm - `os/exec.{LookPath,Command}` is disabled on js-wasm so `internal/execabs` won't work on the platform.",0,internal execabs disable tests on js wasm os exec lookpath command is disabled on js wasm so internal execabs won t work on the platform ,0 146730,13190199780.0,IssuesEvent,2020-08-13 09:46:23,golang/go,https://api.github.com/repos/golang/go,opened,cmd/link: help text for linkmode isn't helpful,Documentation,"``` $ go version go version devel +5c7748dc9d Mon Aug 10 23:44:58 2020 +0000 linux/amd64 $ go tool link -h 2>&1 | grep -A1 linkmode -linkmode mode set link mode ``` At least, it could tell me what the modes are, and ideally point me at the docs for what they do. I realise that the compiler and linker are fairly low level and mostusers shouldn't be looking at `go tool link -h`, but given that `-linkmode=external` is somewhat well known and widely used, it's confusing that it's hard to find its definition without looking at the code. CC @cherrymui @jeremyfaller ",1.0,"cmd/link: help text for linkmode isn't helpful - ``` $ go version go version devel +5c7748dc9d Mon Aug 10 23:44:58 2020 +0000 linux/amd64 $ go tool link -h 2>&1 | grep -A1 linkmode -linkmode mode set link mode ``` At least, it could tell me what the modes are, and ideally point me at the docs for what they do. I realise that the compiler and linker are fairly low level and mostusers shouldn't be looking at `go tool link -h`, but given that `-linkmode=external` is somewhat well known and widely used, it's confusing that it's hard to find its definition without looking at the code. CC @cherrymui @jeremyfaller ",1,cmd link help text for linkmode isn t helpful go version go version devel mon aug linux go tool link h grep linkmode linkmode mode set link mode at least it could tell me what the modes are and ideally point me at the docs for what they do i realise that the compiler and linker are fairly low level and mostusers shouldn t be looking at go tool link h but given that linkmode external is somewhat well known and widely used it s confusing that it s hard to find its definition without looking at the code cc cherrymui jeremyfaller ,1 14040,8452644685.0,IssuesEvent,2018-10-20 06:35:57,golang/go,https://api.github.com/repos/golang/go,closed,syscall/js: huge copy overhead when passing byte slices over certain Go/JS boundaries,Arch-Wasm Performance,"This related to my effort to get Go WASM/JS to work with a WebWorker process. ### What version of Go are you using (`go version`)? go version devel +0e0cd70ecf Tue Jul 3 04:16:23 2018 +0000 windows/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ```cmd set GOARCH=wasm set GOBIN= set GOCACHE=C:\Users\leidegre\AppData\Local\go-build set GOEXE= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=js set GOPATH=C:\Users\leidegre\go set GOPROXY= set GORACE= set GOROOT=C:\Users\leidegre\Source\go set GOTMPDIR= set GOTOOLDIR=C:\Users\leidegre\Source\go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=0 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-fPIC -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\leidegre\AppData\Local\Temp\go-build097448038=/tmp/go-build -gno-record-gcc-switches set VGOMODROOT= ``` ### What did you do? Trying to pass an nil `[]byte` slice from a WebWorker process to a web application. ### What did you expect to see? That gigabytes of memory is not allocated. ### What did you see instead? Gigabytes of memory is being allocated on each `postMessage` call. This crashes both Chrome and Firefox render process. Haven't tested Edge. ### Additional findings as soon as you console.log or pass a slice through a boundary context, for example `postMessage` there's copying associated with the ArrayBuffer. For some reason, the gigabyte ArrayBuffer (Go linear memory) gets copied as well and the heap just explodes typically grinding the web page to a halt or crashing the page. I was able to work around this issue by passing the slice through this helper function first. [worker.js] ```js function slice({ byteOffset, byteLength, buffer }) { return buffer.slice(byteOffset, byteOffset + byteLength) } ``` [worker.go] ```go var x []byte x = append(x, 2) x = append(x, 3) x = append(x, 5) y := js.TypedArrayOf(x) z := global.Call(""slice"", y) y.Release() global.Call(""postMessage"", z) // from WebWorker postMessage ``` Note that problem occur even if the slice is empty or nil. If `worker.js`, i.e. the WebWorker process does console.log at any time on any object that is backed by the ArrayBuffer you'll see crazy heap explosion and subsequent crashes. Not sure what to do about this but I thought I'd share my findings here. It's mostly a side effect of how things are not something Go/WASM is doing wrong but maybe this can be improved somehow? Passing values between Go/JS seems like a natural thing to do.",True,"syscall/js: huge copy overhead when passing byte slices over certain Go/JS boundaries - This related to my effort to get Go WASM/JS to work with a WebWorker process. ### What version of Go are you using (`go version`)? go version devel +0e0cd70ecf Tue Jul 3 04:16:23 2018 +0000 windows/amd64 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ```cmd set GOARCH=wasm set GOBIN= set GOCACHE=C:\Users\leidegre\AppData\Local\go-build set GOEXE= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=js set GOPATH=C:\Users\leidegre\go set GOPROXY= set GORACE= set GOROOT=C:\Users\leidegre\Source\go set GOTMPDIR= set GOTOOLDIR=C:\Users\leidegre\Source\go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set CXX=g++ set CGO_ENABLED=0 set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-fPIC -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\leidegre\AppData\Local\Temp\go-build097448038=/tmp/go-build -gno-record-gcc-switches set VGOMODROOT= ``` ### What did you do? Trying to pass an nil `[]byte` slice from a WebWorker process to a web application. ### What did you expect to see? That gigabytes of memory is not allocated. ### What did you see instead? Gigabytes of memory is being allocated on each `postMessage` call. This crashes both Chrome and Firefox render process. Haven't tested Edge. ### Additional findings as soon as you console.log or pass a slice through a boundary context, for example `postMessage` there's copying associated with the ArrayBuffer. For some reason, the gigabyte ArrayBuffer (Go linear memory) gets copied as well and the heap just explodes typically grinding the web page to a halt or crashing the page. I was able to work around this issue by passing the slice through this helper function first. [worker.js] ```js function slice({ byteOffset, byteLength, buffer }) { return buffer.slice(byteOffset, byteOffset + byteLength) } ``` [worker.go] ```go var x []byte x = append(x, 2) x = append(x, 3) x = append(x, 5) y := js.TypedArrayOf(x) z := global.Call(""slice"", y) y.Release() global.Call(""postMessage"", z) // from WebWorker postMessage ``` Note that problem occur even if the slice is empty or nil. If `worker.js`, i.e. the WebWorker process does console.log at any time on any object that is backed by the ArrayBuffer you'll see crazy heap explosion and subsequent crashes. Not sure what to do about this but I thought I'd share my findings here. It's mostly a side effect of how things are not something Go/WASM is doing wrong but maybe this can be improved somehow? Passing values between Go/JS seems like a natural thing to do.",0,syscall js huge copy overhead when passing byte slices over certain go js boundaries this related to my effort to get go wasm js to work with a webworker process what version of go are you using go version go version devel tue jul windows does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env cmd set goarch wasm set gobin set gocache c users leidegre appdata local go build set goexe set gohostarch set gohostos windows set goos js set gopath c users leidegre go set goproxy set gorace set goroot c users leidegre source go set gotmpdir set gotooldir c users leidegre source go pkg tool windows set gccgo gccgo set cc gcc set cxx g set cgo enabled set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags fpic fno caret diagnostics qunused arguments fmessage length fdebug prefix map c users leidegre appdata local temp go tmp go build gno record gcc switches set vgomodroot what did you do trying to pass an nil byte slice from a webworker process to a web application what did you expect to see that gigabytes of memory is not allocated what did you see instead gigabytes of memory is being allocated on each postmessage call this crashes both chrome and firefox render process haven t tested edge additional findings as soon as you console log or pass a slice through a boundary context for example postmessage there s copying associated with the arraybuffer for some reason the gigabyte arraybuffer go linear memory gets copied as well and the heap just explodes typically grinding the web page to a halt or crashing the page i was able to work around this issue by passing the slice through this helper function first js function slice byteoffset bytelength buffer return buffer slice byteoffset byteoffset bytelength go var x byte x append x x append x x append x y js typedarrayof x z global call slice y y release global call postmessage z from webworker postmessage note that problem occur even if the slice is empty or nil if worker js i e the webworker process does console log at any time on any object that is backed by the arraybuffer you ll see crazy heap explosion and subsequent crashes not sure what to do about this but i thought i d share my findings here it s mostly a side effect of how things are not something go wasm is doing wrong but maybe this can be improved somehow passing values between go js seems like a natural thing to do ,0 122618,12156398853.0,IssuesEvent,2020-04-25 17:09:44,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: hoverKind FullDocumentation is incorrectly escaping various characters,Documentation Tools gopls," ### What version of Go are you using (`go version`)? 
❯ gopls version                          
golang.org/x/tools/gopls v0.3.4
    golang.org/x/tools/gopls@v0.3.4 h1:4GC7q/pXQ/tsxHBGVdsMdlB4gCxVC06m/7rIXg1Px4E=
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
❯ go env                                 
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/james/.cache/go-build""
GOENV=""/home/james/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/james/go:/home/james/godev""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build613753881=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I have set `""hoverKind"": ""FullDocumentation""` as added in https://github.com/golang/go/issues/32561. This works, but it inserts a lot of escaped characters into the markdown description that it doesn't need to. I'm not quite sure why. Here is an example for `fmt#Errorf`: ```markdown [`fmt.Errorf` on pkg.go.dev](https://pkg.go.dev/fmt#Errorf) Errorf formats according to a format specifier and returns the string as a value that satisfies error\\. If the format specifier includes a \\%w verb with an error operand, the returned error will implement an Unwrap method returning the operand\\. It is invalid to include more than one \\%w verb or to supply it with an operand that does not implement the error interface\\. The \\%w verb is otherwise a synonym for \\%v\\. ``` Rendering this via markdown (inside Emacs via lsp-mode) produces this: ![image](https://user-images.githubusercontent.com/522123/80281358-69076c80-8702-11ea-99a9-93e69422d657.png) I'm also seeing html entities being escaped: ![image](https://user-images.githubusercontent.com/522123/80284964-c3f88e00-8719-11ea-96fa-32f4c7106c4f.png) In the raw JSON this looks like `\u0026nbsp;`. ### What did you expect to see? Full documentation without any escape characters. ### What did you see instead? Full documentation with lots of embedded escape characters.",1.0,"x/tools/gopls: hoverKind FullDocumentation is incorrectly escaping various characters - ### What version of Go are you using (`go version`)? 
❯ gopls version                          
golang.org/x/tools/gopls v0.3.4
    golang.org/x/tools/gopls@v0.3.4 h1:4GC7q/pXQ/tsxHBGVdsMdlB4gCxVC06m/7rIXg1Px4E=
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
❯ go env                                 
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/james/.cache/go-build""
GOENV=""/home/james/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/james/go:/home/james/godev""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build613753881=/tmp/go-build -gno-record-gcc-switches""
### What did you do? I have set `""hoverKind"": ""FullDocumentation""` as added in https://github.com/golang/go/issues/32561. This works, but it inserts a lot of escaped characters into the markdown description that it doesn't need to. I'm not quite sure why. Here is an example for `fmt#Errorf`: ```markdown [`fmt.Errorf` on pkg.go.dev](https://pkg.go.dev/fmt#Errorf) Errorf formats according to a format specifier and returns the string as a value that satisfies error\\. If the format specifier includes a \\%w verb with an error operand, the returned error will implement an Unwrap method returning the operand\\. It is invalid to include more than one \\%w verb or to supply it with an operand that does not implement the error interface\\. The \\%w verb is otherwise a synonym for \\%v\\. ``` Rendering this via markdown (inside Emacs via lsp-mode) produces this: ![image](https://user-images.githubusercontent.com/522123/80281358-69076c80-8702-11ea-99a9-93e69422d657.png) I'm also seeing html entities being escaped: ![image](https://user-images.githubusercontent.com/522123/80284964-c3f88e00-8719-11ea-96fa-32f4c7106c4f.png) In the raw JSON this looks like `\u0026nbsp;`. ### What did you expect to see? Full documentation without any escape characters. ### What did you see instead? Full documentation with lots of embedded escape characters.",1,x tools gopls hoverkind fulldocumentation is incorrectly escaping various characters please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version ❯ gopls version golang org x tools gopls golang org x tools gopls pxq does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output ❯ go env goarch gobin gocache home james cache go build goenv home james config go env goexe goflags gohostarch gohostos linux goinsecure gonoproxy gonosumdb goos linux gopath home james go home james godev goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 i have set hoverkind fulldocumentation as added in this works but it inserts a lot of escaped characters into the markdown description that it doesn t need to i m not quite sure why here is an example for fmt errorf markdown errorf formats according to a format specifier and returns the string as a value that satisfies error if the format specifier includes a w verb with an error operand the returned error will implement an unwrap method returning the operand it is invalid to include more than one w verb or to supply it with an operand that does not implement the error interface the w verb is otherwise a synonym for v rendering this via markdown inside emacs via lsp mode produces this i m also seeing html entities being escaped in the raw json this looks like what did you expect to see full documentation without any escape characters what did you see instead full documentation with lots of embedded escape characters ,1 58839,8306417044.0,IssuesEvent,2018-09-22 18:30:59,golang/go,https://api.github.com/repos/golang/go,closed,doc: mention how to add GOPATH\bin to PATH for Windows users,Documentation NeedsFix OS-Windows,[GOPATH variable section](https://tip.golang.org/doc/code.html#GOPATH) is not mentioning that GOPATH\bin needs to be added to PATH for convince. Create a wiki page with platform specific instructions how to add the bin directory to the PATH and add instructions for Windows.,1.0,doc: mention how to add GOPATH\bin to PATH for Windows users - [GOPATH variable section](https://tip.golang.org/doc/code.html#GOPATH) is not mentioning that GOPATH\bin needs to be added to PATH for convince. Create a wiki page with platform specific instructions how to add the bin directory to the PATH and add instructions for Windows.,1,doc mention how to add gopath bin to path for windows users is not mentioning that gopath bin needs to be added to path for convince create a wiki page with platform specific instructions how to add the bin directory to the path and add instructions for windows ,1 18031,6541202983.0,IssuesEvent,2017-09-01 18:47:11,golang/go,https://api.github.com/repos/golang/go,closed,x/build/cmd/gopherbot: congratulate new contributors based on unique email only,Builders HelpWanted,"We've had several cases where users have slightly changed the name they use for their git commits, triggering the ""Congratulations on your first change..."" bot. CL https://go-review.googlesource.com/60851 is a good example of this. We should probably just have it be unique by email address. The code is here: https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go#L782 I think this would be a good change for new contributors to the Go tools. ",1.0,"x/build/cmd/gopherbot: congratulate new contributors based on unique email only - We've had several cases where users have slightly changed the name they use for their git commits, triggering the ""Congratulations on your first change..."" bot. CL https://go-review.googlesource.com/60851 is a good example of this. We should probably just have it be unique by email address. The code is here: https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go#L782 I think this would be a good change for new contributors to the Go tools. ",0,x build cmd gopherbot congratulate new contributors based on unique email only we ve had several cases where users have slightly changed the name they use for their git commits triggering the congratulations on your first change bot cl is a good example of this we should probably just have it be unique by email address the code is here i think this would be a good change for new contributors to the go tools ,0 24087,5027454411.0,IssuesEvent,2016-12-15 15:35:36,golang/go,https://api.github.com/repos/golang/go,closed,net: fix comment on IPv4bcast,Documentation,"The comment says `IPv4bcast = IPv4(255, 255, 255, 255) // broadcast`, but it's a limited broadcast address and should be distinguished from directed broadcast addresses. ",1.0,"net: fix comment on IPv4bcast - The comment says `IPv4bcast = IPv4(255, 255, 255, 255) // broadcast`, but it's a limited broadcast address and should be distinguished from directed broadcast addresses. ",1,net fix comment on the comment says broadcast but it s a limited broadcast address and should be distinguished from directed broadcast addresses ,1 57667,8202281478.0,IssuesEvent,2018-09-02 07:04:41,golang/go,https://api.github.com/repos/golang/go,closed,"cmd/{godoc,vet},testing: godoc disagrees with the docs and vet about validity of example name suffixes",Documentation,"### What version of Go are you using (`go version`)? ``` $ go version go version go1.11 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? linux/amd64 ### What did you do? ``` ~/src/gonum.org/v1/gonum/graph/topo$ go vet # gonum.org/v1/gonum/graph/topo_test ./2sat_example_test.go:177: ExampleTarjanSCC_2sat refers to unknown field or method: TarjanSCC.2sat ``` However, godoc [renders the 2sat example](https://godoc.org/gonum.org/v1/gonum/graph/topo#example-TarjanSCC--2sat). ### What did you expect to see? An error from vet and a failure from godoc to render the example. ### What did you see instead? A vet error but a rendered example. ### What would you like to see? No error and a rendered example. That is, a relaxation of the [documented](https://golang.org/pkg/testing/#hdr-Examples) requirement for an initial lowercase **letter** in the suffix (""The suffix must start with a lower-case letter."") to allow numeric leading glyphs. ",1.0,"cmd/{godoc,vet},testing: godoc disagrees with the docs and vet about validity of example name suffixes - ### What version of Go are you using (`go version`)? ``` $ go version go version go1.11 linux/amd64 ``` ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? linux/amd64 ### What did you do? ``` ~/src/gonum.org/v1/gonum/graph/topo$ go vet # gonum.org/v1/gonum/graph/topo_test ./2sat_example_test.go:177: ExampleTarjanSCC_2sat refers to unknown field or method: TarjanSCC.2sat ``` However, godoc [renders the 2sat example](https://godoc.org/gonum.org/v1/gonum/graph/topo#example-TarjanSCC--2sat). ### What did you expect to see? An error from vet and a failure from godoc to render the example. ### What did you see instead? A vet error but a rendered example. ### What would you like to see? No error and a rendered example. That is, a relaxation of the [documented](https://golang.org/pkg/testing/#hdr-Examples) requirement for an initial lowercase **letter** in the suffix (""The suffix must start with a lower-case letter."") to allow numeric leading glyphs. ",1,cmd godoc vet testing godoc disagrees with the docs and vet about validity of example name suffixes what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env linux what did you do src gonum org gonum graph topo go vet gonum org gonum graph topo test example test go exampletarjanscc refers to unknown field or method tarjanscc however godoc what did you expect to see an error from vet and a failure from godoc to render the example what did you see instead a vet error but a rendered example what would you like to see no error and a rendered example that is a relaxation of the requirement for an initial lowercase letter in the suffix the suffix must start with a lower case letter to allow numeric leading glyphs ,1 17555,4171880676.0,IssuesEvent,2016-06-21 02:16:27,golang/go,https://api.github.com/repos/golang/go,closed,text/template: does not document how values are formatted,Documentation NeedsFix,"go version devel +3c6b668 Thu Jun 2 00:22:03 2016 +0000 linux/amd64 I may well have missed it, but text/template package doesn't seem to specify anywhere how values are actually displayed. For example, by reading the documentation, it's not clear whether a value's String method will be called to produce text to display in the template. ",1.0,"text/template: does not document how values are formatted - go version devel +3c6b668 Thu Jun 2 00:22:03 2016 +0000 linux/amd64 I may well have missed it, but text/template package doesn't seem to specify anywhere how values are actually displayed. For example, by reading the documentation, it's not clear whether a value's String method will be called to produce text to display in the template. ",1,text template does not document how values are formatted go version devel thu jun linux i may well have missed it but text template package doesn t seem to specify anywhere how values are actually displayed for example by reading the documentation it s not clear whether a value s string method will be called to produce text to display in the template ,1 40049,10438037824.0,IssuesEvent,2019-09-18 00:24:41,golang/go,https://api.github.com/repos/golang/go,opened,x/net/http2/h2demo: has started to cause x/net builders to fail,Builders NeedsDecision Soon Testing,"Issue #32528 has been resolved and all inner modules in x/net are being tested now, which includes the `golang.org/x/net/http2/h2demo` module. It contains a single package, which is a command with an `// +build h2demo` build constraint. This is currently causing the x/net builders to report a failure, because the `go test` command reports a non-zero exit code when given an import path pattern that matches no packages: ``` h2demo $ go test golang.org/x/net/http2/h2demo/... go: warning: ""golang.org/x/net/http2/h2demo/..."" matched no packages no packages to test h2demo $ echo $? 1 ``` We have to fix x/net builders, but need to decide how. ### Possible Solutions My first suggestion would be to remove the `h2demo` build constraint. If I understand correctly, it was used when `h2demo` was created in 2015, before modules, and it was a probably a way to make it not appear in users' $GOPATH/bin when they did `go get -u golang.org/x/net/...` and to avoid its dependencies from being fetched. The `h2demo` command was carved out into a separate module in #30685 to resolve the issue of it contributing too many dependencies to x/net. I think the build constraint isn't needed, but let me know what you think. An alternative solution is to come up with a way to allow a module with zero packages to not cause a test failure. But this option doesn't seem very good. /cc @bradfitz @jayconrod",1.0,"x/net/http2/h2demo: has started to cause x/net builders to fail - Issue #32528 has been resolved and all inner modules in x/net are being tested now, which includes the `golang.org/x/net/http2/h2demo` module. It contains a single package, which is a command with an `// +build h2demo` build constraint. This is currently causing the x/net builders to report a failure, because the `go test` command reports a non-zero exit code when given an import path pattern that matches no packages: ``` h2demo $ go test golang.org/x/net/http2/h2demo/... go: warning: ""golang.org/x/net/http2/h2demo/..."" matched no packages no packages to test h2demo $ echo $? 1 ``` We have to fix x/net builders, but need to decide how. ### Possible Solutions My first suggestion would be to remove the `h2demo` build constraint. If I understand correctly, it was used when `h2demo` was created in 2015, before modules, and it was a probably a way to make it not appear in users' $GOPATH/bin when they did `go get -u golang.org/x/net/...` and to avoid its dependencies from being fetched. The `h2demo` command was carved out into a separate module in #30685 to resolve the issue of it contributing too many dependencies to x/net. I think the build constraint isn't needed, but let me know what you think. An alternative solution is to come up with a way to allow a module with zero packages to not cause a test failure. But this option doesn't seem very good. /cc @bradfitz @jayconrod",0,x net has started to cause x net builders to fail issue has been resolved and all inner modules in x net are being tested now which includes the golang org x net module it contains a single package which is a command with an build build constraint this is currently causing the x net builders to report a failure because the go test command reports a non zero exit code when given an import path pattern that matches no packages go test golang org x net go warning golang org x net matched no packages no packages to test echo we have to fix x net builders but need to decide how possible solutions my first suggestion would be to remove the build constraint if i understand correctly it was used when was created in before modules and it was a probably a way to make it not appear in users gopath bin when they did go get u golang org x net and to avoid its dependencies from being fetched the command was carved out into a separate module in to resolve the issue of it contributing too many dependencies to x net i think the build constraint isn t needed but let me know what you think an alternative solution is to come up with a way to allow a module with zero packages to not cause a test failure but this option doesn t seem very good cc bradfitz jayconrod,0 16642,6259115578.0,IssuesEvent,2017-07-14 17:16:11,golang/go,https://api.github.com/repos/golang/go,closed,x/build: add solaris amd64 release builder to dashboard,Builders,A new host key for host-solaris-oracle-amd64-oraclerel was generated; the builder needs to be added. I will submit the change shortly.,1.0,x/build: add solaris amd64 release builder to dashboard - A new host key for host-solaris-oracle-amd64-oraclerel was generated; the builder needs to be added. I will submit the change shortly.,0,x build add solaris release builder to dashboard a new host key for host solaris oracle oraclerel was generated the builder needs to be added i will submit the change shortly ,0 416732,28097698583.0,IssuesEvent,2023-03-30 16:58:38,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/go/analysis: pkgsite documentation for golang.org/x/tools/go/analysis/passes/* often lacks details,Documentation Tools pkgsite,"I am not sure if this is a feature request for pkgsite, or it's just because the go analysis analyzer code was structured in a way not friendly with go documentation. Analyzers often place the helpful details in Doc constant, but this long doc is hidden from documentation https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/nilness ![Screenshot 2023-03-09 at 9 10 51 AM](https://user-images.githubusercontent.com/4999471/224050682-c293e809-ffd5-4726-95c7-98f68e79b49d.png) ``` $ go doc package nilness // import ""golang.org/x/tools/go/analysis/passes/nilness"" Package nilness inspects the control-flow graph of an SSA function and reports errors such as nil pointer dereferences and degenerate nil pointer comparisons. const Doc = ... var Analyzer = &analysis.Analyzer{ ... } $ go doc Doc ``` Would be nice if the documentation page of analyzers presents sufficient details. The pattern I saw in similar situation was to generate the package doc (doc.go) from the types but not sure if that's the best way. cc @adonovan @golang/tools-team ",1.0,"x/tools/go/analysis: pkgsite documentation for golang.org/x/tools/go/analysis/passes/* often lacks details - I am not sure if this is a feature request for pkgsite, or it's just because the go analysis analyzer code was structured in a way not friendly with go documentation. Analyzers often place the helpful details in Doc constant, but this long doc is hidden from documentation https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/nilness ![Screenshot 2023-03-09 at 9 10 51 AM](https://user-images.githubusercontent.com/4999471/224050682-c293e809-ffd5-4726-95c7-98f68e79b49d.png) ``` $ go doc package nilness // import ""golang.org/x/tools/go/analysis/passes/nilness"" Package nilness inspects the control-flow graph of an SSA function and reports errors such as nil pointer dereferences and degenerate nil pointer comparisons. const Doc = ... var Analyzer = &analysis.Analyzer{ ... } $ go doc Doc ``` Would be nice if the documentation page of analyzers presents sufficient details. The pattern I saw in similar situation was to generate the package doc (doc.go) from the types but not sure if that's the best way. cc @adonovan @golang/tools-team ",1,x tools go analysis pkgsite documentation for golang org x tools go analysis passes often lacks details i am not sure if this is a feature request for pkgsite or it s just because the go analysis analyzer code was structured in a way not friendly with go documentation analyzers often place the helpful details in doc constant but this long doc is hidden from documentation go doc package nilness import golang org x tools go analysis passes nilness package nilness inspects the control flow graph of an ssa function and reports errors such as nil pointer dereferences and degenerate nil pointer comparisons const doc var analyzer analysis analyzer go doc doc would be nice if the documentation page of analyzers presents sufficient details the pattern i saw in similar situation was to generate the package doc doc go from the types but not sure if that s the best way cc adonovan golang tools team ,1 426859,29667339532.0,IssuesEvent,2023-06-11 00:42:26,golang/go,https://api.github.com/repos/golang/go,closed,cmp: document ordering for floating point values in cmp.Ordered,Documentation NeedsFix,"Although the information is scattered about elsewhere, it would be good for the documentation for `cmp.Ordered` to explain how NaNs work. Then, the documentation for `builtin.min` and `builtin.max` should reference the documentation for `cmp.Ordered` directly (it does indirectly through the declaration). ",1.0,"cmp: document ordering for floating point values in cmp.Ordered - Although the information is scattered about elsewhere, it would be good for the documentation for `cmp.Ordered` to explain how NaNs work. Then, the documentation for `builtin.min` and `builtin.max` should reference the documentation for `cmp.Ordered` directly (it does indirectly through the declaration). ",1,cmp document ordering for floating point values in cmp ordered although the information is scattered about elsewhere it would be good for the documentation for cmp ordered to explain how nans work then the documentation for builtin min and builtin max should reference the documentation for cmp ordered directly it does indirectly through the declaration ,1 81947,10265284653.0,IssuesEvent,2019-08-22 18:28:08,golang/go,https://api.github.com/repos/golang/go,reopened,doc: update release notes for library support for new literals,Documentation release-blocker,"The release notes don't mention all the library changes related to the new number literals. In particular there is new printing in fmt, new parsing in strconv, math/big, and text/scanner. I started to update the notes but there's a lot to add. Filing so I don't forget.",1.0,"doc: update release notes for library support for new literals - The release notes don't mention all the library changes related to the new number literals. In particular there is new printing in fmt, new parsing in strconv, math/big, and text/scanner. I started to update the notes but there's a lot to add. Filing so I don't forget.",1,doc update release notes for library support for new literals the release notes don t mention all the library changes related to the new number literals in particular there is new printing in fmt new parsing in strconv math big and text scanner i started to update the notes but there s a lot to add filing so i don t forget ,1 427447,29813066024.0,IssuesEvent,2023-06-16 16:36:19,golang/go,https://api.github.com/repos/golang/go,closed,runtime: document that MemStats.Lookups is always zero,Documentation NeedsFix compiler/runtime,"package main import ""fmt"" import ""runtime"" func main () { var a = runtime.MemStats{} runtime.ReadMemStats(&a) fmt.Printf(""%+v\n"", a.Lookups) }",1.0,"runtime: document that MemStats.Lookups is always zero - package main import ""fmt"" import ""runtime"" func main () { var a = runtime.MemStats{} runtime.ReadMemStats(&a) fmt.Printf(""%+v\n"", a.Lookups) }",1,runtime document that memstats lookups is always zero package main import fmt import runtime func main var a runtime memstats runtime readmemstats a fmt printf v n a lookups ,1 5308,2921604600.0,IssuesEvent,2015-06-25 03:02:05,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that conn.Hijack might have left-over read/write timeouts on net.Conn,Documentation,"
What does 'go version' print?

Found with go-1.2rc3, present in go-1.3, and still present in the default branch as of
20272:90616fa61ef4.

What steps reproduce the problem?

Setting a ReadTimeout or WriteTimeout on an http.Server and then hijacking a http.conn
(passed as the ResponseWriter) from a request handler leaves the deadlines set on the
connection.

This causes unexpected read and write behavior, requiring an unnatural removal of the
deadlines after hijacking. I found this while implementing the server half of the HTML5
EventSource API, and it also affects any other hijack users (e.g. go.net's websocket
package does not have code to clear deadlines when it takes over a connection; I have
not tested it though.)

A simplified example of the issue is here (probably useful to derive a regression test
from): http://play.golang.org/p/bRyjSayMJN

Adding these two lines fixes the issue:

diff -r 90616fa61ef4 src/pkg/net/http/server.go
--- a/src/pkg/net/http/server.go	Fri Jun 27 18:30:09 2014 -0700
+++ b/src/pkg/net/http/server.go	Fri Jun 27 22:43:18 2014 -0700
@@ -128,18 +128,20 @@
 func (c *conn) hijack() (rwc net.Conn, buf *bufio.ReadWriter, err error) {
 	c.mu.Lock()
 	defer c.mu.Unlock()
 	if c.hijackedv {
 		return nil, nil, ErrHijacked
 	}
 	if c.closeNotifyc != nil {
 		return nil, nil, errors.New("http: Hijack is incompatible with use of CloseNotifier")
 	}
+	c.rwc.SetReadDeadline(time.Time{})
+	c.rwc.SetWriteDeadline(time.Time{})
 	c.hijackedv = true
 	rwc = c.rwc
 	buf = c.buf
 	c.rwc = nil
 	c.buf = nil
 	c.setState(rwc, StateHijacked)
 	return
 }
",1.0,"net/http: document that conn.Hijack might have left-over read/write timeouts on net.Conn - 
What does 'go version' print?

Found with go-1.2rc3, present in go-1.3, and still present in the default branch as of
20272:90616fa61ef4.

What steps reproduce the problem?

Setting a ReadTimeout or WriteTimeout on an http.Server and then hijacking a http.conn
(passed as the ResponseWriter) from a request handler leaves the deadlines set on the
connection.

This causes unexpected read and write behavior, requiring an unnatural removal of the
deadlines after hijacking. I found this while implementing the server half of the HTML5
EventSource API, and it also affects any other hijack users (e.g. go.net's websocket
package does not have code to clear deadlines when it takes over a connection; I have
not tested it though.)

A simplified example of the issue is here (probably useful to derive a regression test
from): http://play.golang.org/p/bRyjSayMJN

Adding these two lines fixes the issue:

diff -r 90616fa61ef4 src/pkg/net/http/server.go
--- a/src/pkg/net/http/server.go	Fri Jun 27 18:30:09 2014 -0700
+++ b/src/pkg/net/http/server.go	Fri Jun 27 22:43:18 2014 -0700
@@ -128,18 +128,20 @@
 func (c *conn) hijack() (rwc net.Conn, buf *bufio.ReadWriter, err error) {
 	c.mu.Lock()
 	defer c.mu.Unlock()
 	if c.hijackedv {
 		return nil, nil, ErrHijacked
 	}
 	if c.closeNotifyc != nil {
 		return nil, nil, errors.New("http: Hijack is incompatible with use of CloseNotifier")
 	}
+	c.rwc.SetReadDeadline(time.Time{})
+	c.rwc.SetWriteDeadline(time.Time{})
 	c.hijackedv = true
 	rwc = c.rwc
 	buf = c.buf
 	c.rwc = nil
 	c.buf = nil
 	c.setState(rwc, StateHijacked)
 	return
 }
",1,net http document that conn hijack might have left over read write timeouts on net conn what does go version print found with go present in go and still present in the default branch as of what steps reproduce the problem setting a readtimeout or writetimeout on an http server and then hijacking a http conn passed as the responsewriter from a request handler leaves the deadlines set on the connection this causes unexpected read and write behavior requiring an unnatural removal of the deadlines after hijacking i found this while implementing the server half of the eventsource api and it also affects any other hijack users e g go net s websocket package does not have code to clear deadlines when it takes over a connection i have not tested it though a simplified example of the issue is here probably useful to derive a regression test from a href adding these two lines fixes the issue diff r src pkg net http server go a src pkg net http server go fri jun b src pkg net http server go fri jun func c conn hijack rwc net conn buf bufio readwriter err error c mu lock defer c mu unlock if c hijackedv return nil nil errhijacked if c closenotifyc nil return nil nil errors new quot http hijack is incompatible with use of closenotifier quot c rwc setreaddeadline time time c rwc setwritedeadline time time c hijackedv true rwc c rwc buf c buf c rwc nil c buf nil c setstate rwc statehijacked return ,1 0,2489415033.0,IssuesEvent,2015-01-01 01:50:25,golang/go,https://api.github.com/repos/golang/go,closed,go.tools/go/vet: excessive imports,helpwanted performance release-none repo-tools,"
Profiling vet on a large corpus shows about >10% time spent in syscalls initiated by
gcimporter.(*parser).next. Many of these reads are avoidable; there is high import
overlap across packages, particularly within a given project.

Concretely, instrumenting calls to Import (in gcimporter.go) and then running 'go vet'
on camlistore yields these top duplicate imports:

 153 fmt.a
 147 testing.a
 120 io.a
 119 strings.a
 113 os.a
 108 bytes.a
  99 time.a
  97 errors.a
  82 io/ioutil.a
  80 log.a
  76 sync.a
  70 strconv.a
  64 net/http.a
  56 path/filepath.a
  51 camlistore.org/pkg/blob.a
  44 runtime.a
  39 sort.a
  39 flag.a
  35 reflect.a
  35 net/url.a
  
These 20 account for 1627 of the 2750 import reads.

Hacking in a quick LRU that simply caches the raw data in the files cuts 'go vet' user
time for camlistore by ~10%. I'm not sure that that is the right long-term approach,
though.
",True,"go.tools/go/vet: excessive imports - 
Profiling vet on a large corpus shows about >10% time spent in syscalls initiated by
gcimporter.(*parser).next. Many of these reads are avoidable; there is high import
overlap across packages, particularly within a given project.

Concretely, instrumenting calls to Import (in gcimporter.go) and then running 'go vet'
on camlistore yields these top duplicate imports:

 153 fmt.a
 147 testing.a
 120 io.a
 119 strings.a
 113 os.a
 108 bytes.a
  99 time.a
  97 errors.a
  82 io/ioutil.a
  80 log.a
  76 sync.a
  70 strconv.a
  64 net/http.a
  56 path/filepath.a
  51 camlistore.org/pkg/blob.a
  44 runtime.a
  39 sort.a
  39 flag.a
  35 reflect.a
  35 net/url.a
  
These 20 account for 1627 of the 2750 import reads.

Hacking in a quick LRU that simply caches the raw data in the files cuts 'go vet' user
time for camlistore by ~10%. I'm not sure that that is the right long-term approach,
though.
",0,go tools go vet excessive imports profiling vet on a large corpus shows about gt time spent in syscalls initiated by gcimporter parser next many of these reads are avoidable there is high import overlap across packages particularly within a given project concretely instrumenting calls to import in gcimporter go and then running go vet on camlistore yields these top duplicate imports fmt a testing a io a strings a os a bytes a time a errors a io ioutil a log a sync a strconv a net http a path filepath a camlistore org pkg blob a runtime a sort a flag a reflect a net url a these account for of the import reads hacking in a quick lru that simply caches the raw data in the files cuts go vet user time for camlistore by i m not sure that that is the right long term approach though ,0 5946,2993245496.0,IssuesEvent,2015-07-22 01:25:45,golang/go,https://api.github.com/repos/golang/go,closed,doc: clarify that new methods may be added to standard library types,Documentation,"Currently the go1compat document states that exported structs in the standard library may add new fields, but it doesn't mention that they may add new methods too. To date, every Go release has added new methods to existing types. For selector expressions, the risk of ambiguity from new methods is the same as for new fields. But if a new method is added to a standard type that's embedded in a user type, it could cause that user type to no longer satisfy existing interfaces due to ambiguity, which is a risk unique to adding new methods.",1.0,"doc: clarify that new methods may be added to standard library types - Currently the go1compat document states that exported structs in the standard library may add new fields, but it doesn't mention that they may add new methods too. To date, every Go release has added new methods to existing types. For selector expressions, the risk of ambiguity from new methods is the same as for new fields. But if a new method is added to a standard type that's embedded in a user type, it could cause that user type to no longer satisfy existing interfaces due to ambiguity, which is a risk unique to adding new methods.",1,doc clarify that new methods may be added to standard library types currently the document states that exported structs in the standard library may add new fields but it doesn t mention that they may add new methods too to date every go release has added new methods to existing types for selector expressions the risk of ambiguity from new methods is the same as for new fields but if a new method is added to a standard type that s embedded in a user type it could cause that user type to no longer satisfy existing interfaces due to ambiguity which is a risk unique to adding new methods ,1 80005,10149101863.0,IssuesEvent,2019-08-05 14:33:13,golang/go,https://api.github.com/repos/golang/go,opened,doc: add Unicode 11 support to Go 1.13 release notes,Documentation NeedsFix release-blocker,"Tracking issue for Unicode 11 support: #27945 APIs changed: ``` pkg unicode, const Version = ""11.0.0"" pkg unicode, var Dogra *RangeTable pkg unicode, var Gunjala_Gondi *RangeTable pkg unicode, var Hanifi_Rohingya *RangeTable pkg unicode, var Makasar *RangeTable pkg unicode, var Medefaidrin *RangeTable pkg unicode, var Old_Sogdian *RangeTable pkg unicode, var Sogdian *RangeTable ``` /cc @mpvl ",1.0,"doc: add Unicode 11 support to Go 1.13 release notes - Tracking issue for Unicode 11 support: #27945 APIs changed: ``` pkg unicode, const Version = ""11.0.0"" pkg unicode, var Dogra *RangeTable pkg unicode, var Gunjala_Gondi *RangeTable pkg unicode, var Hanifi_Rohingya *RangeTable pkg unicode, var Makasar *RangeTable pkg unicode, var Medefaidrin *RangeTable pkg unicode, var Old_Sogdian *RangeTable pkg unicode, var Sogdian *RangeTable ``` /cc @mpvl ",1,doc add unicode support to go release notes tracking issue for unicode support apis changed pkg unicode const version pkg unicode var dogra rangetable pkg unicode var gunjala gondi rangetable pkg unicode var hanifi rohingya rangetable pkg unicode var makasar rangetable pkg unicode var medefaidrin rangetable pkg unicode var old sogdian rangetable pkg unicode var sogdian rangetable cc mpvl ,1 32656,6101589302.0,IssuesEvent,2017-06-20 14:53:48,golang/go,https://api.github.com/repos/golang/go,closed,Website documentation,Documentation,"If we open exaple on page https://golang.org/pkg/go/parser/ and run in play. ### what you see? open example_test.go: No such file or directory ### What did you expect to see? The result of snippet code ",1.0,"Website documentation - If we open exaple on page https://golang.org/pkg/go/parser/ and run in play. ### what you see? open example_test.go: No such file or directory ### What did you expect to see? The result of snippet code ",1,website documentation if we open exaple on page and run in play what you see open example test go no such file or directory what did you expect to see the result of snippet code ,1 70345,9403660307.0,IssuesEvent,2019-04-09 02:25:58,golang/go,https://api.github.com/repos/golang/go,closed,spec: poorly documented slice definition syntax,Documentation WaitingForInfo," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.1 linux/amd64
But also on Windows and in Go 1.12 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/felian/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/felian/go_code""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build955872785=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://play.golang.org/p/clO1qELMYH2 
package main
import ""fmt""
func main() { fmt.Println([]int{1, 2, 3, 7: 3, 6, 7}) }
Also works nicely with arrays, and with multiple `:`: 
fmt.Println([20]int{1, 2, 3, 7: 11, 12, 13: 10})
fmt.Println([30]int{1, 2, 3, 7: 11, 12, 13: 10, 18: 11, 25})
### What did you expect to see? This syntax should be well documented or invalid. I found one example of this after ""Examples of valid array, slice, and map literals:"" in [language specification](https://golang.org/ref/spec). But it seems not enough. ### What did you see instead? This syntax is valid and seems poorly documented. Thanks for directions to @irwinnoteam2009",1.0,"spec: poorly documented slice definition syntax - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.11.1 linux/amd64
But also on Windows and in Go 1.12 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/felian/.cache/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOOS=""linux""
GOPATH=""/home/felian/go_code""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/go""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GCCGO=""gccgo""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""""
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-build955872785=/tmp/go-build -gno-record-gcc-switches""
### What did you do? https://play.golang.org/p/clO1qELMYH2 
package main
import ""fmt""
func main() { fmt.Println([]int{1, 2, 3, 7: 3, 6, 7}) }
Also works nicely with arrays, and with multiple `:`: 
fmt.Println([20]int{1, 2, 3, 7: 11, 12, 13: 10})
fmt.Println([30]int{1, 2, 3, 7: 11, 12, 13: 10, 18: 11, 25})
### What did you expect to see? This syntax should be well documented or invalid. I found one example of this after ""Examples of valid array, slice, and map literals:"" in [language specification](https://golang.org/ref/spec). But it seems not enough. ### What did you see instead? This syntax is valid and seems poorly documented. Thanks for directions to @irwinnoteam2009",1,spec poorly documented slice definition syntax what version of go are you using go version go version go version linux but also on windows and in go does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home felian cache go build goexe goflags gohostarch gohostos linux goos linux gopath home felian go code goproxy gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches 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 package main import fmt func main fmt println int also works nicely with arrays and with multiple fmt println int fmt println int what did you expect to see this syntax should be well documented or invalid i found one example of this after examples of valid array slice and map literals in but it seems not enough what did you see instead this syntax is valid and seems poorly documented thanks for directions to ,1 295328,22207963410.0,IssuesEvent,2022-06-07 16:23:52,golang/go,https://api.github.com/repos/golang/go,closed,go/doc: find a better home for Go documentation features like section headings,Documentation NeedsFix,"[fluhus/godoc-tricks](https://github.com/fluhus/godoc-tricks) describes several extended tricks for the Godoc renderer that remain relevant for https://pkg.go.dev. Particularly notable is the technique described as [Titles](https://pkg.go.dev/github.com/fluhus/godoc-tricks#Titles), which can be thought of as naive section headings as demonstrated below with the word ""Limitations"": ```go // CreditCard models a lender-backed payment instrument. // // Limitations // // The type provides no native validation against its issuer. It is a dumb data type. type CreditCard struct{} ``` To date this technique is not substantively mentioned in any of the following: * https://blog.golang.org/godoc * https://golang.org/pkg/go/doc/ (minor prosaic allusion) Considering its utility for information presentation, anchoring, etc., I propose the feature earn proper documentation. I tried to search for an existing bug for this, but the closest thing I could find was https://github.com/golang/go/issues/18342. The correct approach would probably involve amending the previous documents somehow (or maybe another).",1.0,"go/doc: find a better home for Go documentation features like section headings - [fluhus/godoc-tricks](https://github.com/fluhus/godoc-tricks) describes several extended tricks for the Godoc renderer that remain relevant for https://pkg.go.dev. Particularly notable is the technique described as [Titles](https://pkg.go.dev/github.com/fluhus/godoc-tricks#Titles), which can be thought of as naive section headings as demonstrated below with the word ""Limitations"": ```go // CreditCard models a lender-backed payment instrument. // // Limitations // // The type provides no native validation against its issuer. It is a dumb data type. type CreditCard struct{} ``` To date this technique is not substantively mentioned in any of the following: * https://blog.golang.org/godoc * https://golang.org/pkg/go/doc/ (minor prosaic allusion) Considering its utility for information presentation, anchoring, etc., I propose the feature earn proper documentation. I tried to search for an existing bug for this, but the closest thing I could find was https://github.com/golang/go/issues/18342. The correct approach would probably involve amending the previous documents somehow (or maybe another).",1,go doc find a better home for go documentation features like section headings describes several extended tricks for the godoc renderer that remain relevant for particularly notable is the technique described as which can be thought of as naive section headings as demonstrated below with the word limitations go creditcard models a lender backed payment instrument limitations the type provides no native validation against its issuer it is a dumb data type type creditcard struct to date this technique is not substantively mentioned in any of the following minor prosaic allusion considering its utility for information presentation anchoring etc i propose the feature earn proper documentation i tried to search for an existing bug for this but the closest thing i could find was the correct approach would probably involve amending the previous documents somehow or maybe another ,1 173274,14406753531.0,IssuesEvent,2020-12-03 20:43:06,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document compiler changes for Go 1.16,Documentation NeedsInvestigation release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:

Compiler

TODO

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. (If there aren't noteworthy compiler changes in Go 1.16, the section should be removed.) A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document compiler changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:

Compiler

TODO

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. (If there aren't noteworthy compiler changes in Go 1.16, the section should be removed.) A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document compiler changes for go as of filing this issue the contained the following html compiler todo per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved if there aren t noteworthy compiler changes in go the section should be removed a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 6395,5408708840.0,IssuesEvent,2017-03-01 01:02:42,golang/go,https://api.github.com/repos/golang/go,closed,runtime: convT2E called for function value ,Performance,"Go 1.8 amd64 linux when running the below program `convT2E` is called for `BenchmarkEfaceFnVal` but not for `BenchmarkEfaceFn`. **Program:** ```Go package main import ""testing"" func efaceFn(v interface{}) { return } func BenchmarkEfaceFnVal(b *testing.B) { b.ReportAllocs() efaceFnVal := efaceFn for i := 0; i < b.N; i++ { efaceFnVal(0x1) } } func BenchmarkEfaceFn(b *testing.B) { b.ReportAllocs() for i := 0; i < b.N; i++ { efaceFn(0x1) } } ``` **Result:** | Name | Iterations | ns/op | B/op | allocs/op | | -- | -- | -- | -- | -- | | BenchmarkEfaceFnVal-24 | 20000000 | 60.8 ns/op | 8 B/op | 1 allocs/op | | BenchmarkEfaceFn-24 | 2000000000 | 0.48 ns/op | 0 B/op | 0 allocs/op | ",True,"runtime: convT2E called for function value - Go 1.8 amd64 linux when running the below program `convT2E` is called for `BenchmarkEfaceFnVal` but not for `BenchmarkEfaceFn`. **Program:** ```Go package main import ""testing"" func efaceFn(v interface{}) { return } func BenchmarkEfaceFnVal(b *testing.B) { b.ReportAllocs() efaceFnVal := efaceFn for i := 0; i < b.N; i++ { efaceFnVal(0x1) } } func BenchmarkEfaceFn(b *testing.B) { b.ReportAllocs() for i := 0; i < b.N; i++ { efaceFn(0x1) } } ``` **Result:** | Name | Iterations | ns/op | B/op | allocs/op | | -- | -- | -- | -- | -- | | BenchmarkEfaceFnVal-24 | 20000000 | 60.8 ns/op | 8 B/op | 1 allocs/op | | BenchmarkEfaceFn-24 | 2000000000 | 0.48 ns/op | 0 B/op | 0 allocs/op | ",0,runtime called for function value go linux when running the below program is called for benchmarkefacefnval but not for benchmarkefacefn program go package main import testing func efacefn v interface return func benchmarkefacefnval b testing b b reportallocs efacefnval efacefn for i i b n i efacefnval func benchmarkefacefn b testing b b reportallocs for i i b n i efacefn result name iterations ns op b op allocs op benchmarkefacefnval ns op b op allocs op benchmarkefacefn ns op b op allocs op ,0 33957,6276688397.0,IssuesEvent,2017-07-18 10:10:22,golang/go,https://api.github.com/repos/golang/go,closed,x/review/git-codereview: -trybot option not documented,Documentation,"Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? - `go version go1.6 darwin/amd64` 2. What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/.../Source/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 1. What did you do? `go codereview mail -h` describes an option, `-trybot`, but neither `go codereview help` nor https://godoc.org/golang.org/x/review/git-codereview describes the option 2. What did you expect to see? Something telling me what the `-trybot` option does (esp. if I can use it). 3. What did you see instead? Nothing telling me what `-trybot` does. ",1.0,"x/review/git-codereview: -trybot option not documented - Please answer these questions before submitting your issue. Thanks! 1. What version of Go are you using (`go version`)? - `go version go1.6 darwin/amd64` 2. What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/.../Source/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 1. What did you do? `go codereview mail -h` describes an option, `-trybot`, but neither `go codereview help` nor https://godoc.org/golang.org/x/review/git-codereview describes the option 2. What did you expect to see? Something telling me what the `-trybot` option does (esp. if I can use it). 3. What did you see instead? Nothing telling me what `-trybot` does. ",1,x review git codereview trybot option not documented please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users source go gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fno common cxx clang cgo enabled what did you do go codereview mail h describes an option trybot but neither go codereview help nor describes the option what did you expect to see something telling me what the trybot option does esp if i can use it what did you see instead nothing telling me what trybot does ,1 49159,6015199229.0,IssuesEvent,2017-06-07 00:56:33,golang/go,https://api.github.com/repos/golang/go,closed,runtime: spurious error in TestPanicRace,HelpWanted Testing,"Saw on the trybots for CL 45018: --- FAIL: TestPanicRace (0.00s) crash_test.go:584: program exited successfully, should have failed crash_test.go:587: crash_test.go:596: did not find expected string ""panic: crash"" crash_test.go:596: did not find expected string ""PanicRace"" crash_test.go:596: did not find expected string ""created by "" I don't think this has anything to do with my CL, it only does additional compile-time checks, and those checks are not enabled on this builder. Flaky test? https://storage.googleapis.com/go-build-log/6c7e4f31/linux-amd64_b2988fea.log ",1.0,"runtime: spurious error in TestPanicRace - Saw on the trybots for CL 45018: --- FAIL: TestPanicRace (0.00s) crash_test.go:584: program exited successfully, should have failed crash_test.go:587: crash_test.go:596: did not find expected string ""panic: crash"" crash_test.go:596: did not find expected string ""PanicRace"" crash_test.go:596: did not find expected string ""created by "" I don't think this has anything to do with my CL, it only does additional compile-time checks, and those checks are not enabled on this builder. Flaky test? https://storage.googleapis.com/go-build-log/6c7e4f31/linux-amd64_b2988fea.log ",0,runtime spurious error in testpanicrace saw on the trybots for cl fail testpanicrace crash test go program exited successfully should have failed crash test go crash test go did not find expected string panic crash crash test go did not find expected string panicrace crash test go did not find expected string created by i don t think this has anything to do with my cl it only does additional compile time checks and those checks are not enabled on this builder flaky test ,0 55774,8029919049.0,IssuesEvent,2018-07-27 17:43:34,golang/go,https://api.github.com/repos/golang/go,closed,syscall: improve NewCallback documentation and panic message,Documentation OS-Windows help wanted,"### What version of Go are you using (`go version`)? Tip (commit 65d55a13a92a3) ### Does this issue reproduce with the latest release? Yes. `syscall.NewCallback` (and `syscall.NewCallbackCDecl`) don't describe what's expected of the type of their argument beyond ""it must be a function"". But they do have requirements. For example, if you pass a function with no argument and no results, they panic with ""compileCallback: function must have one output parameter"". I don't actually know what this means a priori, and the `NewCallback` documentation doesn't tell me. The term ""output parameter"" doesn't appear in the Go spec, and it could (and does in this case) mean a result value, or it could mean a C-style output parameter which is actually an input argument that points to where to put the result. We should document `NewCallback*`'s requirements and clarify the panic message for when they're violated. /cc @alexbrainman ",1.0,"syscall: improve NewCallback documentation and panic message - ### What version of Go are you using (`go version`)? Tip (commit 65d55a13a92a3) ### Does this issue reproduce with the latest release? Yes. `syscall.NewCallback` (and `syscall.NewCallbackCDecl`) don't describe what's expected of the type of their argument beyond ""it must be a function"". But they do have requirements. For example, if you pass a function with no argument and no results, they panic with ""compileCallback: function must have one output parameter"". I don't actually know what this means a priori, and the `NewCallback` documentation doesn't tell me. The term ""output parameter"" doesn't appear in the Go spec, and it could (and does in this case) mean a result value, or it could mean a C-style output parameter which is actually an input argument that points to where to put the result. We should document `NewCallback*`'s requirements and clarify the panic message for when they're violated. /cc @alexbrainman ",1,syscall improve newcallback documentation and panic message what version of go are you using go version tip commit does this issue reproduce with the latest release yes syscall newcallback and syscall newcallbackcdecl don t describe what s expected of the type of their argument beyond it must be a function but they do have requirements for example if you pass a function with no argument and no results they panic with compilecallback function must have one output parameter i don t actually know what this means a priori and the newcallback documentation doesn t tell me the term output parameter doesn t appear in the go spec and it could and does in this case mean a result value or it could mean a c style output parameter which is actually an input argument that points to where to put the result we should document newcallback s requirements and clarify the panic message for when they re violated cc alexbrainman ,1 321237,23847309952.0,IssuesEvent,2022-09-06 14:55:24,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: The analyzers documentation doesn't mention some analyzers,Documentation gopls Tools," ### gopls version ### What did you do? I read x/tools/gopls/doc/analyzers.md to try to find the setting that would turn off useless messages labelled QF1003. ### What did you expect to see? Some mention of QF1003, or a hint about where to find information about it. ### What did you see instead? nothing. ### Editor and settings ",1.0,"x/tools/gopls: The analyzers documentation doesn't mention some analyzers - ### gopls version ### What did you do? I read x/tools/gopls/doc/analyzers.md to try to find the setting that would turn off useless messages labelled QF1003. ### What did you expect to see? Some mention of QF1003, or a hint about where to find information about it. ### What did you see instead? nothing. ### Editor and settings ",1,x tools gopls the analyzers documentation doesn t mention some analyzers gopls version build info golang org x tools gopls master golang org x tools gopls devel github com burntsushi toml github com google go cmp github com sergi go diff golang org x mod dev kqgndtypbw o golang org x sync golang org x sys rm golang org x text golang org x tools devel golang org x xerrors d honnef co go tools mvdan cc gofumpt mvdan cc xurls tzxjvaj go what did you do i read x tools gopls doc analyzers md to try to find the setting that would turn off useless messages labelled what did you expect to see some mention of or a hint about where to find information about it what did you see instead nothing editor and settings ,1 26838,7874781602.0,IssuesEvent,2018-06-25 18:11:58,golang/go,https://api.github.com/repos/golang/go,opened,x/build: add js/wasm Chrome/Firefox capable trybot,Arch-Wasm Builders NeedsDecision,"Follow on from https://github.com/golang/go/issues/26015#issuecomment-400029578 With a Chrome and/or Firefox capable trybot we'd be able to do more interesting WASM tests in a headless browser-based JS VM, and so have access to the DOM etc. This issue is to decide whether or not such a trybot would be useful and therefore worth the effort.",1.0,"x/build: add js/wasm Chrome/Firefox capable trybot - Follow on from https://github.com/golang/go/issues/26015#issuecomment-400029578 With a Chrome and/or Firefox capable trybot we'd be able to do more interesting WASM tests in a headless browser-based JS VM, and so have access to the DOM etc. This issue is to decide whether or not such a trybot would be useful and therefore worth the effort.",0,x build add js wasm chrome firefox capable trybot follow on from with a chrome and or firefox capable trybot we d be able to do more interesting wasm tests in a headless browser based js vm and so have access to the dom etc this issue is to decide whether or not such a trybot would be useful and therefore worth the effort ,0 385257,26627505520.0,IssuesEvent,2023-01-24 15:30:33,golang/go,https://api.github.com/repos/golang/go,closed,"x/website: Fuzzing documentation image has transparent background, works poorly with dark mode",Documentation NeedsFix website,"The fuzzing page, https://tip.golang.org/security/fuzz/, has an image describing different components involved. It however has a transparent background, and with the page supporting dark mode, the image gets very tricky to read: ![image](https://user-images.githubusercontent.com/214867/189207556-9c10f2e7-894a-4b8c-be87-678fb45a21a9.png) I'm not sure if having a opaque white background would be problematic, but that seems to be the easiest solution.",1.0,"x/website: Fuzzing documentation image has transparent background, works poorly with dark mode - The fuzzing page, https://tip.golang.org/security/fuzz/, has an image describing different components involved. It however has a transparent background, and with the page supporting dark mode, the image gets very tricky to read: ![image](https://user-images.githubusercontent.com/214867/189207556-9c10f2e7-894a-4b8c-be87-678fb45a21a9.png) I'm not sure if having a opaque white background would be problematic, but that seems to be the easiest solution.",1,x website fuzzing documentation image has transparent background works poorly with dark mode the fuzzing page has an image describing different components involved it however has a transparent background and with the page supporting dark mode the image gets very tricky to read i m not sure if having a opaque white background would be problematic but that seems to be the easiest solution ,1 3636,3973715029.0,IssuesEvent,2016-05-04 19:34:37,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: precalculate constant square roots,Performance,"Low priority, but probably also an easy ssa rule. ```go package x import ""math"" func root2() float64 { return math.Sqrt(2) } ``` yields (amd64): ``` """".root2 t=1 size=32 args=0x8 locals=0x0 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) TEXT """".root2(SB), $0-8 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) NOP 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) NOP 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) FUNCDATA $0, gclocals·5184031d3a32a42d85027f073f873668(SB) 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:6) MOVSD $f64.4000000000000000(SB), X0 0x0008 00008 (/Volumes/Data/src/go.tip/src/sqrt.go:6) SQRTSD X0, X0 0x000c 00012 (/Volumes/Data/src/go.tip/src/sqrt.go:6) MOVSD X0, """".~r0+8(FP) 0x0012 00018 (/Volumes/Data/src/go.tip/src/sqrt.go:6) RET ``` But sqrt(2) is a constant. cc @randall77 @brtzsnr ",True,"cmd/compile: precalculate constant square roots - Low priority, but probably also an easy ssa rule. ```go package x import ""math"" func root2() float64 { return math.Sqrt(2) } ``` yields (amd64): ``` """".root2 t=1 size=32 args=0x8 locals=0x0 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) TEXT """".root2(SB), $0-8 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) NOP 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) NOP 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) FUNCDATA $0, gclocals·5184031d3a32a42d85027f073f873668(SB) 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:5) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0000 00000 (/Volumes/Data/src/go.tip/src/sqrt.go:6) MOVSD $f64.4000000000000000(SB), X0 0x0008 00008 (/Volumes/Data/src/go.tip/src/sqrt.go:6) SQRTSD X0, X0 0x000c 00012 (/Volumes/Data/src/go.tip/src/sqrt.go:6) MOVSD X0, """".~r0+8(FP) 0x0012 00018 (/Volumes/Data/src/go.tip/src/sqrt.go:6) RET ``` But sqrt(2) is a constant. cc @randall77 @brtzsnr ",0,cmd compile precalculate constant square roots low priority but probably also an easy ssa rule go package x import math func return math sqrt yields t size args locals volumes data src go tip src sqrt go text sb volumes data src go tip src sqrt go nop volumes data src go tip src sqrt go nop volumes data src go tip src sqrt go funcdata gclocals· sb volumes data src go tip src sqrt go funcdata gclocals· sb volumes data src go tip src sqrt go movsd sb volumes data src go tip src sqrt go sqrtsd volumes data src go tip src sqrt go movsd fp volumes data src go tip src sqrt go ret but sqrt is a constant cc brtzsnr ,0 50208,6065411421.0,IssuesEvent,2017-06-14 16:09:35,golang/go,https://api.github.com/repos/golang/go,closed,runtime/pprof: TestMutexProfile flakiness,Testing,"On the builders, I see TestMutexProfile occasionally failing with ``` --- FAIL: TestMutexProfile (0.01s) pprof_test.go:532: expected 6 lines, got 3 ""--- mutex:\ncycles/second=2362842166\nsampling period=1"" --- mutex: cycles/second=2362842166 sampling period=1 FAIL FAIL runtime/pprof 1.298s ``` Maybe freebsd only? @pjweinb Some builder logs: https://build.golang.org/log/c625cca078dac40bc5f1f50b62891c04b52308c5 https://build.golang.org/log/118de984fc0903fe93c3e677962cd7965637a2a3",1.0,"runtime/pprof: TestMutexProfile flakiness - On the builders, I see TestMutexProfile occasionally failing with ``` --- FAIL: TestMutexProfile (0.01s) pprof_test.go:532: expected 6 lines, got 3 ""--- mutex:\ncycles/second=2362842166\nsampling period=1"" --- mutex: cycles/second=2362842166 sampling period=1 FAIL FAIL runtime/pprof 1.298s ``` Maybe freebsd only? @pjweinb Some builder logs: https://build.golang.org/log/c625cca078dac40bc5f1f50b62891c04b52308c5 https://build.golang.org/log/118de984fc0903fe93c3e677962cd7965637a2a3",0,runtime pprof testmutexprofile flakiness on the builders i see testmutexprofile occasionally failing with fail testmutexprofile pprof test go expected lines got mutex ncycles second nsampling period mutex cycles second sampling period fail fail runtime pprof maybe freebsd only pjweinb some builder logs ,0 85647,24647589337.0,IssuesEvent,2022-10-17 15:55:53,golang/go,https://api.github.com/repos/golang/go,closed,net/http: TestIssue4191_InfiniteGetTimeout is flaky again on the freebsd/arm builder,OS-FreeBSD Builders,"``` ok net 13.891s 2022/10/14 23:31:37 http: TLS handshake error from 127.0.0.1:42528: read tcp 127.0.0.1:42527->127.0.0.1:42528: read: connection reset by peer 2022/10/14 23:31:37 http2: server: error reading preface from client 127.0.0.1:42531: local error: tls: bad record MAC 2022/10/14 23:31:40 http: TLS handshake error from 127.0.0.1:42548: read tcp 127.0.0.1:42547->127.0.0.1:42548: read: connection reset by peer --- FAIL: TestIssue4191_InfiniteGetTimeout (0.00s) --- FAIL: TestIssue4191_InfiniteGetTimeout/h1 (1.77s) transport_test.go:2170: increasing timeout transport_test.go:2175: Error issuing GET: Get ""https://127.0.0.1:42527/get"": write tcp 127.0.0.1:42531->127.0.0.1:42527: i/o timeout 2022/10/14 23:31:47 http2: server: error reading preface from client 127.0.0.1:42638: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/14 23:31:48 http2: server: error reading preface from client 127.0.0.1:42647: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/14 23:31:49 http: TLS handshake error from 127.0.0.1:42694: write tcp 127.0.0.1:42693->127.0.0.1:42694: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42698: write tcp 127.0.0.1:42697->127.0.0.1:42698: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42700: write tcp 127.0.0.1:42699->127.0.0.1:42700: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42704: write tcp 127.0.0.1:42703->127.0.0.1:42704: i/o timeout 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42863: read tcp 127.0.0.1:42858->127.0.0.1:42863: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42868: write tcp 127.0.0.1:42858->127.0.0.1:42868: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42860: write tcp 127.0.0.1:42858->127.0.0.1:42860: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42859: write tcp 127.0.0.1:42858->127.0.0.1:42859: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42875: write tcp 127.0.0.1:42869->127.0.0.1:42875: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42877: write tcp 127.0.0.1:42869->127.0.0.1:42877: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42873: write tcp 127.0.0.1:42869->127.0.0.1:42873: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42878: write tcp 127.0.0.1:42869->127.0.0.1:42878: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42879: write tcp 127.0.0.1:42869->127.0.0.1:42879: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42871: write tcp 127.0.0.1:42869->127.0.0.1:42871: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42874: write tcp 127.0.0.1:42869->127.0.0.1:42874: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42862: write tcp 127.0.0.1:42858->127.0.0.1:42862: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42876: write tcp 127.0.0.1:42869->127.0.0.1:42876: use of closed network connection 2022/10/14 23:32:04 http: TLS handshake error from 127.0.0.1:42956: EOF 2022/10/14 23:32:04 http: TLS handshake error from 127.0.0.1:42958: EOF 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43076: EOF 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43079: read tcp 127.0.0.1:43078->127.0.0.1:43079: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43083: read tcp 127.0.0.1:43075->127.0.0.1:43083: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43077: read tcp 127.0.0.1:43075->127.0.0.1:43077: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43082: read tcp 127.0.0.1:43078->127.0.0.1:43082: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43084: read tcp 127.0.0.1:43078->127.0.0.1:43084: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43085: read tcp 127.0.0.1:43075->127.0.0.1:43085: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43087: read tcp 127.0.0.1:43075->127.0.0.1:43087: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43086: read tcp 127.0.0.1:43078->127.0.0.1:43086: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43088: read tcp 127.0.0.1:43078->127.0.0.1:43088: read: connection reset by peer FAIL FAIL net/http 91.402s ``` https://build.golang.org/log/b40a6e5b2861f487c38fae158286aac8f1120768",1.0,"net/http: TestIssue4191_InfiniteGetTimeout is flaky again on the freebsd/arm builder - ``` ok net 13.891s 2022/10/14 23:31:37 http: TLS handshake error from 127.0.0.1:42528: read tcp 127.0.0.1:42527->127.0.0.1:42528: read: connection reset by peer 2022/10/14 23:31:37 http2: server: error reading preface from client 127.0.0.1:42531: local error: tls: bad record MAC 2022/10/14 23:31:40 http: TLS handshake error from 127.0.0.1:42548: read tcp 127.0.0.1:42547->127.0.0.1:42548: read: connection reset by peer --- FAIL: TestIssue4191_InfiniteGetTimeout (0.00s) --- FAIL: TestIssue4191_InfiniteGetTimeout/h1 (1.77s) transport_test.go:2170: increasing timeout transport_test.go:2175: Error issuing GET: Get ""https://127.0.0.1:42527/get"": write tcp 127.0.0.1:42531->127.0.0.1:42527: i/o timeout 2022/10/14 23:31:47 http2: server: error reading preface from client 127.0.0.1:42638: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/14 23:31:48 http2: server: error reading preface from client 127.0.0.1:42647: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/14 23:31:49 http: TLS handshake error from 127.0.0.1:42694: write tcp 127.0.0.1:42693->127.0.0.1:42694: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42698: write tcp 127.0.0.1:42697->127.0.0.1:42698: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42700: write tcp 127.0.0.1:42699->127.0.0.1:42700: i/o timeout 2022/10/14 23:31:50 http: TLS handshake error from 127.0.0.1:42704: write tcp 127.0.0.1:42703->127.0.0.1:42704: i/o timeout 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42863: read tcp 127.0.0.1:42858->127.0.0.1:42863: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42868: write tcp 127.0.0.1:42858->127.0.0.1:42868: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42860: write tcp 127.0.0.1:42858->127.0.0.1:42860: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42859: write tcp 127.0.0.1:42858->127.0.0.1:42859: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42875: write tcp 127.0.0.1:42869->127.0.0.1:42875: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42877: write tcp 127.0.0.1:42869->127.0.0.1:42877: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42873: write tcp 127.0.0.1:42869->127.0.0.1:42873: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42878: write tcp 127.0.0.1:42869->127.0.0.1:42878: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42879: write tcp 127.0.0.1:42869->127.0.0.1:42879: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42871: write tcp 127.0.0.1:42869->127.0.0.1:42871: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42874: write tcp 127.0.0.1:42869->127.0.0.1:42874: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42862: write tcp 127.0.0.1:42858->127.0.0.1:42862: use of closed network connection 2022/10/14 23:32:01 http: TLS handshake error from 127.0.0.1:42876: write tcp 127.0.0.1:42869->127.0.0.1:42876: use of closed network connection 2022/10/14 23:32:04 http: TLS handshake error from 127.0.0.1:42956: EOF 2022/10/14 23:32:04 http: TLS handshake error from 127.0.0.1:42958: EOF 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43076: EOF 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43079: read tcp 127.0.0.1:43078->127.0.0.1:43079: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43083: read tcp 127.0.0.1:43075->127.0.0.1:43083: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43077: read tcp 127.0.0.1:43075->127.0.0.1:43077: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43082: read tcp 127.0.0.1:43078->127.0.0.1:43082: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43084: read tcp 127.0.0.1:43078->127.0.0.1:43084: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43085: read tcp 127.0.0.1:43075->127.0.0.1:43085: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43087: read tcp 127.0.0.1:43075->127.0.0.1:43087: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43086: read tcp 127.0.0.1:43078->127.0.0.1:43086: read: connection reset by peer 2022/10/14 23:32:13 http: TLS handshake error from 127.0.0.1:43088: read tcp 127.0.0.1:43078->127.0.0.1:43088: read: connection reset by peer FAIL FAIL net/http 91.402s ``` https://build.golang.org/log/b40a6e5b2861f487c38fae158286aac8f1120768",0,net http infinitegettimeout is flaky again on the freebsd arm builder ok net http tls handshake error from read tcp read connection reset by peer server error reading preface from client local error tls bad record mac http tls handshake error from read tcp read connection reset by peer fail infinitegettimeout fail infinitegettimeout transport test go increasing timeout transport test go error issuing get get write tcp i o timeout server error reading preface from client bogus greeting connect golang fake tld server error reading preface from client bogus greeting connect golang fake tld http tls handshake error from write tcp i o timeout http tls handshake error from write tcp i o timeout http tls handshake error from write tcp i o timeout http tls handshake error from write tcp i o timeout http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from eof http tls handshake error from eof http tls handshake error from eof http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer http tls handshake error from read tcp read connection reset by peer fail fail net http ,0 81979,10265943341.0,IssuesEvent,2019-08-22 20:08:58,golang/go,https://api.github.com/repos/golang/go,closed,"os, syscall: changes to os.Err* and syscall.Errno not mentioned in release notes and syscall package docs",Documentation NeedsFix release-blocker,"The changes made to the `os` and `syscall` package for #30322 are not mentioned in the Go 1.13 release notes, nor in the documentation for `syscall.Errno` or the `syscall` package. Because users in general cannot redefine the error behavior of the errors defined by their dependencies, as a user I would not expect `syscall.Errno` errors to be defined as equivalent to errors defined in the higher-level `os` package. As noted in #32463 and #33411, the fact that they are has significant, non-trivial implications. If `errors.Is` is now recommended and supported for checking the properties of `syscall.Errno` errors, the `syscall.Errno` documentation and the Go 1.13 release notes should be updated to mention that. CC @neild @jba @mpvl @rsc @andybons @ianlancetaylor ",1.0,"os, syscall: changes to os.Err* and syscall.Errno not mentioned in release notes and syscall package docs - The changes made to the `os` and `syscall` package for #30322 are not mentioned in the Go 1.13 release notes, nor in the documentation for `syscall.Errno` or the `syscall` package. Because users in general cannot redefine the error behavior of the errors defined by their dependencies, as a user I would not expect `syscall.Errno` errors to be defined as equivalent to errors defined in the higher-level `os` package. As noted in #32463 and #33411, the fact that they are has significant, non-trivial implications. If `errors.Is` is now recommended and supported for checking the properties of `syscall.Errno` errors, the `syscall.Errno` documentation and the Go 1.13 release notes should be updated to mention that. CC @neild @jba @mpvl @rsc @andybons @ianlancetaylor ",1,os syscall changes to os err and syscall errno not mentioned in release notes and syscall package docs the changes made to the os and syscall package for are not mentioned in the go release notes nor in the documentation for syscall errno or the syscall package because users in general cannot redefine the error behavior of the errors defined by their dependencies as a user i would not expect syscall errno errors to be defined as equivalent to errors defined in the higher level os package as noted in and the fact that they are has significant non trivial implications if errors is is now recommended and supported for checking the properties of syscall errno errors the syscall errno documentation and the go release notes should be updated to mention that cc neild jba mpvl rsc andybons ianlancetaylor ,1 22096,4772943492.0,IssuesEvent,2016-10-26 22:25:48,golang/go,https://api.github.com/repos/golang/go,closed,net/http: ambiguous sentence in docs for Response.ParseForm,Documentation NeedsFix,"Please answer these questions before submitting your issue. Thanks! 1 What version of Go are you using (`go version`)? go1.6.2 2 What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/cjohnson/Documents/Code/Golang"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6.2/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 3 What did you do? ```shell $ go doc http.ParseForm func (r *Request) ParseForm() error ParseForm parses the raw query from the URL and updates r.Form. For POST or PUT requests, it also parses the request body as a form and put the results into both r.PostForm and r.Form. POST and PUT body parameters take precedence over URL query string values in r.Form. If the request Body's size has not already been limited by MaxBytesReader, the size is capped at 10MB. ParseMultipartForm calls ParseForm automatically. It is idempotent. ``` 4 What did you expect to see? Grammatically unambiguous documentation. 5 What did you see instead? In ""It is idempotent,"" ""it"" ambiguously refers to `ParseForm` or `ParseMultipartForm` or both. I think it should be `ParseForm`, but I'm not sure. Maybe both?",1.0,"net/http: ambiguous sentence in docs for Response.ParseForm - Please answer these questions before submitting your issue. Thanks! 1 What version of Go are you using (`go version`)? go1.6.2 2 What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/cjohnson/Documents/Code/Golang"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.6.2/libexec"" GOTOOLDIR=""/usr/local/Cellar/go/1.6.2/libexec/pkg/tool/darwin_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` 3 What did you do? ```shell $ go doc http.ParseForm func (r *Request) ParseForm() error ParseForm parses the raw query from the URL and updates r.Form. For POST or PUT requests, it also parses the request body as a form and put the results into both r.PostForm and r.Form. POST and PUT body parameters take precedence over URL query string values in r.Form. If the request Body's size has not already been limited by MaxBytesReader, the size is capped at 10MB. ParseMultipartForm calls ParseForm automatically. It is idempotent. ``` 4 What did you expect to see? Grammatically unambiguous documentation. 5 What did you see instead? In ""It is idempotent,"" ""it"" ambiguously refers to `ParseForm` or `ParseMultipartForm` or both. I think it should be `ParseForm`, but I'm not sure. Maybe both?",1,net http ambiguous sentence in docs for response parseform please answer these questions before submitting your issue thanks what version of go are you using go version what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users cjohnson documents code golang gorace goroot usr local cellar go libexec gotooldir usr local cellar go libexec pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fno common cxx clang cgo enabled what did you do shell go doc http parseform func r request parseform error parseform parses the raw query from the url and updates r form for post or put requests it also parses the request body as a form and put the results into both r postform and r form post and put body parameters take precedence over url query string values in r form if the request body s size has not already been limited by maxbytesreader the size is capped at parsemultipartform calls parseform automatically it is idempotent what did you expect to see grammatically unambiguous documentation what did you see instead in it is idempotent it ambiguously refers to parseform or parsemultipartform or both i think it should be parseform but i m not sure maybe both ,1 77383,9993917866.0,IssuesEvent,2019-07-11 16:21:52,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: handle 404-ing links in documentLink,Documentation gopls,"Related to discussion on https://github.com/microsoft/vscode-go/issues/2614. Would it be reasonable to test that a link is valid in `textDocument/documentLink`?",1.0,"x/tools/gopls: handle 404-ing links in documentLink - Related to discussion on https://github.com/microsoft/vscode-go/issues/2614. Would it be reasonable to test that a link is valid in `textDocument/documentLink`?",1,x tools gopls handle ing links in documentlink related to discussion on would it be reasonable to test that a link is valid in textdocument documentlink ,1 75882,7495377306.0,IssuesEvent,2018-04-07 20:08:16,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: TestLocalImportsEasy flake,OS-Windows Testing help wanted,"https://build.golang.org/log/cadb4ff3677483c2818a2ec0fa8a3d6a08f73f6a ``` --- FAIL: TestLocalImportsEasy (0.58s) go_test.go:1162: running testgo [build -o ./easy.exe testdata\local\easy.go] go_test.go:1163: remove ./easy.exe: Access is denied. FAIL FAIL cmd/go 165.352s ``` Looks like something like this happened before: https://github.com/golang/go/issues/11217 The fix there was to make sure that executable filenames are distinct. From a quick glance, it appears to me that `testLocalEasy` is called from two locations in cmd/go/go_test.go, and it appears superficially that both locations would end up using `easy.exe`. Similarly so for `testLocalEasySub`, `testLocalHard`, and maybe others. Maybe the same fix is called for here? cc @alexbrainman @ianlancetaylor ",1.0,"cmd/go: TestLocalImportsEasy flake - https://build.golang.org/log/cadb4ff3677483c2818a2ec0fa8a3d6a08f73f6a ``` --- FAIL: TestLocalImportsEasy (0.58s) go_test.go:1162: running testgo [build -o ./easy.exe testdata\local\easy.go] go_test.go:1163: remove ./easy.exe: Access is denied. FAIL FAIL cmd/go 165.352s ``` Looks like something like this happened before: https://github.com/golang/go/issues/11217 The fix there was to make sure that executable filenames are distinct. From a quick glance, it appears to me that `testLocalEasy` is called from two locations in cmd/go/go_test.go, and it appears superficially that both locations would end up using `easy.exe`. Similarly so for `testLocalEasySub`, `testLocalHard`, and maybe others. Maybe the same fix is called for here? cc @alexbrainman @ianlancetaylor ",0,cmd go testlocalimportseasy flake fail testlocalimportseasy go test go running testgo go test go remove easy exe access is denied fail fail cmd go looks like something like this happened before the fix there was to make sure that executable filenames are distinct from a quick glance it appears to me that testlocaleasy is called from two locations in cmd go go test go and it appears superficially that both locations would end up using easy exe similarly so for testlocaleasysub testlocalhard and maybe others maybe the same fix is called for here cc alexbrainman ianlancetaylor ,0 38930,6714864270.0,IssuesEvent,2017-10-13 18:39:20,golang/go,https://api.github.com/repos/golang/go,reopened,database/sql: unclear docs for Tx cause races in sql/driver implementations,Documentation NeedsFix,"### What version of Go are you using (`go version`)? `go version go1.8.3 darwin/amd64` ### What did you do? Unlike `Conn` or `Stmt` there's no guidance on `Tx` indicating how the stdlib uses implementations. This seems to cause bugs in driver implementations, as a `Tx` is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package. This came up as I was debugging [a panic inside of lib/pq](https://github.com/lib/pq/issues/614) and discovered it was a data race due to the authors not assuming that their `Tx` would have to deal with calls from multiple goroutines (the repro is [here](https://gist.github.com/blinsay/044f39176eeab7f3020d1b527df5bdd7). It slowly adjusts timeouts to try and make the Context time out as results are coming back). Out of curiosity, I looked at `go-sql-driver/mysql` and the lack of a race there seems like a happy accident - the Context expiring occasionally causes [an internal error to bubble up](https://github.com/go-sql-driver/mysql/blob/a825be04c652d01442384e9dcdf2cdc3f1eda67f/packets.go#L441-L443), since the authors appear to aggressively check their invariants. I'm not sure whether this is a documentation problem or if there's something database/sql could do to make life easier for driver implementors. ",1.0,"database/sql: unclear docs for Tx cause races in sql/driver implementations - ### What version of Go are you using (`go version`)? `go version go1.8.3 darwin/amd64` ### What did you do? Unlike `Conn` or `Stmt` there's no guidance on `Tx` indicating how the stdlib uses implementations. This seems to cause bugs in driver implementations, as a `Tx` is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package. This came up as I was debugging [a panic inside of lib/pq](https://github.com/lib/pq/issues/614) and discovered it was a data race due to the authors not assuming that their `Tx` would have to deal with calls from multiple goroutines (the repro is [here](https://gist.github.com/blinsay/044f39176eeab7f3020d1b527df5bdd7). It slowly adjusts timeouts to try and make the Context time out as results are coming back). Out of curiosity, I looked at `go-sql-driver/mysql` and the lack of a race there seems like a happy accident - the Context expiring occasionally causes [an internal error to bubble up](https://github.com/go-sql-driver/mysql/blob/a825be04c652d01442384e9dcdf2cdc3f1eda67f/packets.go#L441-L443), since the authors appear to aggressively check their invariants. I'm not sure whether this is a documentation problem or if there's something database/sql could do to make life easier for driver implementors. ",1,database sql unclear docs for tx cause races in sql driver implementations what version of go are you using go version go version darwin what did you do unlike conn or stmt there s no guidance on tx indicating how the stdlib uses implementations this seems to cause bugs in driver implementations as a tx is expected to handle concurrent calls from multiple goroutines unlike most of the other interfaces in the package this came up as i was debugging and discovered it was a data race due to the authors not assuming that their tx would have to deal with calls from multiple goroutines the repro is it slowly adjusts timeouts to try and make the context time out as results are coming back out of curiosity i looked at go sql driver mysql and the lack of a race there seems like a happy accident the context expiring occasionally causes since the authors appear to aggressively check their invariants i m not sure whether this is a documentation problem or if there s something database sql could do to make life easier for driver implementors ,1 5156,2909691363.0,IssuesEvent,2015-06-21 00:25:37,golang/go,https://api.github.com/repos/golang/go,closed,misc/ios: document ideviceinfo,Documentation,detect.go shells out to a command named ideviceinfo. It's not clear how to install this binary and where it comes from. Document the installation steps or give a link to an equivalent doc.,1.0,misc/ios: document ideviceinfo - detect.go shells out to a command named ideviceinfo. It's not clear how to install this binary and where it comes from. Document the installation steps or give a link to an equivalent doc.,1,misc ios document ideviceinfo detect go shells out to a command named ideviceinfo it s not clear how to install this binary and where it comes from document the installation steps or give a link to an equivalent doc ,1 47788,12122394376.0,IssuesEvent,2020-04-22 10:53:48,golang/go,https://api.github.com/repos/golang/go,closed,cmd/api: tests timing out on plan9-arm builder,Builders NeedsInvestigation OS-Plan9 Testing,"[CL 224619](https://go-review.googlesource.com/c/go/+/224619) slowed the cmd/api tests on plan9_arm from best-case about 1 minute to best-case about 3 minutes, and worst-case timing out after 13 minutes, for example [here](https://build.golang.org/log/f4704e4e0bc49d1d31c722b21e994e3b614eb947 ). The CL added code to the cmd/api test to ""warm up the import cache"" by starting 31 `go list -deps -json std` commands in parallel. Each of these 31 commands walks the source and package trees doing a 'stat' (twice) on each of 2562 files, and opens and reads every source file at least twice (once partially, once fully). This is quite hard work on a diskless Raspberry Pi 3 with 1GB of RAM. In the instances where the test times out, it appears the OS has started swapping (to the same file server which holds the source tree -- swapping to SDcard is not really practical). The `dist test` command doesn't run cmd/api itself on Plan 9 platforms, because it takes too long. Can I suggest skipping the cmd/api test on plan9_arm for the same reason? Alternatively, perhaps a radical idea: instead of forking off separate `go list` commands, burdening the OS with 31 independent garbage-collected address spaces, and producing json text to be re-read and parsed, would it be feasible to do the tree walks internally as goroutines?",1.0,"cmd/api: tests timing out on plan9-arm builder - [CL 224619](https://go-review.googlesource.com/c/go/+/224619) slowed the cmd/api tests on plan9_arm from best-case about 1 minute to best-case about 3 minutes, and worst-case timing out after 13 minutes, for example [here](https://build.golang.org/log/f4704e4e0bc49d1d31c722b21e994e3b614eb947 ). The CL added code to the cmd/api test to ""warm up the import cache"" by starting 31 `go list -deps -json std` commands in parallel. Each of these 31 commands walks the source and package trees doing a 'stat' (twice) on each of 2562 files, and opens and reads every source file at least twice (once partially, once fully). This is quite hard work on a diskless Raspberry Pi 3 with 1GB of RAM. In the instances where the test times out, it appears the OS has started swapping (to the same file server which holds the source tree -- swapping to SDcard is not really practical). The `dist test` command doesn't run cmd/api itself on Plan 9 platforms, because it takes too long. Can I suggest skipping the cmd/api test on plan9_arm for the same reason? Alternatively, perhaps a radical idea: instead of forking off separate `go list` commands, burdening the OS with 31 independent garbage-collected address spaces, and producing json text to be re-read and parsed, would it be feasible to do the tree walks internally as goroutines?",0,cmd api tests timing out on arm builder slowed the cmd api tests on arm from best case about minute to best case about minutes and worst case timing out after minutes for example the cl added code to the cmd api test to warm up the import cache by starting go list deps json std commands in parallel each of these commands walks the source and package trees doing a stat twice on each of files and opens and reads every source file at least twice once partially once fully this is quite hard work on a diskless raspberry pi with of ram in the instances where the test times out it appears the os has started swapping to the same file server which holds the source tree swapping to sdcard is not really practical the dist test command doesn t run cmd api itself on plan platforms because it takes too long can i suggest skipping the cmd api test on arm for the same reason alternatively perhaps a radical idea instead of forking off separate go list commands burdening the os with independent garbage collected address spaces and producing json text to be re read and parsed would it be feasible to do the tree walks internally as goroutines ,0 3801,4052397921.0,IssuesEvent,2016-05-24 02:17:22,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: pointless strength reduction,Performance,"``` var t [256]byte func f(b *[16]byte) { for i, v := range b { b[i] = t[v] } } ``` compiles to: ``` 0x000f 00015 (tmp1.go:7) MOVBLZX (AX), DX 0x0012 00018 (tmp1.go:7) LEAQ """".t(SB), BX 0x0019 00025 (tmp1.go:7) MOVBLZX (BX)(DX*1), DX 0x001d 00029 (tmp1.go:7) MOVQ """".b+8(FP), BX 0x0022 00034 (tmp1.go:7) MOVB DL, (BX)(CX*1) 0x0025 00037 (tmp1.go:6) INCQ AX 0x0028 00040 (tmp1.go:6) INCQ CX 0x002b 00043 (tmp1.go:6) CMPQ CX, $16 0x002f 00047 (tmp1.go:6) JLT $0, 15 ``` It looks like we strength-reduced the index into `b` into a pointer increment. But the terminating condition still uses the integer, so we end up having 2 induction variables instead of one. We should either compute the terminating condition using an end pointer (and throw away the induction variable CX), or throw away the pointer induction variable (AX) and use an indexed load. @brtzsnr ",True,"cmd/compile: pointless strength reduction - ``` var t [256]byte func f(b *[16]byte) { for i, v := range b { b[i] = t[v] } } ``` compiles to: ``` 0x000f 00015 (tmp1.go:7) MOVBLZX (AX), DX 0x0012 00018 (tmp1.go:7) LEAQ """".t(SB), BX 0x0019 00025 (tmp1.go:7) MOVBLZX (BX)(DX*1), DX 0x001d 00029 (tmp1.go:7) MOVQ """".b+8(FP), BX 0x0022 00034 (tmp1.go:7) MOVB DL, (BX)(CX*1) 0x0025 00037 (tmp1.go:6) INCQ AX 0x0028 00040 (tmp1.go:6) INCQ CX 0x002b 00043 (tmp1.go:6) CMPQ CX, $16 0x002f 00047 (tmp1.go:6) JLT $0, 15 ``` It looks like we strength-reduced the index into `b` into a pointer increment. But the terminating condition still uses the integer, so we end up having 2 induction variables instead of one. We should either compute the terminating condition using an end pointer (and throw away the induction variable CX), or throw away the pointer induction variable (AX) and use an indexed load. @brtzsnr ",0,cmd compile pointless strength reduction var t byte func f b byte for i v range b b t compiles to go movblzx ax dx go leaq t sb bx go movblzx bx dx dx go movq b fp bx go movb dl bx cx go incq ax go incq cx go cmpq cx go jlt it looks like we strength reduced the index into b into a pointer increment but the terminating condition still uses the integer so we end up having induction variables instead of one we should either compute the terminating condition using an end pointer and throw away the induction variable cx or throw away the pointer induction variable ax and use an indexed load brtzsnr ,0 23200,4893247064.0,IssuesEvent,2016-11-18 22:25:54,golang/go,https://api.github.com/repos/golang/go,opened,net: document net.Conn operation after deadline is exceeded,Documentation,"The current phrasing on `net.Conn.SetDeadline` is: > A deadline is an absolute time after which I/O operations fail with a timeout (see type Error) instead of blocking. The deadline applies to all future and pending I/O, not just the immediately following call to Read or Write. > > An idle timeout can be implemented by repeatedly extending the deadline after successful Read or Write calls. > > A zero value for t means I/O operations will not time out. I'm debugging some non-compliant implementations of `net.Conn` due to the clarification made in ([CL/30164](http://golang.org/cl/30164)). While fixing them, I noticed another discrepancy of some `net.Conn` implementations as compared to `net.TCPConn` and would like some clarification on expected behavior. The `net.TCPConn` implementation allows a deadline to be exceeded, which unblocks any pending IO operations. However, it also allows the user to extend the deadline to be in the future, essentially allowing IO operations to function again. In some of the implementations I'm fixing, once the deadline has been exceeded, the underlying connection is destroyed and it does not matter if the deadline is set to be in the future again; all IO operations henceforth are dead. Is ""refreshable"" deadlines an expected behavior of `net.Conn`? Does any logic in the standard library depend on it? /cc @bradfitz ",1.0,"net: document net.Conn operation after deadline is exceeded - The current phrasing on `net.Conn.SetDeadline` is: > A deadline is an absolute time after which I/O operations fail with a timeout (see type Error) instead of blocking. The deadline applies to all future and pending I/O, not just the immediately following call to Read or Write. > > An idle timeout can be implemented by repeatedly extending the deadline after successful Read or Write calls. > > A zero value for t means I/O operations will not time out. I'm debugging some non-compliant implementations of `net.Conn` due to the clarification made in ([CL/30164](http://golang.org/cl/30164)). While fixing them, I noticed another discrepancy of some `net.Conn` implementations as compared to `net.TCPConn` and would like some clarification on expected behavior. The `net.TCPConn` implementation allows a deadline to be exceeded, which unblocks any pending IO operations. However, it also allows the user to extend the deadline to be in the future, essentially allowing IO operations to function again. In some of the implementations I'm fixing, once the deadline has been exceeded, the underlying connection is destroyed and it does not matter if the deadline is set to be in the future again; all IO operations henceforth are dead. Is ""refreshable"" deadlines an expected behavior of `net.Conn`? Does any logic in the standard library depend on it? /cc @bradfitz ",1,net document net conn operation after deadline is exceeded the current phrasing on net conn setdeadline is a deadline is an absolute time after which i o operations fail with a timeout see type error instead of blocking the deadline applies to all future and pending i o not just the immediately following call to read or write an idle timeout can be implemented by repeatedly extending the deadline after successful read or write calls a zero value for t means i o operations will not time out i m debugging some non compliant implementations of net conn due to the clarification made in while fixing them i noticed another discrepancy of some net conn implementations as compared to net tcpconn and would like some clarification on expected behavior the net tcpconn implementation allows a deadline to be exceeded which unblocks any pending io operations however it also allows the user to extend the deadline to be in the future essentially allowing io operations to function again in some of the implementations i m fixing once the deadline has been exceeded the underlying connection is destroyed and it does not matter if the deadline is set to be in the future again all io operations henceforth are dead is refreshable deadlines an expected behavior of net conn does any logic in the standard library depend on it cc bradfitz ,1 298132,25791134303.0,IssuesEvent,2022-12-10 04:57:40,golang/go,https://api.github.com/repos/golang/go,closed,x/net/http2: data race in TestCanonicalHeaderCacheGrowth,Testing NeedsFix,"``` #!watchflakes post <- pkg == ""x/net/http2"" && test == ""TestCanonicalHeaderCacheGrowth"" && `DATA RACE` ``` https://build.golang.org/log/9f76836a9c3da1bd2d60e0e4b5274e6d253febaa: ``` ================== WARNING: DATA RACE Write at 0x000001a1e0cc by goroutine 67: golang.org/x/net/http2.disableGoroutineTracking() C:/workdir/gopath/src/golang.org/x/net/http2/server_test.go:3502 +0x64 golang.org/x/net/http2.TestCanonicalHeaderCacheGrowth() C:/workdir/gopath/src/golang.org/x/net/http2/server_test.go:4550 +0x9b testing.tRunner() C:/workdir/go/src/testing/testing.go:1439 +0x213 testing.(*T).Run.func1() C:/workdir/go/src/testing/testing.go:1486 +0x47 Previous read at 0x000001a1e0cc by goroutine 248: golang.org/x/net/http2.goroutineLock.checkNotOn() C:/workdir/gopath/src/golang.org/x/net/http2/gotrack.go:41 +0xaa golang.org/x/net/http2.(*serverConn).writeFrameFromHandler() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1134 +0x75 golang.org/x/net/http2.(*serverConn).writeHeaders() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2331 +0x116 golang.org/x/net/http2.(*responseWriterState).writeChunk() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2617 +0x10f2 golang.org/x/net/http2.chunkWriter.Write() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2520 +0xb5 golang.org/x/net/http2.(*responseWriter).FlushError() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2790 +0xbb golang.org/x/net/http2.(*responseWriter).Flush() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2774 +0x78 golang.org/x/net/http2.(*responseWriter).handlerDone() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2952 +0x6e golang.org/x/net/http2.(*serverConn).runHandler.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2303 +0x3de runtime.deferreturn() C:/workdir/go/src/runtime/panic.go:436 +0x32 golang.org/x/net/http2.(*serverConn).processHeaders.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2018 +0x64 Goroutine 67 (running) created at: testing.(*T).Run() C:/workdir/go/src/testing/testing.go:1486 +0x724 testing.runTests.func1() C:/workdir/go/src/testing/testing.go:1839 +0x99 testing.tRunner() C:/workdir/go/src/testing/testing.go:1439 +0x213 testing.runTests() C:/workdir/go/src/testing/testing.go:1837 +0x7e4 testing.(*M).Run() C:/workdir/go/src/testing/testing.go:1719 +0xa71 main.main() _testmain.go:767 +0x2e4 Goroutine 248 (finished) created at: golang.org/x/net/http2.(*serverConn).processHeaders() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2018 +0xd39 golang.org/x/net/http2.(*serverConn).processFrame() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1518 +0x635 golang.org/x/net/http2.(*serverConn).processFrameFromReader() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1461 +0x2ed golang.org/x/net/http2.(*serverConn).serve() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:952 +0x15ea golang.org/x/net/http2.(*Server).ServeConn() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:531 +0x1771 golang.org/x/net/http2.ConfigureServer.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:321 +0x124 net/http.(*conn).serve() C:/workdir/go/src/net/http/server.go:1874 +0x1c56 net/http.(*Server).Serve.func3() C:/workdir/go/src/net/http/server.go:3071 +0x58 ================== --- FAIL: TestCanonicalHeaderCacheGrowth (86.60s) testing.go:1312: race detected during execution of test FAIL FAIL golang.org/x/net/http2 111.467s ```",1.0,"x/net/http2: data race in TestCanonicalHeaderCacheGrowth - ``` #!watchflakes post <- pkg == ""x/net/http2"" && test == ""TestCanonicalHeaderCacheGrowth"" && `DATA RACE` ``` https://build.golang.org/log/9f76836a9c3da1bd2d60e0e4b5274e6d253febaa: ``` ================== WARNING: DATA RACE Write at 0x000001a1e0cc by goroutine 67: golang.org/x/net/http2.disableGoroutineTracking() C:/workdir/gopath/src/golang.org/x/net/http2/server_test.go:3502 +0x64 golang.org/x/net/http2.TestCanonicalHeaderCacheGrowth() C:/workdir/gopath/src/golang.org/x/net/http2/server_test.go:4550 +0x9b testing.tRunner() C:/workdir/go/src/testing/testing.go:1439 +0x213 testing.(*T).Run.func1() C:/workdir/go/src/testing/testing.go:1486 +0x47 Previous read at 0x000001a1e0cc by goroutine 248: golang.org/x/net/http2.goroutineLock.checkNotOn() C:/workdir/gopath/src/golang.org/x/net/http2/gotrack.go:41 +0xaa golang.org/x/net/http2.(*serverConn).writeFrameFromHandler() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1134 +0x75 golang.org/x/net/http2.(*serverConn).writeHeaders() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2331 +0x116 golang.org/x/net/http2.(*responseWriterState).writeChunk() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2617 +0x10f2 golang.org/x/net/http2.chunkWriter.Write() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2520 +0xb5 golang.org/x/net/http2.(*responseWriter).FlushError() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2790 +0xbb golang.org/x/net/http2.(*responseWriter).Flush() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2774 +0x78 golang.org/x/net/http2.(*responseWriter).handlerDone() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2952 +0x6e golang.org/x/net/http2.(*serverConn).runHandler.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2303 +0x3de runtime.deferreturn() C:/workdir/go/src/runtime/panic.go:436 +0x32 golang.org/x/net/http2.(*serverConn).processHeaders.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2018 +0x64 Goroutine 67 (running) created at: testing.(*T).Run() C:/workdir/go/src/testing/testing.go:1486 +0x724 testing.runTests.func1() C:/workdir/go/src/testing/testing.go:1839 +0x99 testing.tRunner() C:/workdir/go/src/testing/testing.go:1439 +0x213 testing.runTests() C:/workdir/go/src/testing/testing.go:1837 +0x7e4 testing.(*M).Run() C:/workdir/go/src/testing/testing.go:1719 +0xa71 main.main() _testmain.go:767 +0x2e4 Goroutine 248 (finished) created at: golang.org/x/net/http2.(*serverConn).processHeaders() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:2018 +0xd39 golang.org/x/net/http2.(*serverConn).processFrame() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1518 +0x635 golang.org/x/net/http2.(*serverConn).processFrameFromReader() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:1461 +0x2ed golang.org/x/net/http2.(*serverConn).serve() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:952 +0x15ea golang.org/x/net/http2.(*Server).ServeConn() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:531 +0x1771 golang.org/x/net/http2.ConfigureServer.func1() C:/workdir/gopath/src/golang.org/x/net/http2/server.go:321 +0x124 net/http.(*conn).serve() C:/workdir/go/src/net/http/server.go:1874 +0x1c56 net/http.(*Server).Serve.func3() C:/workdir/go/src/net/http/server.go:3071 +0x58 ================== --- FAIL: TestCanonicalHeaderCacheGrowth (86.60s) testing.go:1312: race detected during execution of test FAIL FAIL golang.org/x/net/http2 111.467s ```",0,x net data race in testcanonicalheadercachegrowth watchflakes post pkg x net test testcanonicalheadercachegrowth data race warning data race write at by goroutine golang org x net disablegoroutinetracking c workdir gopath src golang org x net server test go golang org x net testcanonicalheadercachegrowth c workdir gopath src golang org x net server test go testing trunner c workdir go src testing testing go testing t run c workdir go src testing testing go previous read at by goroutine golang org x net goroutinelock checknoton c workdir gopath src golang org x net gotrack go golang org x net serverconn writeframefromhandler c workdir gopath src golang org x net server go golang org x net serverconn writeheaders c workdir gopath src golang org x net server go golang org x net responsewriterstate writechunk c workdir gopath src golang org x net server go golang org x net chunkwriter write c workdir gopath src golang org x net server go golang org x net responsewriter flusherror c workdir gopath src golang org x net server go golang org x net responsewriter flush c workdir gopath src golang org x net server go golang org x net responsewriter handlerdone c workdir gopath src golang org x net server go golang org x net serverconn runhandler c workdir gopath src golang org x net server go runtime deferreturn c workdir go src runtime panic go golang org x net serverconn processheaders c workdir gopath src golang org x net server go goroutine running created at testing t run c workdir go src testing testing go testing runtests c workdir go src testing testing go testing trunner c workdir go src testing testing go testing runtests c workdir go src testing testing go testing m run c workdir go src testing testing go main main testmain go goroutine finished created at golang org x net serverconn processheaders c workdir gopath src golang org x net server go golang org x net serverconn processframe c workdir gopath src golang org x net server go golang org x net serverconn processframefromreader c workdir gopath src golang org x net server go golang org x net serverconn serve c workdir gopath src golang org x net server go golang org x net server serveconn c workdir gopath src golang org x net server go golang org x net configureserver c workdir gopath src golang org x net server go net http conn serve c workdir go src net http server go net http server serve c workdir go src net http server go fail testcanonicalheadercachegrowth testing go race detected during execution of test fail fail golang org x net ,0 85860,10466780926.0,IssuesEvent,2019-09-21 21:47:14,golang/go,https://api.github.com/repos/golang/go,closed,strings: EqualFold doc could be clearer,Documentation NeedsFix help wanted,"The doc for EqualFold says: > EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under Unicode case-folding. I have been using Go for over five years now and had no idea what ""Unicode case-folding"" was until about three minutes ago. Previously I had implemented this by calling `strings.ToLower` on each side, which is slow and unnecessary. More commonly I believe the EqualFold functionality is known as ""case insensitive matching."" Users who are searching the strings documentation for the phrase ""case insensitive"" will find nothing, when they should be finding this function. Scanning Github this seems like a common mistake: https://github.com/sachin-varade/network/blob/5d4ab4a3757603b8c0ba9a9df7bc9e0ff92ad102/app/utils/setup/chaincode/processors/read_ledger.go#L172 https://github.com/projectriri/bot-gateway/blob/d4402bd4ac0d4478bd86e585ca83e9d3fc1c140e/converters/cqhttp-ubm-conv/cqhttp-ubm-conv.go#L79 Several Go vetters/linters have checks for this construction that suggest using EqualFold instead: https://github.com/dominikh/go-tools/blob/1da3061645b400d55be4855f104d8a68ca0a61e5/staticcheck/testdata/src/CheckToLowerToUpperComparison/CheckToLowerToUpperComparison.go StackOverflow answers suggesting the use of EqualFold have 35,000 views and 10,000 views, respectively. https://stackoverflow.com/q/24836044/329700 https://stackoverflow.com/q/30196780/329700",1.0,"strings: EqualFold doc could be clearer - The doc for EqualFold says: > EqualFold reports whether s and t, interpreted as UTF-8 strings, are equal under Unicode case-folding. I have been using Go for over five years now and had no idea what ""Unicode case-folding"" was until about three minutes ago. Previously I had implemented this by calling `strings.ToLower` on each side, which is slow and unnecessary. More commonly I believe the EqualFold functionality is known as ""case insensitive matching."" Users who are searching the strings documentation for the phrase ""case insensitive"" will find nothing, when they should be finding this function. Scanning Github this seems like a common mistake: https://github.com/sachin-varade/network/blob/5d4ab4a3757603b8c0ba9a9df7bc9e0ff92ad102/app/utils/setup/chaincode/processors/read_ledger.go#L172 https://github.com/projectriri/bot-gateway/blob/d4402bd4ac0d4478bd86e585ca83e9d3fc1c140e/converters/cqhttp-ubm-conv/cqhttp-ubm-conv.go#L79 Several Go vetters/linters have checks for this construction that suggest using EqualFold instead: https://github.com/dominikh/go-tools/blob/1da3061645b400d55be4855f104d8a68ca0a61e5/staticcheck/testdata/src/CheckToLowerToUpperComparison/CheckToLowerToUpperComparison.go StackOverflow answers suggesting the use of EqualFold have 35,000 views and 10,000 views, respectively. https://stackoverflow.com/q/24836044/329700 https://stackoverflow.com/q/30196780/329700",1,strings equalfold doc could be clearer the doc for equalfold says equalfold reports whether s and t interpreted as utf strings are equal under unicode case folding i have been using go for over five years now and had no idea what unicode case folding was until about three minutes ago previously i had implemented this by calling strings tolower on each side which is slow and unnecessary more commonly i believe the equalfold functionality is known as case insensitive matching users who are searching the strings documentation for the phrase case insensitive will find nothing when they should be finding this function scanning github this seems like a common mistake several go vetters linters have checks for this construction that suggest using equalfold instead stackoverflow answers suggesting the use of equalfold have views and views respectively ,1 44357,23597209460.0,IssuesEvent,2022-08-23 20:30:12,golang/go,https://api.github.com/repos/golang/go,closed,strconv: optimize Parse for []byte arguments,Performance NeedsDecision,"In 2016, #2632 was closed with the [explanation that](https://github.com/golang/go/issues/2632#issuecomment-252725945): > I still think we might be able to do something to make these conversions free and avoid 2x API bloat everywhere. I'd rather hold out for that. People who are super-sensitive to these allocations today can easily copy+modify the current code and ship that in their programs. In summary, it's argued that 1) the compiler should address this, and 2) people can vendor and modify the `strconv` package. It's been 4 years since the issue was closed (and 9 years since the issue was first reported), and there there hasn't been a compiler optimization that permits calling the `Parse` functions with a `[]byte` without it creating garbage. That is: ```go var b []byte = ... v, err := strconv.ParseXXX(string(b), ...) ``` always (as of Go1.15) allocates and copies the input `[]byte`. Forking `strconv` is an unfavorable workaround because it means that the vendor fails to benefit from future optimizations to `strconv` (e.g., [cl/187957](https://golang.org/cl/187957) or [cl/260858](https://golang.org/cl/260858)) and fixes to the implementation (e.g., #29491) and may go against company guidelines that forbid forks. Personally, I haven't seen anyone fork `strconv`. Rather, in most cases I see users cast a `[]byte` to a `string` using `unsafe`. This is what we do in the protobuf module. However, some use-cases are constrained to avoid using `unsafe` (e.g., `encoding/json`) and so continue to suffer from performance losses. Given the passage of time and the lack of a natural solution to this, I think we should revisit this issue. It seems that we should either: 1) Modify the compiler to detect cases where a string variable does not escape and that it's use [involves no synchronization points](https://github.com/golang/go/issues/2632#issuecomment-144865645), so that it functionally performs an allocation-free cast of `[]byte` to `string` in the example snippet above. If such a compiler optimization existed, we would probably also need to modify `strconv` to avoid escaping the [string input through the error value](https://github.com/golang/go/blob/d21af00dd22d478d0026797c91961168ba83aff9/src/strconv/atof.go#L693) by copying the input string. Note that this will slow down cases where parsing fails. 2) Accept that a compiler optimization is not happening, in which case we add `ParseBoolBytes`, `ParseComplexBytes`, `ParseFloatBytes`, `ParseIntBytes`, and `ParseUintBytes`, which are identical to their counterparts without the `Bytes` suffix, but operate on a `[]byte` as the input instead of a `string`. (We can add `Bytes` equivalents for the `QuoteXXX` functions as well, but those seem to be rarely with a `[]byte`.) Obviously option 1 is preferred, but if its not going to happen, but perhaps it's time to do option 2. It's been almost a decade. \cc @mvdan @rogpeppe @mdlayher ",True,"strconv: optimize Parse for []byte arguments - In 2016, #2632 was closed with the [explanation that](https://github.com/golang/go/issues/2632#issuecomment-252725945): > I still think we might be able to do something to make these conversions free and avoid 2x API bloat everywhere. I'd rather hold out for that. People who are super-sensitive to these allocations today can easily copy+modify the current code and ship that in their programs. In summary, it's argued that 1) the compiler should address this, and 2) people can vendor and modify the `strconv` package. It's been 4 years since the issue was closed (and 9 years since the issue was first reported), and there there hasn't been a compiler optimization that permits calling the `Parse` functions with a `[]byte` without it creating garbage. That is: ```go var b []byte = ... v, err := strconv.ParseXXX(string(b), ...) ``` always (as of Go1.15) allocates and copies the input `[]byte`. Forking `strconv` is an unfavorable workaround because it means that the vendor fails to benefit from future optimizations to `strconv` (e.g., [cl/187957](https://golang.org/cl/187957) or [cl/260858](https://golang.org/cl/260858)) and fixes to the implementation (e.g., #29491) and may go against company guidelines that forbid forks. Personally, I haven't seen anyone fork `strconv`. Rather, in most cases I see users cast a `[]byte` to a `string` using `unsafe`. This is what we do in the protobuf module. However, some use-cases are constrained to avoid using `unsafe` (e.g., `encoding/json`) and so continue to suffer from performance losses. Given the passage of time and the lack of a natural solution to this, I think we should revisit this issue. It seems that we should either: 1) Modify the compiler to detect cases where a string variable does not escape and that it's use [involves no synchronization points](https://github.com/golang/go/issues/2632#issuecomment-144865645), so that it functionally performs an allocation-free cast of `[]byte` to `string` in the example snippet above. If such a compiler optimization existed, we would probably also need to modify `strconv` to avoid escaping the [string input through the error value](https://github.com/golang/go/blob/d21af00dd22d478d0026797c91961168ba83aff9/src/strconv/atof.go#L693) by copying the input string. Note that this will slow down cases where parsing fails. 2) Accept that a compiler optimization is not happening, in which case we add `ParseBoolBytes`, `ParseComplexBytes`, `ParseFloatBytes`, `ParseIntBytes`, and `ParseUintBytes`, which are identical to their counterparts without the `Bytes` suffix, but operate on a `[]byte` as the input instead of a `string`. (We can add `Bytes` equivalents for the `QuoteXXX` functions as well, but those seem to be rarely with a `[]byte`.) Obviously option 1 is preferred, but if its not going to happen, but perhaps it's time to do option 2. It's been almost a decade. \cc @mvdan @rogpeppe @mdlayher ",0,strconv optimize parse for byte arguments in was closed with the i still think we might be able to do something to make these conversions free and avoid api bloat everywhere i d rather hold out for that people who are super sensitive to these allocations today can easily copy modify the current code and ship that in their programs in summary it s argued that the compiler should address this and people can vendor and modify the strconv package it s been years since the issue was closed and years since the issue was first reported and there there hasn t been a compiler optimization that permits calling the parse functions with a byte without it creating garbage that is go var b byte v err strconv parsexxx string b always as of allocates and copies the input byte forking strconv is an unfavorable workaround because it means that the vendor fails to benefit from future optimizations to strconv e g or and fixes to the implementation e g and may go against company guidelines that forbid forks personally i haven t seen anyone fork strconv rather in most cases i see users cast a byte to a string using unsafe this is what we do in the protobuf module however some use cases are constrained to avoid using unsafe e g encoding json and so continue to suffer from performance losses given the passage of time and the lack of a natural solution to this i think we should revisit this issue it seems that we should either modify the compiler to detect cases where a string variable does not escape and that it s use so that it functionally performs an allocation free cast of byte to string in the example snippet above if such a compiler optimization existed we would probably also need to modify strconv to avoid escaping the by copying the input string note that this will slow down cases where parsing fails accept that a compiler optimization is not happening in which case we add parseboolbytes parsecomplexbytes parsefloatbytes parseintbytes and parseuintbytes which are identical to their counterparts without the bytes suffix but operate on a byte as the input instead of a string we can add bytes equivalents for the quotexxx functions as well but those seem to be rarely with a byte obviously option is preferred but if its not going to happen but perhaps it s time to do option it s been almost a decade cc mvdan rogpeppe mdlayher ,0 32004,6024024196.0,IssuesEvent,2017-06-08 02:54:59,golang/go,https://api.github.com/repos/golang/go,closed,doc: improve `go test --help` -timeout usage message,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version go1.8 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/glendc/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gy/ldypn6dn08b_8q7cn3mg0l440000gn/T/go-build629694106=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ``` $ go test --help 2> >(grep -A2 timeout) ``` ### What did you expect to see? ``` -timeout t If a package runs longer than t, panic. The default is 10 minutes (10m). ``` ### What did you see instead? ``` -timeout t If a test runs longer than t, panic. The default is 10 minutes (10m). ``` Right now it seems to indicate that if an individual test, such as `TestFoo`, runs longer than t, it panic. But this is not true, and in fact after some local testing, it seems to be that it applies the timeout value on a package level, rather than it being applied on a single test only. Especially the ""`a test`"" is very confusing imho. I'm not the greatest in writing clear documentation though, so there is probably a better way to put it, than what I propose.",1.0,"doc: improve `go test --help` -timeout usage message - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? `go version go1.8 darwin/amd64` ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/glendc/go"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gy/ldypn6dn08b_8q7cn3mg0l440000gn/T/go-build629694106=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ``` ### What did you do? ``` $ go test --help 2> >(grep -A2 timeout) ``` ### What did you expect to see? ``` -timeout t If a package runs longer than t, panic. The default is 10 minutes (10m). ``` ### What did you see instead? ``` -timeout t If a test runs longer than t, panic. The default is 10 minutes (10m). ``` Right now it seems to indicate that if an individual test, such as `TestFoo`, runs longer than t, it panic. But this is not true, and in fact after some local testing, it seems to be that it applies the timeout value on a package level, rather than it being applied on a single test only. Especially the ""`a test`"" is very confusing imho. I'm not the greatest in writing clear documentation though, so there is probably a better way to put it, than what I propose.",1,doc improve go test help timeout usage message please answer these questions before submitting your issue thanks what version of go are you using go version go version darwin what operating system and processor architecture are you using go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users glendc go gorace goroot usr local go gotooldir usr local go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders gy t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g what did you do go test help grep timeout what did you expect to see timeout t if a package runs longer than t panic the default is minutes what did you see instead timeout t if a test runs longer than t panic the default is minutes right now it seems to indicate that if an individual test such as testfoo runs longer than t it panic but this is not true and in fact after some local testing it seems to be that it applies the timeout value on a package level rather than it being applied on a single test only especially the a test is very confusing imho i m not the greatest in writing clear documentation though so there is probably a better way to put it than what i propose ,1 285602,24680271018.0,IssuesEvent,2022-10-18 20:38:41,golang/go,https://api.github.com/repos/golang/go,closed,net/http: test flake in TestTransportIgnores408/h1,Testing NeedsInvestigation,"Seen on a trybot. Did not find an existing issue. CC @neild @bradfitz https://storage.googleapis.com/go-build-log/4868bfba/linux-amd64_7494de7d.log ``` --- FAIL: TestTransportIgnores408 (0.00s) --- FAIL: TestTransportIgnores408/h1 (0.01s) transport_test.go:6017: expected no log output; got: 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:51852: EOF 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:35068: EOF 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46010: read tcp 127.0.0.1:45467->127.0.0.1:46010: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:45980: read tcp 127.0.0.1:45467->127.0.0.1:45980: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46022: write tcp 127.0.0.1:45467->127.0.0.1:46022: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:45996: read tcp 127.0.0.1:45467->127.0.0.1:45996: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46036: write tcp 127.0.0.1:45467->127.0.0.1:46036: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46046: write tcp 127.0.0.1:45467->127.0.0.1:46046: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54726: read tcp 127.0.0.1:44951->127.0.0.1:54726: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54764: write tcp 127.0.0.1:44951->127.0.0.1:54764: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54716: write tcp 127.0.0.1:44951->127.0.0.1:54716: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54780: write tcp 127.0.0.1:44951->127.0.0.1:54780: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54740: write tcp 127.0.0.1:44951->127.0.0.1:54740: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54790: write tcp 127.0.0.1:44951->127.0.0.1:54790: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54752: write tcp 127.0.0.1:44951->127.0.0.1:54752: use of closed network connection 2022/10/09 03:30:01 http2: server: error reading preface from client 127.0.0.1:60128: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/09 03:30:01 http2: server: error reading preface from client 127.0.0.1:37392: bogus greeting ""CONNECT golang.fake.tld:"" FAIL FAIL net/http 2.757s FAIL ```",1.0,"net/http: test flake in TestTransportIgnores408/h1 - Seen on a trybot. Did not find an existing issue. CC @neild @bradfitz https://storage.googleapis.com/go-build-log/4868bfba/linux-amd64_7494de7d.log ``` --- FAIL: TestTransportIgnores408 (0.00s) --- FAIL: TestTransportIgnores408/h1 (0.01s) transport_test.go:6017: expected no log output; got: 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:51852: EOF 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:35068: EOF 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46010: read tcp 127.0.0.1:45467->127.0.0.1:46010: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:45980: read tcp 127.0.0.1:45467->127.0.0.1:45980: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46022: write tcp 127.0.0.1:45467->127.0.0.1:46022: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:45996: read tcp 127.0.0.1:45467->127.0.0.1:45996: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46036: write tcp 127.0.0.1:45467->127.0.0.1:46036: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:46046: write tcp 127.0.0.1:45467->127.0.0.1:46046: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54726: read tcp 127.0.0.1:44951->127.0.0.1:54726: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54764: write tcp 127.0.0.1:44951->127.0.0.1:54764: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54716: write tcp 127.0.0.1:44951->127.0.0.1:54716: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54780: write tcp 127.0.0.1:44951->127.0.0.1:54780: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54740: write tcp 127.0.0.1:44951->127.0.0.1:54740: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54790: write tcp 127.0.0.1:44951->127.0.0.1:54790: use of closed network connection 2022/10/09 03:30:01 http: TLS handshake error from 127.0.0.1:54752: write tcp 127.0.0.1:44951->127.0.0.1:54752: use of closed network connection 2022/10/09 03:30:01 http2: server: error reading preface from client 127.0.0.1:60128: bogus greeting ""CONNECT golang.fake.tld:"" 2022/10/09 03:30:01 http2: server: error reading preface from client 127.0.0.1:37392: bogus greeting ""CONNECT golang.fake.tld:"" FAIL FAIL net/http 2.757s FAIL ```",0,net http test flake in seen on a trybot did not find an existing issue cc neild bradfitz fail fail transport test go expected no log output got http tls handshake error from eof http tls handshake error from eof http tls handshake error from read tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from read tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection http tls handshake error from write tcp use of closed network connection server error reading preface from client bogus greeting connect golang fake tld server error reading preface from client bogus greeting connect golang fake tld fail fail net http fail ,0 173146,14403565531.0,IssuesEvent,2020-12-03 16:12:42,golang/go,https://api.github.com/repos/golang/go,closed,"doc/go1.16: document new packages in Go 1.16 standard library (io/fs, embed, runtime/metrics, testing/fstest)",Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML: ```HTML

Core library

TODO: mention significant additions like new packages (io/fs), new proposal-scoped features (//go:embed), and so on

``` Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1.0,"doc/go1.16: document new packages in Go 1.16 standard library (io/fs, embed, runtime/metrics, testing/fstest) - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML: ```HTML

Core library

TODO: mention significant additions like new packages (io/fs), new proposal-scoped features (//go:embed), and so on

``` Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body.",1,doc document new packages in go standard library io fs embed runtime metrics testing fstest as of filing this issue the contained the following html html core library todo mention significant additions like new packages io fs new proposal scoped features go embed and so on per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 71319,9489547682.0,IssuesEvent,2019-04-22 23:01:25,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that Request.SetBasicAuth doesn't do any additional escaping,Documentation NeedsFix,"### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you do? Call [`req.SetBasicAuth(user, pass)`](https://golang.org/pkg/net/http/#Request.SetBasicAuth) with special characters in either the username or the password, e.g.: ```go req, err := http.NewRequest(""POST"", ""http://127.0.0.1/foo"", nil) req.SetBasicAuth(""foo"", ""bar+baz"") if err != nil { panic(err) } fmt.Println(req.Header.Get(""Authorization"")) ``` ### What did you expect to see? The above program should probably print `Basic Zm9vOmJhciUyQmJheg==` ### What did you see instead? The above program prints `Basic Zm9vOmJhcitiYXo=` ### Discussion So I spent a long long _long_ time debugging some OpenID Connect authentication issue with `kubectl` and [dex](https://github.com/dexidp/dex). Long story short, it turns out that the random client secret I had generated contained a `+` sign and it needed to be URL encoded before being base64-encoded when used with basic auth. After looking at the code in Kubernetes and various other projects, I realized that nobody ever escapes the arguments passed to `SetBasicAuth()`. So this issue is extremely widespread. In fact the bug was even present in Go's own OAuth2 implementation until golang/oauth2#237 fixed it. The godoc doesn't say anything about escaping so it's not clear to me whether the intent was to have users do it themselves (and, clearly, they don't) or, more likely, this was just an unfortunate omission (i.e. a bug) when the library was implemented. Given how widespread this issue is, I think the standard library should do the URL encoding automagically. Now since there are some callers that already do it (e.g. the OAuth2 library after the fix mentioned above), this means that the code should probably make a pass through the strings it's given and if they contain anything that needs escaping, then escape the whole string, otherwise use the string as-is. If you guys disagree that the library should take care of escaping the arguments, then at the very least the godoc should be updated to explicitly state that the strings must be URL-safe or URL encoded. But I strongly think that the library should just make it work automatically given that virtually none of the existing code out there does this properly. Granted this problem is probably not that likely to occur in practice, again I hit it because I used a random string of ASCII characters as a client secret, and there was a `+` in there. So `kubectl` worked for a while but once it needed to refresh its token, I'd get a mysterious 401 due to this bug.",1.0,"net/http: document that Request.SetBasicAuth doesn't do any additional escaping - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.12.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes. ### What did you do? Call [`req.SetBasicAuth(user, pass)`](https://golang.org/pkg/net/http/#Request.SetBasicAuth) with special characters in either the username or the password, e.g.: ```go req, err := http.NewRequest(""POST"", ""http://127.0.0.1/foo"", nil) req.SetBasicAuth(""foo"", ""bar+baz"") if err != nil { panic(err) } fmt.Println(req.Header.Get(""Authorization"")) ``` ### What did you expect to see? The above program should probably print `Basic Zm9vOmJhciUyQmJheg==` ### What did you see instead? The above program prints `Basic Zm9vOmJhcitiYXo=` ### Discussion So I spent a long long _long_ time debugging some OpenID Connect authentication issue with `kubectl` and [dex](https://github.com/dexidp/dex). Long story short, it turns out that the random client secret I had generated contained a `+` sign and it needed to be URL encoded before being base64-encoded when used with basic auth. After looking at the code in Kubernetes and various other projects, I realized that nobody ever escapes the arguments passed to `SetBasicAuth()`. So this issue is extremely widespread. In fact the bug was even present in Go's own OAuth2 implementation until golang/oauth2#237 fixed it. The godoc doesn't say anything about escaping so it's not clear to me whether the intent was to have users do it themselves (and, clearly, they don't) or, more likely, this was just an unfortunate omission (i.e. a bug) when the library was implemented. Given how widespread this issue is, I think the standard library should do the URL encoding automagically. Now since there are some callers that already do it (e.g. the OAuth2 library after the fix mentioned above), this means that the code should probably make a pass through the strings it's given and if they contain anything that needs escaping, then escape the whole string, otherwise use the string as-is. If you guys disagree that the library should take care of escaping the arguments, then at the very least the godoc should be updated to explicitly state that the strings must be URL-safe or URL encoded. But I strongly think that the library should just make it work automatically given that virtually none of the existing code out there does this properly. Granted this problem is probably not that likely to occur in practice, again I hit it because I used a random string of ASCII characters as a client secret, and there was a `+` in there. So `kubectl` worked for a while but once it needed to refresh its token, I'd get a mysterious 401 due to this bug.",1,net http document that request setbasicauth doesn t do any additional escaping what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what did you do call with special characters in either the username or the password e g go req err http newrequest post nil req setbasicauth foo bar baz if err nil panic err fmt println req header get authorization what did you expect to see the above program should probably print basic what did you see instead the above program prints basic discussion so i spent a long long long time debugging some openid connect authentication issue with kubectl and long story short it turns out that the random client secret i had generated contained a sign and it needed to be url encoded before being encoded when used with basic auth after looking at the code in kubernetes and various other projects i realized that nobody ever escapes the arguments passed to setbasicauth so this issue is extremely widespread in fact the bug was even present in go s own implementation until golang fixed it the godoc doesn t say anything about escaping so it s not clear to me whether the intent was to have users do it themselves and clearly they don t or more likely this was just an unfortunate omission i e a bug when the library was implemented given how widespread this issue is i think the standard library should do the url encoding automagically now since there are some callers that already do it e g the library after the fix mentioned above this means that the code should probably make a pass through the strings it s given and if they contain anything that needs escaping then escape the whole string otherwise use the string as is if you guys disagree that the library should take care of escaping the arguments then at the very least the godoc should be updated to explicitly state that the strings must be url safe or url encoded but i strongly think that the library should just make it work automatically given that virtually none of the existing code out there does this properly granted this problem is probably not that likely to occur in practice again i hit it because i used a random string of ascii characters as a client secret and there was a in there so kubectl worked for a while but once it needed to refresh its token i d get a mysterious due to this bug ,1 52335,7759136373.0,IssuesEvent,2018-05-31 22:02:16,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that Server.Serve expects a hashable net.Listener (as a map key),Documentation,"### What version of Go are you using (`go version`)? 1.10 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/vagrant/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/vagrant/workspace-dss"" GORACE="""" GOROOT=""/usr/local/go-1.10"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go-1.10/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build230598238=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? I implemented `net.Listener` with a struct that defined a `func()` field. I passed this struct to `http.Server.Serve`. The code compiled just fine and panicked at run-time because my listener implementation couldn't be used as a hash key (see `trackListener` in the `http` package). ### What did you expect to see? A working `http.Server`. Or else some documentation that clearly states the constraints for the kinds of listeners usable with `http.Server`. ### What did you see instead? Panic at run-time.",1.0,"net/http: document that Server.Serve expects a hashable net.Listener (as a map key) - ### What version of Go are you using (`go version`)? 1.10 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ``` GOARCH=""amd64"" GOBIN="""" GOCACHE=""/home/vagrant/.cache/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/vagrant/workspace-dss"" GORACE="""" GOROOT=""/usr/local/go-1.10"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/go-1.10/pkg/tool/linux_amd64"" GCCGO=""gccgo"" CC=""gcc"" CXX=""g++"" CGO_ENABLED=""1"" 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-build230598238=/tmp/go-build -gno-record-gcc-switches"" ``` ### What did you do? I implemented `net.Listener` with a struct that defined a `func()` field. I passed this struct to `http.Server.Serve`. The code compiled just fine and panicked at run-time because my listener implementation couldn't be used as a hash key (see `trackListener` in the `http` package). ### What did you expect to see? A working `http.Server`. Or else some documentation that clearly states the constraints for the kinds of listeners usable with `http.Server`. ### What did you see instead? Panic at run-time.",1,net http document that server serve expects a hashable net listener as a map key what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache home vagrant cache go build goexe gohostarch gohostos linux goos linux gopath home vagrant workspace dss gorace goroot usr local go gotmpdir gotooldir usr local go pkg tool linux gccgo gccgo cc gcc cxx g cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do i implemented net listener with a struct that defined a func field i passed this struct to http server serve the code compiled just fine and panicked at run time because my listener implementation couldn t be used as a hash key see tracklistener in the http package what did you expect to see a working http server or else some documentation that clearly states the constraints for the kinds of listeners usable with http server what did you see instead panic at run time ,1 174819,14500008787.0,IssuesEvent,2020-12-11 17:27:14,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document go command changes for Go 1.16,Documentation GoCommand NeedsInvestigation okay-after-beta1 release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML: ```HTML

Go command

TODO

``` And these TODOs: ``` TODO: write and link to section in golang.org/ref/mod TODO: write and link to blog post [...] TODO: write and link to section in golang.org/ref/mod TODO: write and link to tutorial or blog post ``` Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body. ",1.0,"doc/go1.16: document go command changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML: ```HTML

Go command

TODO

``` And these TODOs: ``` TODO: write and link to section in golang.org/ref/mod TODO: write and link to blog post [...] TODO: write and link to section in golang.org/ref/mod TODO: write and link to tutorial or blog post ``` Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body. ",1,doc document go command changes for go as of filing this issue the contained the following html html go command todo and these todos todo write and link to section in golang org ref mod todo write and link to blog post todo write and link to section in golang org ref mod todo write and link to tutorial or blog post per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 30445,5796681474.0,IssuesEvent,2017-05-02 20:03:51,golang/go,https://api.github.com/repos/golang/go,closed,doc: CLA instructions are out of date,Documentation NeedsFix,"https://golang.org/doc/contribute.html#cla suggests to navigate to Settings -> Agreements in gerrit. There is no menu entry called ""Agreements"" for me on https://go-review.googlesource.com/settings.",1.0,"doc: CLA instructions are out of date - https://golang.org/doc/contribute.html#cla suggests to navigate to Settings -> Agreements in gerrit. There is no menu entry called ""Agreements"" for me on https://go-review.googlesource.com/settings.",1,doc cla instructions are out of date suggests to navigate to settings agreements in gerrit there is no menu entry called agreements for me on ,1 37953,18853090401.0,IssuesEvent,2021-11-12 00:17:24,golang/go,https://api.github.com/repos/golang/go,closed,net: allow not creating a goroutine for netFD.connect in case of caller passes context which is not going to be cancelled manually,Performance NeedsInvestigation,"### What version of Go are you using (`go version`)? go1.17.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? `GO111MODULE="""" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/mikefaraponov/Library/Caches/go-build"" GOENV=""/Users/mikefaraponov/Library/Application Support/go/env"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOINSECURE="""" GOMODCACHE=""/Users/mikefaraponov/go/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""darwin"" GOPATH=""/Users/mikefaraponov/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/usr/local/Cellar/go/1.15.6/libexec"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/1.15.6/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" AR=""ar"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD=""/Users/mikefaraponov/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/97/d1hwd7t96mj0_jxmpngf2m5w0000gn/T/go-build319243062=/tmp/go-build -gno-record-gcc-switches -fno-common""` ### What did you do? Creating TCPConn connection via net.Dialer ### What did you expect to see? No netFD func2 goroutines to be spawned. ### What did you see instead? Each new connection created create netFD interruptor goroutine ### Solution net/fd_unix.go ```go if deadline, hasDeadline := ctx.Deadline(); hasDeadline { fd.pfd.SetWriteDeadline(deadline) defer fd.pfd.SetWriteDeadline(noDeadline) } // Start the ""interrupter"" goroutine, if this context might be canceled. // (The background context cannot) // // The interrupter goroutine waits for the context to be done and // interrupts the dial (by altering the fd's write deadline, which // wakes up waitWrite). if ctxDone := ctx.Done(); ctxDone != nil { // skip creation of goroutine and allow fd.pfd.SetWriteDeadline(deadline) to gracefully close this connection on timeout, this allows to pass custom context.Context implementation with deadline but not cancelable or just check some ctx.Value(""bypasscreationofgoroutine"") instead of ctx.Done() != nil check may be prefereble // Wait for the interrupter goroutine to exit before returning // from connect. done := make(chan struct{}) interruptRes := make(chan error) defer func() { close(done) if ctxErr := <-interruptRes; ctxErr != nil && ret == nil { // The interrupter goroutine called SetWriteDeadline, // but the connect code below had returned from // waitWrite already and did a successful connect (ret // == nil). Because we've now poisoned the connection // by making it unwritable, don't return a successful // dial. This was issue 16523. ret = mapErr(ctxErr) fd.Close() // prevent a leak } }() go func() { select { case <-ctxDone: // Force the runtime's poller to immediately give up // waiting for writability, unblocking waitWrite // below. fd.pfd.SetWriteDeadline(aLongTimeAgo) testHookCanceledDial() interruptRes <- ctx.Err() case <-done: interruptRes <- nil } }() } ``` And then smth like this can be used to bypass context cancel mechanism and do not utilise interruptor goroutine: ```go type deadlineCtx struct { deadline time.Time } func (m *deadlineCtx) Deadline() (deadline time.Time, ok bool) { return m.deadline, true } func (m *deadlineCtx) Done() <-chan struct{} { return nil } func (m *deadlineCtx) Err() error { return nil } func (m *deadlineCtx) Value(interface{}) interface{} { return nil } ``` ",True,"net: allow not creating a goroutine for netFD.connect in case of caller passes context which is not going to be cancelled manually - ### What version of Go are you using (`go version`)? go1.17.2 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? `GO111MODULE="""" GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/mikefaraponov/Library/Caches/go-build"" GOENV=""/Users/mikefaraponov/Library/Application Support/go/env"" GOEXE="""" GOFLAGS="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOINSECURE="""" GOMODCACHE=""/Users/mikefaraponov/go/pkg/mod"" GONOPROXY="""" GONOSUMDB="""" GOOS=""darwin"" GOPATH=""/Users/mikefaraponov/go"" GOPRIVATE="""" GOPROXY=""https://proxy.golang.org,direct"" GOROOT=""/usr/local/Cellar/go/1.15.6/libexec"" GOSUMDB=""sum.golang.org"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/1.15.6/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" AR=""ar"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" GOMOD=""/Users/mikefaraponov/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/97/d1hwd7t96mj0_jxmpngf2m5w0000gn/T/go-build319243062=/tmp/go-build -gno-record-gcc-switches -fno-common""` ### What did you do? Creating TCPConn connection via net.Dialer ### What did you expect to see? No netFD func2 goroutines to be spawned. ### What did you see instead? Each new connection created create netFD interruptor goroutine ### Solution net/fd_unix.go ```go if deadline, hasDeadline := ctx.Deadline(); hasDeadline { fd.pfd.SetWriteDeadline(deadline) defer fd.pfd.SetWriteDeadline(noDeadline) } // Start the ""interrupter"" goroutine, if this context might be canceled. // (The background context cannot) // // The interrupter goroutine waits for the context to be done and // interrupts the dial (by altering the fd's write deadline, which // wakes up waitWrite). if ctxDone := ctx.Done(); ctxDone != nil { // skip creation of goroutine and allow fd.pfd.SetWriteDeadline(deadline) to gracefully close this connection on timeout, this allows to pass custom context.Context implementation with deadline but not cancelable or just check some ctx.Value(""bypasscreationofgoroutine"") instead of ctx.Done() != nil check may be prefereble // Wait for the interrupter goroutine to exit before returning // from connect. done := make(chan struct{}) interruptRes := make(chan error) defer func() { close(done) if ctxErr := <-interruptRes; ctxErr != nil && ret == nil { // The interrupter goroutine called SetWriteDeadline, // but the connect code below had returned from // waitWrite already and did a successful connect (ret // == nil). Because we've now poisoned the connection // by making it unwritable, don't return a successful // dial. This was issue 16523. ret = mapErr(ctxErr) fd.Close() // prevent a leak } }() go func() { select { case <-ctxDone: // Force the runtime's poller to immediately give up // waiting for writability, unblocking waitWrite // below. fd.pfd.SetWriteDeadline(aLongTimeAgo) testHookCanceledDial() interruptRes <- ctx.Err() case <-done: interruptRes <- nil } }() } ``` And then smth like this can be used to bypass context cancel mechanism and do not utilise interruptor goroutine: ```go type deadlineCtx struct { deadline time.Time } func (m *deadlineCtx) Deadline() (deadline time.Time, ok bool) { return m.deadline, true } func (m *deadlineCtx) Done() <-chan struct{} { return nil } func (m *deadlineCtx) Err() error { return nil } func (m *deadlineCtx) Value(interface{}) interface{} { return nil } ``` ",0,net allow not creating a goroutine for netfd connect in case of caller passes context which is not going to be cancelled manually what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env goarch gobin gocache users mikefaraponov library caches go build goenv users mikefaraponov library application support go env goexe goflags gohostarch gohostos darwin goinsecure gomodcache users mikefaraponov go pkg mod gonoproxy gonosumdb goos darwin gopath users mikefaraponov go goprivate goproxy goroot usr local cellar go libexec gosumdb sum golang org gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod users mikefaraponov go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common what did you do creating tcpconn connection via net dialer what did you expect to see no netfd goroutines to be spawned what did you see instead each new connection created create netfd interruptor goroutine solution net fd unix go go if deadline hasdeadline ctx deadline hasdeadline fd pfd setwritedeadline deadline defer fd pfd setwritedeadline nodeadline start the interrupter goroutine if this context might be canceled the background context cannot the interrupter goroutine waits for the context to be done and interrupts the dial by altering the fd s write deadline which wakes up waitwrite if ctxdone ctx done ctxdone nil skip creation of goroutine and allow fd pfd setwritedeadline deadline to gracefully close this connection on timeout this allows to pass custom context context implementation with deadline but not cancelable or just check some ctx value bypasscreationofgoroutine instead of ctx done nil check may be prefereble wait for the interrupter goroutine to exit before returning from connect done make chan struct interruptres make chan error defer func close done if ctxerr interruptres ctxerr nil ret nil the interrupter goroutine called setwritedeadline but the connect code below had returned from waitwrite already and did a successful connect ret nil because we ve now poisoned the connection by making it unwritable don t return a successful dial this was issue ret maperr ctxerr fd close prevent a leak go func select case ctxdone force the runtime s poller to immediately give up waiting for writability unblocking waitwrite below fd pfd setwritedeadline alongtimeago testhookcanceleddial interruptres ctx err case done interruptres nil and then smth like this can be used to bypass context cancel mechanism and do not utilise interruptor goroutine go type deadlinectx struct deadline time time func m deadlinectx deadline deadline time time ok bool return m deadline true func m deadlinectx done chan struct return nil func m deadlinectx err error return nil func m deadlinectx value interface interface return nil ,0 150924,13385591088.0,IssuesEvent,2020-09-02 13:40:14,golang/go,https://api.github.com/repos/golang/go,closed,doc: include fix for #34437 in Go 1.14 release notes [1.14 backport],CherryPickApproved Documentation,"@dmitshur requested issue #38801 to be considered for backport to the next 1.14 minor release. > @gopherbot Please open an issue to backport this to Go 1.14 when the fix is available. This is a documentation fix. ",1.0,"doc: include fix for #34437 in Go 1.14 release notes [1.14 backport] - @dmitshur requested issue #38801 to be considered for backport to the next 1.14 minor release. > @gopherbot Please open an issue to backport this to Go 1.14 when the fix is available. This is a documentation fix. ",1,doc include fix for in go release notes dmitshur requested issue to be considered for backport to the next minor release gopherbot please open an issue to backport this to go when the fix is available this is a documentation fix ,1 253689,19161549963.0,IssuesEvent,2021-12-03 01:10:04,golang/go,https://api.github.com/repos/golang/go,closed,builtin: add documentation for `any` and `comparable` to pseudo-package `builtin`,Documentation release-blocker okay-after-beta1,The new predeclared identifiers `any` and `comparable` in Go 1.18 should have documentation entries in the `builtin` pseudo-package: https://pkg.go.dev/builtin@master,1.0,builtin: add documentation for `any` and `comparable` to pseudo-package `builtin` - The new predeclared identifiers `any` and `comparable` in Go 1.18 should have documentation entries in the `builtin` pseudo-package: https://pkg.go.dev/builtin@master,1,builtin add documentation for any and comparable to pseudo package builtin the new predeclared identifiers any and comparable in go should have documentation entries in the builtin pseudo package ,1 188130,15128894959.0,IssuesEvent,2021-02-10 00:12:23,golang/go,https://api.github.com/repos/golang/go,closed,wiki: CodeReviewComments change: suggest got/want phrasing instead of actual/expected.,Documentation NeedsDecision,"Google's internal Go style has converged on ""got/want"" phrasing for test failures, with got before want. This is [reflected in the Standard Library tests, but there are exceptions.](https://golang.org/src/io/io_test.go) Even in the linked io_test.go there is one test that is written in the ""expected/got"" style. I think it would be useful for the external style guide to suggest ""got/want"" as the common convention for test output: ""In test messages, prefer using the terms 'got/want' instead of 'actual/expected.'"" Creating a common convention would make it easier for programmers to read + understand unfamiliar Go tests. It would also mean that we could add a 'got/want' lint rule to Golint.",1.0,"wiki: CodeReviewComments change: suggest got/want phrasing instead of actual/expected. - Google's internal Go style has converged on ""got/want"" phrasing for test failures, with got before want. This is [reflected in the Standard Library tests, but there are exceptions.](https://golang.org/src/io/io_test.go) Even in the linked io_test.go there is one test that is written in the ""expected/got"" style. I think it would be useful for the external style guide to suggest ""got/want"" as the common convention for test output: ""In test messages, prefer using the terms 'got/want' instead of 'actual/expected.'"" Creating a common convention would make it easier for programmers to read + understand unfamiliar Go tests. It would also mean that we could add a 'got/want' lint rule to Golint.",1,wiki codereviewcomments change suggest got want phrasing instead of actual expected google s internal go style has converged on got want phrasing for test failures with got before want this is even in the linked io test go there is one test that is written in the expected got style i think it would be useful for the external style guide to suggest got want as the common convention for test output in test messages prefer using the terms got want instead of actual expected creating a common convention would make it easier for programmers to read understand unfamiliar go tests it would also mean that we could add a got want lint rule to golint ,1 9821,7002265875.0,IssuesEvent,2017-12-18 13:29:32,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: suboptimal compilation of 64-bit OMOD for 386/arm,Performance,"Compiling: ``` package p func f(t int64) int64 { return t%1e9 } ``` for 386 or arm compiles as ``` func f(t int64) int64 { return t - runtime.int64div(t, 1e9) * 1e9 } ``` even though we're not able to do anything to optimize the `* 1e9` multiplication. We might as well just call `runtime.int64mod`. ",True,"cmd/compile: suboptimal compilation of 64-bit OMOD for 386/arm - Compiling: ``` package p func f(t int64) int64 { return t%1e9 } ``` for 386 or arm compiles as ``` func f(t int64) int64 { return t - runtime.int64div(t, 1e9) * 1e9 } ``` even though we're not able to do anything to optimize the `* 1e9` multiplication. We might as well just call `runtime.int64mod`. ",0,cmd compile suboptimal compilation of bit omod for arm compiling package p func f t return t for or arm compiles as func f t return t runtime t even though we re not able to do anything to optimize the multiplication we might as well just call runtime ,0 79925,23070524658.0,IssuesEvent,2022-07-25 17:35:40,golang/go,https://api.github.com/repos/golang/go,closed,"x/build/cmd/pubsubhelper: Gerrit event URL values include an unnecessary ""?usp=email"" query",Builders NeedsFix,"A recent Gerrit event from https://pubsubhelper.golang.org/recent looks like this: ```JSON { ""Time"": ""2022-07-24T18:47:26.542273157Z"", ""Gerrit"": { ""URL"": ""https://go-review.googlesource.com/c/go/+/418734?usp=email"", ""Project"": ""go"", ""CommitHash"": ""e810f8204157253ccc66d7f3b4828551088bcd1a"", ""ChangeNumber"": 418734 } }, ``` Though it's a valid URL, the inclusion of the the ""usp"" query parameter in the change URL isn't something the caller will find helpful, ~~and it's not helping the maintner corpus size either~~. We can trivially omit it. Edit: This event is used only to wake up the maintnerd server, its content doesn't contribute to corpus size.",1.0,"x/build/cmd/pubsubhelper: Gerrit event URL values include an unnecessary ""?usp=email"" query - A recent Gerrit event from https://pubsubhelper.golang.org/recent looks like this: ```JSON { ""Time"": ""2022-07-24T18:47:26.542273157Z"", ""Gerrit"": { ""URL"": ""https://go-review.googlesource.com/c/go/+/418734?usp=email"", ""Project"": ""go"", ""CommitHash"": ""e810f8204157253ccc66d7f3b4828551088bcd1a"", ""ChangeNumber"": 418734 } }, ``` Though it's a valid URL, the inclusion of the the ""usp"" query parameter in the change URL isn't something the caller will find helpful, ~~and it's not helping the maintner corpus size either~~. We can trivially omit it. Edit: This event is used only to wake up the maintnerd server, its content doesn't contribute to corpus size.",0,x build cmd pubsubhelper gerrit event url values include an unnecessary usp email query a recent gerrit event from looks like this json time gerrit url project go commithash changenumber though it s a valid url the inclusion of the the usp query parameter in the change url isn t something the caller will find helpful and it s not helping the maintner corpus size either we can trivially omit it edit this event is used only to wake up the maintnerd server its content doesn t contribute to corpus size ,0 151373,12034593845.0,IssuesEvent,2020-04-13 16:19:51,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/go/loader: TestStdlib is failing on tip because TestTempFile was moved,NeedsFix Testing Tools,"[CL 226877](https://golang.org/cl/226877) has moved the function `TestTempFile` from `io/ioutil` internal test to external test. `TestStdlib` is now failing: ``` $ gotip test [...] --- FAIL: TestStdlib (10.54s) stdlib_test.go:103: package ""io/ioutil"" has no func ""TestTempFile"" stdlib_test.go:117: GOMAXPROCS: 8 stdlib_test.go:118: #Source lines: 1303424 stdlib_test.go:119: Load/parse/typecheck: 10.070588601s stdlib_test.go:120: #MB: 1068 FAIL exit status 1 FAIL golang.org/x/tools/go/loader 19.542s ``` Spotted on [build.golang.org](https://build.golang.org/?repo=golang.org%2fx%2ftools). /cc @ianthehat @matloob per [owners](https://dev.golang.org/owners).",1.0,"x/tools/go/loader: TestStdlib is failing on tip because TestTempFile was moved - [CL 226877](https://golang.org/cl/226877) has moved the function `TestTempFile` from `io/ioutil` internal test to external test. `TestStdlib` is now failing: ``` $ gotip test [...] --- FAIL: TestStdlib (10.54s) stdlib_test.go:103: package ""io/ioutil"" has no func ""TestTempFile"" stdlib_test.go:117: GOMAXPROCS: 8 stdlib_test.go:118: #Source lines: 1303424 stdlib_test.go:119: Load/parse/typecheck: 10.070588601s stdlib_test.go:120: #MB: 1068 FAIL exit status 1 FAIL golang.org/x/tools/go/loader 19.542s ``` Spotted on [build.golang.org](https://build.golang.org/?repo=golang.org%2fx%2ftools). /cc @ianthehat @matloob per [owners](https://dev.golang.org/owners).",0,x tools go loader teststdlib is failing on tip because testtempfile was moved has moved the function testtempfile from io ioutil internal test to external test teststdlib is now failing gotip test fail teststdlib stdlib test go package io ioutil has no func testtempfile stdlib test go gomaxprocs stdlib test go source lines stdlib test go load parse typecheck stdlib test go mb fail exit status fail golang org x tools go loader spotted on cc ianthehat matloob per ,0 211843,16460193729.0,IssuesEvent,2021-05-21 17:44:28,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document database/sql changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
database/sql

TODO: https://golang.org/cl/258360: close driver.Connector if it implements io.Closer

TODO: https://golang.org/cl/311572: add NullInt16 and NullByte

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46008."" in the body.",1.0,"doc/go1.17: document database/sql changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
database/sql

TODO: https://golang.org/cl/258360: close driver.Connector if it implements io.Closer

TODO: https://golang.org/cl/311572: add NullInt16 and NullByte

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46008."" in the body.",1,doc document database sql changes for go as of filing this issue the contained the following html database sql todo a href close driver connector if it implements io closer todo a href add and nullbyte this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 35410,6461914133.0,IssuesEvent,2017-08-16 09:20:44,golang/go,https://api.github.com/repos/golang/go,closed,go/types: Identical ignores receiver of Signature,Documentation,"### What version of Go are you using (`go version`)? go version go1.8.3 linux/amd64 go version devel +827be89a69 Thu Jun 15 21:53:23 2017 +0000 linux/amd64 ### What did you do? In the go/types type system, methods are represented as Func objects with Signature types, where the Signature has a receiver that is not nil. To me, that implies that the receiver is part of the Signature's identity. types.Identical, however, disagrees, and only looks at the arguments and results. This leads to two methods, with differently typed receivers, to be considered identical. I can see arguments for and against this behaviour. On the one hand, it makes correct canonicalisation difficult and leads to confusing behaviour when using e.g. typeutil.Map. Two methods with different receivers are clearly different, requiring a different implicit first argument. Furthermore, swapping supposedly ""identical"" signatures would change the meaning of the program. On the other hand, when working with interfaces and checking whether a method matches the definition in an interface, the receiver is irrelevant. I ran into this behavior while serialising type information to disk, using typeutil.Map to deduplicate type information. This led to a function turning into a method, because it shared the signature (sans receiver) of a method. A program demonstrating the issue is at https://play.golang.org/p/H0FR2qbm2k I'm not sure if this is a bug or working as intended, but either way it is a flaw in the current API. /cc @griesemer ### What did you expect to see? ``` func (pkg.T1).Method() func (pkg.T2).Method() false ``` ### What did you see instead? ``` func (pkg.T1).Method() func (pkg.T2).Method() true ``` ",1.0,"go/types: Identical ignores receiver of Signature - ### What version of Go are you using (`go version`)? go version go1.8.3 linux/amd64 go version devel +827be89a69 Thu Jun 15 21:53:23 2017 +0000 linux/amd64 ### What did you do? In the go/types type system, methods are represented as Func objects with Signature types, where the Signature has a receiver that is not nil. To me, that implies that the receiver is part of the Signature's identity. types.Identical, however, disagrees, and only looks at the arguments and results. This leads to two methods, with differently typed receivers, to be considered identical. I can see arguments for and against this behaviour. On the one hand, it makes correct canonicalisation difficult and leads to confusing behaviour when using e.g. typeutil.Map. Two methods with different receivers are clearly different, requiring a different implicit first argument. Furthermore, swapping supposedly ""identical"" signatures would change the meaning of the program. On the other hand, when working with interfaces and checking whether a method matches the definition in an interface, the receiver is irrelevant. I ran into this behavior while serialising type information to disk, using typeutil.Map to deduplicate type information. This led to a function turning into a method, because it shared the signature (sans receiver) of a method. A program demonstrating the issue is at https://play.golang.org/p/H0FR2qbm2k I'm not sure if this is a bug or working as intended, but either way it is a flaw in the current API. /cc @griesemer ### What did you expect to see? ``` func (pkg.T1).Method() func (pkg.T2).Method() false ``` ### What did you see instead? ``` func (pkg.T1).Method() func (pkg.T2).Method() true ``` ",1,go types identical ignores receiver of signature what version of go are you using go version go version linux go version devel thu jun linux what did you do in the go types type system methods are represented as func objects with signature types where the signature has a receiver that is not nil to me that implies that the receiver is part of the signature s identity types identical however disagrees and only looks at the arguments and results this leads to two methods with differently typed receivers to be considered identical i can see arguments for and against this behaviour on the one hand it makes correct canonicalisation difficult and leads to confusing behaviour when using e g typeutil map two methods with different receivers are clearly different requiring a different implicit first argument furthermore swapping supposedly identical signatures would change the meaning of the program on the other hand when working with interfaces and checking whether a method matches the definition in an interface the receiver is irrelevant i ran into this behavior while serialising type information to disk using typeutil map to deduplicate type information this led to a function turning into a method because it shared the signature sans receiver of a method a program demonstrating the issue is at i m not sure if this is a bug or working as intended but either way it is a flaw in the current api cc griesemer what did you expect to see func pkg method func pkg method false what did you see instead func pkg method func pkg method true ,1 274899,20883189394.0,IssuesEvent,2022-03-23 00:07:39,golang/go,https://api.github.com/repos/golang/go,closed,doc: GOAMD64 not mentionned on https://go.dev/doc/install/source,Documentation NeedsFix,"Go 1.18 introduces [GOAMD64](https://go.dev/doc/go1.18#amd64) compile setting. The GOAMD64 environment variable is not mentionned on https://go.dev/doc/install/source contrary to other environment variables that affect the build. ",1.0,"doc: GOAMD64 not mentionned on https://go.dev/doc/install/source - Go 1.18 introduces [GOAMD64](https://go.dev/doc/go1.18#amd64) compile setting. The GOAMD64 environment variable is not mentionned on https://go.dev/doc/install/source contrary to other environment variables that affect the build. ",1,doc not mentionned on go introduces compile setting the environment variable is not mentionned on contrary to other environment variables that affect the build ,1 99961,11167696261.0,IssuesEvent,2019-12-27 18:16:10,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: improve textDocument/documentLink,Documentation NeedsFix gopls help wanted,"Some additional features we should add support for in `textDocument/documentLink`: - ~~Links missing `http://` or `https://` should be treated as links. For example, `golang.org/issue/12345`.~~ (Completed via [golang.org/cl/194661](https://go-review.googlesource.com/c/tools/+/194661)). - ~~Links to the Go issue tracker should be treated as links. For example, `golang/go#12345`~~. Please add any others as ideas come up.",1.0,"x/tools/gopls: improve textDocument/documentLink - Some additional features we should add support for in `textDocument/documentLink`: - ~~Links missing `http://` or `https://` should be treated as links. For example, `golang.org/issue/12345`.~~ (Completed via [golang.org/cl/194661](https://go-review.googlesource.com/c/tools/+/194661)). - ~~Links to the Go issue tracker should be treated as links. For example, `golang/go#12345`~~. Please add any others as ideas come up.",1,x tools gopls improve textdocument documentlink some additional features we should add support for in textdocument documentlink links missing or should be treated as links for example golang org issue completed via links to the go issue tracker should be treated as links for example golang go please add any others as ideas come up ,1 304678,26323237656.0,IssuesEvent,2023-01-10 02:47:34,golang/go,https://api.github.com/repos/golang/go,closed,misc/cgo: backport needed for dlltool fix,Testing NeedsFix," This is a tracking issue for back-porting https://go.dev/cl/451816 from the main branch to the Go 1.19 and 1.18 release branches (needed due to a builder change). https://go.dev/cl/451816 is a test-only fix to make test misc/cgo/testcshared tests more flexible about the format of the C compiler's dlltool utility (which in some cases is a script, other cases an executable). ",1.0,"misc/cgo: backport needed for dlltool fix - This is a tracking issue for back-porting https://go.dev/cl/451816 from the main branch to the Go 1.19 and 1.18 release branches (needed due to a builder change). https://go.dev/cl/451816 is a test-only fix to make test misc/cgo/testcshared tests more flexible about the format of the C compiler's dlltool utility (which in some cases is a script, other cases an executable). ",0,misc cgo backport needed for dlltool fix this is a tracking issue for back porting from the main branch to the go and release branches needed due to a builder change is a test only fix to make test misc cgo testcshared tests more flexible about the format of the c compiler s dlltool utility which in some cases is a script other cases an executable ,0 5994,2997254325.0,IssuesEvent,2015-07-23 05:51:15,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: document the vendoring setup,Documentation,"The 1.5 go command has an experimental vendoring feature but it is undocumented in the go command, or anywhere else other than an out of date design doc. ",1.0,"cmd/go: document the vendoring setup - The 1.5 go command has an experimental vendoring feature but it is undocumented in the go command, or anywhere else other than an out of date design doc. ",1,cmd go document the vendoring setup the go command has an experimental vendoring feature but it is undocumented in the go command or anywhere else other than an out of date design doc ,1 32592,15496369891.0,IssuesEvent,2021-03-11 02:33:00,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: unnecessary padding in stack frames,NeedsDecision Performance,"In cmd/compile/internal/gc/pgen.go:185, we do: ``` if thearch.LinkArch.InFamily(sys.MIPS, sys.MIPS64, sys.ARM, sys.ARM64, sys.PPC64, sys.S390X) { s.stksize = Rnd(s.stksize, int64(Widthptr)) } ``` This code originated in commit 2ac375b2df85ccf6d2712272bba4d1487e275810 (then called cmd/gc/pgen.c:474, committed by Luuk van Dijk). ``` if(thechar == '5') stksize = rnd(stksize, widthptr); ``` There's no indication why this code was added. I suspect it is not necessary (maybe it was, but is no longer). This issue is to investigate why we do this and whether we can remove it. Reported on go-nuts by Eric from arm. For a simple repro, compile ``` package main func g() func f(p, q *int16) { x := *p y := *q g() *p = y *q = x } ``` The autotmps should be 2 bytes apart, not 8. They are 2 bytes apart on amd64, but not arm64. ",True,"cmd/compile: unnecessary padding in stack frames - In cmd/compile/internal/gc/pgen.go:185, we do: ``` if thearch.LinkArch.InFamily(sys.MIPS, sys.MIPS64, sys.ARM, sys.ARM64, sys.PPC64, sys.S390X) { s.stksize = Rnd(s.stksize, int64(Widthptr)) } ``` This code originated in commit 2ac375b2df85ccf6d2712272bba4d1487e275810 (then called cmd/gc/pgen.c:474, committed by Luuk van Dijk). ``` if(thechar == '5') stksize = rnd(stksize, widthptr); ``` There's no indication why this code was added. I suspect it is not necessary (maybe it was, but is no longer). This issue is to investigate why we do this and whether we can remove it. Reported on go-nuts by Eric from arm. For a simple repro, compile ``` package main func g() func f(p, q *int16) { x := *p y := *q g() *p = y *q = x } ``` The autotmps should be 2 bytes apart, not 8. They are 2 bytes apart on amd64, but not arm64. ",0,cmd compile unnecessary padding in stack frames in cmd compile internal gc pgen go we do if thearch linkarch infamily sys mips sys sys arm sys sys sys s stksize rnd s stksize widthptr this code originated in commit then called cmd gc pgen c committed by luuk van dijk if thechar stksize rnd stksize widthptr there s no indication why this code was added i suspect it is not necessary maybe it was but is no longer this issue is to investigate why we do this and whether we can remove it reported on go nuts by eric from arm for a simple repro compile package main func g func f p q x p y q g p y q x the autotmps should be bytes apart not they are bytes apart on but not ,0 48034,12137402738.0,IssuesEvent,2020-04-23 15:40:50,golang/go,https://api.github.com/repos/golang/go,closed,x/build: windows arm builder missing,Builders WaitingForInfo,"The windows arm builder has been missing for some time now: `host-windows-arm-iotcore: 0/0 (1 missing)` We should work to bring the builder back if possible. /cc @andybons @dmitshur @toothrot ",1.0,"x/build: windows arm builder missing - The windows arm builder has been missing for some time now: `host-windows-arm-iotcore: 0/0 (1 missing)` We should work to bring the builder back if possible. /cc @andybons @dmitshur @toothrot ",0,x build windows arm builder missing the windows arm builder has been missing for some time now host windows arm iotcore missing we should work to bring the builder back if possible cc andybons dmitshur toothrot ,0 61863,8559865821.0,IssuesEvent,2018-11-08 22:41:30,golang/go,https://api.github.com/repos/golang/go,closed,x/image/draw: Transformer documentation is misformatted,Documentation,"[`draw.Transformer`](https://godoc.org/golang.org/x/image/draw#Transformer) documentation currently looks like this: ![image](https://user-images.githubusercontent.com/1924134/48229705-dd1b4c80-e376-11e8-86ac-9363db916f80.png) It should look more like this: ![image](https://user-images.githubusercontent.com/1924134/48229732-f4f2d080-e376-11e8-968e-5a63bca0abb8.png)",1.0,"x/image/draw: Transformer documentation is misformatted - [`draw.Transformer`](https://godoc.org/golang.org/x/image/draw#Transformer) documentation currently looks like this: ![image](https://user-images.githubusercontent.com/1924134/48229705-dd1b4c80-e376-11e8-86ac-9363db916f80.png) It should look more like this: ![image](https://user-images.githubusercontent.com/1924134/48229732-f4f2d080-e376-11e8-968e-5a63bca0abb8.png)",1,x image draw transformer documentation is misformatted documentation currently looks like this it should look more like this ,1 297117,22340355028.0,IssuesEvent,2022-06-14 23:45:05,golang/go,https://api.github.com/repos/golang/go,closed,"spec: review/clarify uses of ""slice of bytes""",Documentation,"This is a follow-up issue for #23536: Comb through documentation (spec, builtins) to verify the use of the term ""slice of bytes"". The spec appears to mean by this any type whose underlying type is `[]byte`. But not all implementations agree. ",1.0,"spec: review/clarify uses of ""slice of bytes"" - This is a follow-up issue for #23536: Comb through documentation (spec, builtins) to verify the use of the term ""slice of bytes"". The spec appears to mean by this any type whose underlying type is `[]byte`. But not all implementations agree. ",1,spec review clarify uses of slice of bytes this is a follow up issue for comb through documentation spec builtins to verify the use of the term slice of bytes the spec appears to mean by this any type whose underlying type is byte but not all implementations agree ,1 35134,6416420042.0,IssuesEvent,2017-08-08 14:46:57,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/cmd/callgraph: usage text suggests invalid code,Documentation,"The [usage](https://github.com/golang/tools/blob/bf4b54dc687c73b6ef63de8b8abf0ad3951e3edc/cmd/callgraph/main.go#L117) text of `x/tools/cmd/callgraph` command mentions: > e.g. Caller.Pkg.Object.Path yields the import path of the enclosing package. > Consult the go/ssa API documentation for details. > Examples: > > callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' \ > $GOROOT/src/net/http/triv.go | sort | uniq `Caller` is [`*ssa.Function`](https://godoc.org/golang.org/x/tools/go/ssa#Function). Its `Pkg` field is [`*ssa.Package`](https://godoc.org/golang.org/x/tools/go/ssa#Package). But `ssa.Package` struct doesn't contain either field or method named `Object`. So one gets the following error: ``` $ callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' $(go env GOROOT)/src/net/http/triv.go | sort | uniq callgraph: template: -format:1:9: executing ""-format"" at <.Caller.Pkg.Object.P...>: can't evaluate field Object in type *ssa.Package ``` I'm guessing that instead of `Caller.Pkg.Object.Path`, it should be `Caller.Pkg.Pkg.Path`: https://godoc.org/golang.org/x/tools/go/ssa#Package.Pkg That works as expected in my testing. My environment details:
### What version of Go are you using (`go version`)? ``` $ go version go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ```bash $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build822597389=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ```
",1.0,"x/tools/cmd/callgraph: usage text suggests invalid code - The [usage](https://github.com/golang/tools/blob/bf4b54dc687c73b6ef63de8b8abf0ad3951e3edc/cmd/callgraph/main.go#L117) text of `x/tools/cmd/callgraph` command mentions: > e.g. Caller.Pkg.Object.Path yields the import path of the enclosing package. > Consult the go/ssa API documentation for details. > Examples: > > callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' \ > $GOROOT/src/net/http/triv.go | sort | uniq `Caller` is [`*ssa.Function`](https://godoc.org/golang.org/x/tools/go/ssa#Function). Its `Pkg` field is [`*ssa.Package`](https://godoc.org/golang.org/x/tools/go/ssa#Package). But `ssa.Package` struct doesn't contain either field or method named `Object`. So one gets the following error: ``` $ callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' $(go env GOROOT)/src/net/http/triv.go | sort | uniq callgraph: template: -format:1:9: executing ""-format"" at <.Caller.Pkg.Object.P...>: can't evaluate field Object in type *ssa.Package ``` I'm guessing that instead of `Caller.Pkg.Object.Path`, it should be `Caller.Pkg.Pkg.Path`: https://godoc.org/golang.org/x/tools/go/ssa#Package.Pkg That works as expected in my testing. My environment details:
### What version of Go are you using (`go version`)? ``` $ go version go version go1.8.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ```bash $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build822597389=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" PKG_CONFIG=""pkg-config"" CGO_CFLAGS=""-g -O2"" CGO_CPPFLAGS="""" CGO_CXXFLAGS=""-g -O2"" CGO_FFLAGS=""-g -O2"" CGO_LDFLAGS=""-g -O2"" ```
",1,x tools cmd callgraph usage text suggests invalid code the text of x tools cmd callgraph command mentions e g caller pkg object path yields the import path of the enclosing package consult the go ssa api documentation for details examples callgraph format caller pkg object path callee pkg object path goroot src net http triv go sort uniq caller is its pkg field is but ssa package struct doesn t contain either field or method named object so one gets the following error callgraph format caller pkg object path callee pkg object path go env goroot src net http triv go sort uniq callgraph template format executing format at can t evaluate field object in type ssa package i m guessing that instead of caller pkg object path it should be caller pkg pkg path that works as expected in my testing my environment details what version of go are you using go version go version go version darwin what operating system and processor architecture are you using go env bash go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users dmitri dropbox work golanding users dmitri dropbox work goland gorace goroot usr local go gotooldir usr local go pkg tool darwin gccgo gccgo cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders tw t go tmp go build gno record gcc switches fno common cxx clang cgo enabled pkg config pkg config cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g ,1 196423,15594086932.0,IssuesEvent,2021-03-18 13:32:28,golang/go,https://api.github.com/repos/golang/go,closed,"crypto/rsa: EncryptOAEP documentation says ""if a given public key is used to decrypt"" instead of ""encrypt""",Documentation NeedsFix,"### What did you do? Opened https://golang.org/pkg/crypto/rsa/#EncryptOAEP in browser ### What did you expect to see? For example, if a given public key is used to **encrypt** two types of messages, then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker. ### What did you see instead? For example, if a given public key is used to **decrypt** two types of messages then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker.",1.0,"crypto/rsa: EncryptOAEP documentation says ""if a given public key is used to decrypt"" instead of ""encrypt"" - ### What did you do? Opened https://golang.org/pkg/crypto/rsa/#EncryptOAEP in browser ### What did you expect to see? For example, if a given public key is used to **encrypt** two types of messages, then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker. ### What did you see instead? For example, if a given public key is used to **decrypt** two types of messages then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker.",1,crypto rsa encryptoaep documentation says if a given public key is used to decrypt instead of encrypt what did you do opened in browser what did you expect to see for example if a given public key is used to encrypt two types of messages then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker what did you see instead for example if a given public key is used to decrypt two types of messages then distinct label values could be used to ensure that a ciphertext for one purpose cannot be used for another by an attacker ,1 6686,5583036750.0,IssuesEvent,2017-03-28 22:54:36,golang/go,https://api.github.com/repos/golang/go,closed,fmt: Printf arguments escape to heap,LongTerm Performance," package main import ""fmt"" func main() { var a = []int{} fmt.Println(a) // a escapes to heap } It looks it is caused by the pp struct in print.go which holds the printed arguments and pp values are referenced by other heap values. This can be avoided. type pp struct { buf buffer // arg holds the current item, as an interface{}. arg interface{} // value is used instead of arg for reflect values. value reflect.Value ... } ",True,"fmt: Printf arguments escape to heap - package main import ""fmt"" func main() { var a = []int{} fmt.Println(a) // a escapes to heap } It looks it is caused by the pp struct in print.go which holds the printed arguments and pp values are referenced by other heap values. This can be avoided. type pp struct { buf buffer // arg holds the current item, as an interface{}. arg interface{} // value is used instead of arg for reflect values. value reflect.Value ... } ",0,fmt printf arguments escape to heap package main import fmt func main var a int fmt println a a escapes to heap it looks it is caused by the pp struct in print go which holds the printed arguments and pp values are referenced by other heap values this can be avoided type pp struct buf buffer arg holds the current item as an interface arg interface value is used instead of arg for reflect values value reflect value ,0 21587,4726882938.0,IssuesEvent,2016-10-18 11:46:47,golang/go,https://api.github.com/repos/golang/go,closed,net: InterfaceAddrs is not good for multi-homed IP node,Documentation NeedsFix,"I propose adding the missing Zone field to IPNet structure. A trouble: The lack of IPv6 addressing scope information makes IPNet less usable. For example, when we have an IPNet and it represents an IPv6 link-local address, it's hard for us to distinguish the address belongs to which link/network interface. A workaround: Rescan IP routing information by using Interfaces function and Addrs method of Interface structure (and play a guessing game when the address comes from foreign packages because it's possible to have the same IPv6 link-local address on all the equipped links.) Proposal: From Go 1.6 the network interface and interface address identification feature works correctly for both IPv4 and IPv6 on tier-1 platforms. I think it makes sense to add Zone field to IPNet structure the same as {IP,TCP,UDP}Addr structures like the following: ``` type IPNet struct { IP IP // network number Mask IPMask // network mask Zone string // IPv6 scoped addressing zone } ``` make IPNet.String return ""fe80::1%en0/64"" and ParseCIDR function being able to parse IPv6 address prefix literal including zone identifier such as ""fe80::1%en0/64"". Also network interface and interface address identification feature comprised of Interfaces function and Addrs method of Interface structure behaves the same as IP address resolution and connection setup features; just handles unicast IPv6 link-local addressing scope information only. An implementation: https://go-review.googlesource.com/#/c/19946/",1.0,"net: InterfaceAddrs is not good for multi-homed IP node - I propose adding the missing Zone field to IPNet structure. A trouble: The lack of IPv6 addressing scope information makes IPNet less usable. For example, when we have an IPNet and it represents an IPv6 link-local address, it's hard for us to distinguish the address belongs to which link/network interface. A workaround: Rescan IP routing information by using Interfaces function and Addrs method of Interface structure (and play a guessing game when the address comes from foreign packages because it's possible to have the same IPv6 link-local address on all the equipped links.) Proposal: From Go 1.6 the network interface and interface address identification feature works correctly for both IPv4 and IPv6 on tier-1 platforms. I think it makes sense to add Zone field to IPNet structure the same as {IP,TCP,UDP}Addr structures like the following: ``` type IPNet struct { IP IP // network number Mask IPMask // network mask Zone string // IPv6 scoped addressing zone } ``` make IPNet.String return ""fe80::1%en0/64"" and ParseCIDR function being able to parse IPv6 address prefix literal including zone identifier such as ""fe80::1%en0/64"". Also network interface and interface address identification feature comprised of Interfaces function and Addrs method of Interface structure behaves the same as IP address resolution and connection setup features; just handles unicast IPv6 link-local addressing scope information only. An implementation: https://go-review.googlesource.com/#/c/19946/",1,net interfaceaddrs is not good for multi homed ip node i propose adding the missing zone field to ipnet structure a trouble the lack of addressing scope information makes ipnet less usable for example when we have an ipnet and it represents an link local address it s hard for us to distinguish the address belongs to which link network interface a workaround rescan ip routing information by using interfaces function and addrs method of interface structure and play a guessing game when the address comes from foreign packages because it s possible to have the same link local address on all the equipped links proposal from go the network interface and interface address identification feature works correctly for both and on tier platforms i think it makes sense to add zone field to ipnet structure the same as ip tcp udp addr structures like the following type ipnet struct ip ip network number mask ipmask network mask zone string scoped addressing zone make ipnet string return and parsecidr function being able to parse address prefix literal including zone identifier such as also network interface and interface address identification feature comprised of interfaces function and addrs method of interface structure behaves the same as ip address resolution and connection setup features just handles unicast link local addressing scope information only an implementation ,1 31714,5987743688.0,IssuesEvent,2017-06-02 01:04:02,golang/go,https://api.github.com/repos/golang/go,closed,compress/gzip: Close() documentation is incomplete,Documentation,"( Originally noted running Go 1.8.3 locally on MacOS Sierra 10.12.5. Looking at current on-line documentation at golang.org/pkg/compress/gzip. ) The documentation of Close() method of gzip.Writer says that it flushes any unwritten data and implies that it does nothing more. That's not quite correct. Critically, it also writes a termination sequence to the output file. Without this, the corresponding Reader will return an ""unexpected EOF"" error. I think that's a significant omission. From the documentation I concluded that Flush and Close were equivalent, and I initially chose the wrong one. Sample test program: https://play.golang.org/p/zPOjLCAttg The same situation also exists in the very similar compress/zlib package. ",1.0,"compress/gzip: Close() documentation is incomplete - ( Originally noted running Go 1.8.3 locally on MacOS Sierra 10.12.5. Looking at current on-line documentation at golang.org/pkg/compress/gzip. ) The documentation of Close() method of gzip.Writer says that it flushes any unwritten data and implies that it does nothing more. That's not quite correct. Critically, it also writes a termination sequence to the output file. Without this, the corresponding Reader will return an ""unexpected EOF"" error. I think that's a significant omission. From the documentation I concluded that Flush and Close were equivalent, and I initially chose the wrong one. Sample test program: https://play.golang.org/p/zPOjLCAttg The same situation also exists in the very similar compress/zlib package. ",1,compress gzip close documentation is incomplete originally noted running go locally on macos sierra looking at current on line documentation at golang org pkg compress gzip the documentation of close method of gzip writer says that it flushes any unwritten data and implies that it does nothing more that s not quite correct critically it also writes a termination sequence to the output file without this the corresponding reader will return an unexpected eof error i think that s a significant omission from the documentation i concluded that flush and close were equivalent and i initially chose the wrong one sample test program the same situation also exists in the very similar compress zlib package ,1 76489,9942996311.0,IssuesEvent,2019-07-03 14:58:17,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: cannot find module for path,Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
go version go1.12.6 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/Users/tristian/go/bin""
GOCACHE=""/Users/tristian/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/tristian/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/Cellar/go/1.12.6/libexec""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.12.6/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/tristian/Repositories/github.com/triztian/my.binary.project/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/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build549198414=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Tried to build the executable after running `rm -rf $GOPATH/pkg`, I then ran `go mod download` and tried to do a build: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go build -x -a -v WORK=/var/folders/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build723678509 build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` After getting that error message, I ensured that the module is fetched and downloaded: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go get code.blockwave.com/blockwave/core.components.engine/wave/plugin-master go: finding code.blockwave.com/blockwave/core.components.engine/wave/plugin-master latest go: finding code.blockwave.com/blockwave/core.components.engine/wave latest go: finding code.blockwave.com/blockwave/core.components.engine latest ``` Then I retried the build: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go build -x -a -v WORK=/var/folders/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build629362765 build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` Same result, so I now tried cleaning the cache: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go clean -modcache build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` I've also ran `go mod verify`, and it reports no issues: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin (issue/blockwave.trunk.11): go mod verify all modules verified ``` ### What did you expect to see? I expected to see a `core.bin` executable in my current directory. ### What did you see instead? ``` build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` ---- I tried to reproduce the issue and to setup a project that mimics the structure of the one that I'm experiencing issues with but it seems to be specific to my setup: * Main Executable: https://github.com/triztian/my.binary.project * Library that uses cgo: https://github.com/triztian/my.special.library However with such setup I'm able to produce a valid executable: ``` λ ~/Repositories/github.com/triztian/my.binary.project (master): go build -v λ ~/Repositories/github.com/triztian/my.binary.project (master): ls build_commands.txt go.mod main.go cmd go.sum my.binary.project ``` And it runs correctly: ``` ./my.binary.project 42 ``` Is there a way for me to get more information about the specific package that is failing?",1.0,"cmd/go: cannot find module for path - ### What version of Go are you using (`go version`)? 
go version go1.12.6 darwin/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GOARCH=""amd64""
GOBIN=""/Users/tristian/go/bin""
GOCACHE=""/Users/tristian/Library/Caches/go-build""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GOOS=""darwin""
GOPATH=""/Users/tristian/go""
GOPROXY=""""
GORACE=""""
GOROOT=""/usr/local/Cellar/go/1.12.6/libexec""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/Cellar/go/1.12.6/libexec/pkg/tool/darwin_amd64""
GCCGO=""gccgo""
CC=""clang""
CXX=""clang++""
CGO_ENABLED=""1""
GOMOD=""/Users/tristian/Repositories/github.com/triztian/my.binary.project/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/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build549198414=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? Tried to build the executable after running `rm -rf $GOPATH/pkg`, I then ran `go mod download` and tried to do a build: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go build -x -a -v WORK=/var/folders/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build723678509 build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` After getting that error message, I ensured that the module is fetched and downloaded: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go get code.blockwave.com/blockwave/core.components.engine/wave/plugin-master go: finding code.blockwave.com/blockwave/core.components.engine/wave/plugin-master latest go: finding code.blockwave.com/blockwave/core.components.engine/wave latest go: finding code.blockwave.com/blockwave/core.components.engine latest ``` Then I retried the build: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go build -x -a -v WORK=/var/folders/g1/v3hz1sm92nv7wbzpg3dx_h_h0000gp/T/go-build629362765 build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` Same result, so I now tried cleaning the cache: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin: go clean -modcache build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` I've also ran `go mod verify`, and it reports no issues: ``` λ ~/Repositories/code.blockwave.com/blockwave/core.bin (issue/blockwave.trunk.11): go mod verify all modules verified ``` ### What did you expect to see? I expected to see a `core.bin` executable in my current directory. ### What did you see instead? ``` build code.blockwave.com/blockwave/core.bin: cannot find module for path code.blockwave.com/blockwave/core.components.engine/wave/plugin-master ``` ---- I tried to reproduce the issue and to setup a project that mimics the structure of the one that I'm experiencing issues with but it seems to be specific to my setup: * Main Executable: https://github.com/triztian/my.binary.project * Library that uses cgo: https://github.com/triztian/my.special.library However with such setup I'm able to produce a valid executable: ``` λ ~/Repositories/github.com/triztian/my.binary.project (master): go build -v λ ~/Repositories/github.com/triztian/my.binary.project (master): ls build_commands.txt go.mod main.go cmd go.sum my.binary.project ``` And it runs correctly: ``` ./my.binary.project 42 ``` Is there a way for me to get more information about the specific package that is failing?",1,cmd go cannot find module for path what version of go are you using go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin users tristian go bin gocache users tristian library caches go build goexe goflags gohostarch gohostos darwin goos darwin gopath users tristian go goproxy gorace goroot usr local cellar go libexec gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled gomod users tristian repositories github com triztian my binary project go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders h t go tmp go build gno record gcc switches fno common what did you do tried to build the executable after running rm rf gopath pkg i then ran go mod download and tried to do a build λ repositories code blockwave com blockwave core bin go build x a v work var folders h t go build code blockwave com blockwave core bin cannot find module for path code blockwave com blockwave core components engine wave plugin master after getting that error message i ensured that the module is fetched and downloaded λ repositories code blockwave com blockwave core bin go get code blockwave com blockwave core components engine wave plugin master go finding code blockwave com blockwave core components engine wave plugin master latest go finding code blockwave com blockwave core components engine wave latest go finding code blockwave com blockwave core components engine latest then i retried the build λ repositories code blockwave com blockwave core bin go build x a v work var folders h t go build code blockwave com blockwave core bin cannot find module for path code blockwave com blockwave core components engine wave plugin master same result so i now tried cleaning the cache λ repositories code blockwave com blockwave core bin go clean modcache build code blockwave com blockwave core bin cannot find module for path code blockwave com blockwave core components engine wave plugin master i ve also ran go mod verify and it reports no issues λ repositories code blockwave com blockwave core bin issue blockwave trunk go mod verify all modules verified if possible provide a recipe for reproducing the error a complete runnable program is good a link on play golang org is best what did you expect to see i expected to see a core bin executable in my current directory what did you see instead build code blockwave com blockwave core bin cannot find module for path code blockwave com blockwave core components engine wave plugin master i tried to reproduce the issue and to setup a project that mimics the structure of the one that i m experiencing issues with but it seems to be specific to my setup main executable library that uses cgo however with such setup i m able to produce a valid executable λ repositories github com triztian my binary project master go build v λ repositories github com triztian my binary project master ls build commands txt go mod main go cmd go sum my binary project and it runs correctly my binary project is there a way for me to get more information about the specific package that is failing ,1 227294,17379693663.0,IssuesEvent,2021-07-31 12:43:14,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document that SetCookie can quote the value,Documentation NeedsInvestigation,"The `SetCookie` function quotes the value if it contains spaces or commas but this behavior is not documented in `SetCookie` documentation: > SetCookie adds a Set-Cookie header to the provided ResponseWriter's headers. The provided cookie must have a valid Name. Invalid cookies may be silently dropped. ",1.0,"net/http: document that SetCookie can quote the value - The `SetCookie` function quotes the value if it contains spaces or commas but this behavior is not documented in `SetCookie` documentation: > SetCookie adds a Set-Cookie header to the provided ResponseWriter's headers. The provided cookie must have a valid Name. Invalid cookies may be silently dropped. ",1,net http document that setcookie can quote the value the setcookie function quotes the value if it contains spaces or commas but this behavior is not documented in setcookie documentation setcookie adds a set cookie header to the provided responsewriter s headers the provided cookie must have a valid name invalid cookies may be silently dropped ,1 102268,16555874343.0,IssuesEvent,2021-05-28 13:53:54,golang/go,https://api.github.com/repos/golang/go,closed,archive/zip: malformed archive may cause panic or memory exhaustion [1.16 backport],CherryPickApproved Security release-blocker,"@rolandshoemaker requested issue #46242 to be considered for backport to the next 1.16 minor release. > @gopherbot please consider this for backport to 1.15 and 1.16 as this is a security issue. ",True,"archive/zip: malformed archive may cause panic or memory exhaustion [1.16 backport] - @rolandshoemaker requested issue #46242 to be considered for backport to the next 1.16 minor release. > @gopherbot please consider this for backport to 1.15 and 1.16 as this is a security issue. ",0,archive zip malformed archive may cause panic or memory exhaustion rolandshoemaker requested issue to be considered for backport to the next minor release gopherbot please consider this for backport to and as this is a security issue ,0 8723,3210522794.0,IssuesEvent,2015-10-06 03:49:18,golang/go,https://api.github.com/repos/golang/go,closed,"tour: clarify what ""export"" means",Documentation,"Context: https://tour.golang.org/basics/3 Change the title above to describe your issue and add your feedback here, including code if necessary hI I did not understand the description export.Please provide more clear explanation regards,ppp ",1.0,"tour: clarify what ""export"" means - Context: https://tour.golang.org/basics/3 Change the title above to describe your issue and add your feedback here, including code if necessary hI I did not understand the description export.Please provide more clear explanation regards,ppp ",1,tour clarify what export means context change the title above to describe your issue and add your feedback here including code if necessary hi i did not understand the description export please provide more clear explanation regards ppp ,1 55799,8030781312.0,IssuesEvent,2018-07-27 21:01:48,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document filepath sanitization for ServeFile,Documentation NeedsFix Security help wanted,"This is a petty formulation issue, but the subject is quite sensitive so I thought I would bring it up. The documentation for http.ServeFile(w ResponseWriter, r *Request, name string) states that name needs to be sanitized to prevent ascension into parent directories. It further states that ServeFile rejects requests that contain "".."" as path elements. I assume the implication of both statements combined is that patterns like ``` http.ServeFile(w, r, filepath.Join(""."", r.URL.Path)) http.ServeFile(w, r, filepath.Join(""dir"", r.URL.Path)) ``` are ""safe"" in the sense that ascension into the respective parent directories is not possible. However this is not obvious from the current documentation as there may more obscure ways of ascending than "".."" that are less obvious (I am honestly not sure). Imo it would be a good idea to state explicitly whether the file path in the above patterns is sufficiently sanitized or not because I see only two scenarios: -If the patterns above are not safe the current documentation may cause security problems -If the patterns are safe some users won't take advantage of this great function because it is not explicitly stated (this is me right now).",1.0,"net/http: document filepath sanitization for ServeFile - This is a petty formulation issue, but the subject is quite sensitive so I thought I would bring it up. The documentation for http.ServeFile(w ResponseWriter, r *Request, name string) states that name needs to be sanitized to prevent ascension into parent directories. It further states that ServeFile rejects requests that contain "".."" as path elements. I assume the implication of both statements combined is that patterns like ``` http.ServeFile(w, r, filepath.Join(""."", r.URL.Path)) http.ServeFile(w, r, filepath.Join(""dir"", r.URL.Path)) ``` are ""safe"" in the sense that ascension into the respective parent directories is not possible. However this is not obvious from the current documentation as there may more obscure ways of ascending than "".."" that are less obvious (I am honestly not sure). Imo it would be a good idea to state explicitly whether the file path in the above patterns is sufficiently sanitized or not because I see only two scenarios: -If the patterns above are not safe the current documentation may cause security problems -If the patterns are safe some users won't take advantage of this great function because it is not explicitly stated (this is me right now).",1,net http document filepath sanitization for servefile this is a petty formulation issue but the subject is quite sensitive so i thought i would bring it up the documentation for http servefile w responsewriter r request name string states that name needs to be sanitized to prevent ascension into parent directories it further states that servefile rejects requests that contain as path elements i assume the implication of both statements combined is that patterns like http servefile w r filepath join r url path http servefile w r filepath join dir r url path are safe in the sense that ascension into the respective parent directories is not possible however this is not obvious from the current documentation as there may more obscure ways of ascending than that are less obvious i am honestly not sure imo it would be a good idea to state explicitly whether the file path in the above patterns is sufficiently sanitized or not because i see only two scenarios if the patterns above are not safe the current documentation may cause security problems if the patterns are safe some users won t take advantage of this great function because it is not explicitly stated this is me right now ,1 16517,4056662158.0,IssuesEvent,2016-05-24 19:23:40,golang/go,https://api.github.com/repos/golang/go,closed,doc: give more tips on proper commit message style,Documentation NeedsFix,In https://go-review.googlesource.com/#/c/21815/1//COMMIT_MSG @bradfitz offers a good tip on how to phrase commit titles. Writing titles and messages is touched on briefly in the [contribution guidelines](https://golang.org/doc/contribute.html#change) but would be nice to mention this and other tips and/or style guidelines.,1.0,doc: give more tips on proper commit message style - In https://go-review.googlesource.com/#/c/21815/1//COMMIT_MSG @bradfitz offers a good tip on how to phrase commit titles. Writing titles and messages is touched on briefly in the [contribution guidelines](https://golang.org/doc/contribute.html#change) but would be nice to mention this and other tips and/or style guidelines.,1,doc give more tips on proper commit message style in bradfitz offers a good tip on how to phrase commit titles writing titles and messages is touched on briefly in the but would be nice to mention this and other tips and or style guidelines ,1 389290,26806326668.0,IssuesEvent,2023-02-01 18:35:29,golang/go,https://api.github.com/repos/golang/go,closed,doc: write Go 1.20 release notes,Documentation NeedsFix early-in-cycle umbrella,"This is the tracking issue for writing the Go 1.20 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.20. When the Go 1.20 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #51400, #47694, #44513, etc.",1.0,"doc: write Go 1.20 release notes - This is the tracking issue for writing the Go 1.20 Release Notes. The version at tip can be viewed at https://tip.golang.org/doc/go1.20. When the Go 1.20 Release Notes are complete, this should be closed, and a similar issue should be made for the next release. Previous issues are #51400, #47694, #44513, etc.",1,doc write go release notes this is the tracking issue for writing the go release notes the version at tip can be viewed at when the go release notes are complete this should be closed and a similar issue should be made for the next release previous issues are etc ,1 173275,14406753584.0,IssuesEvent,2020-12-03 20:43:06,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.16: document runtime changes for Go 1.16,Documentation NeedsInvestigation release-blocker,"As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:

Runtime

TODO

On Linux, the runtime now defaults to releasing memory to the operating system promptly (using MADV_DONTNEED), rather than lazily when the operating system is under memory pressure (using MADV_FREE). This means process-level memory statistics like RSS will more accurately reflect the amount of physical memory being used by Go processes. Systems that are currently using GODEBUG=madvdontneed=1 to improve memory monitoring behavior no longer need to set this environment variable.

[...]
runtime

TODO: https://golang.org/cl/37222: make stack traces of endless recursion print only top and bottom 50

TODO: https://golang.org/cl/242258: add 24 byte allocation size class

TODO: https://golang.org/cl/254659: implement GODEBUG=inittrace=1 support

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body. ",1.0,"doc/go1.16: document runtime changes for Go 1.16 - As of filing this issue, the [Go 1.16 draft release notes](https://tip.golang.org/doc/go1.16) contained the following HTML:

Runtime

TODO

On Linux, the runtime now defaults to releasing memory to the operating system promptly (using MADV_DONTNEED), rather than lazily when the operating system is under memory pressure (using MADV_FREE). This means process-level memory statistics like RSS will more accurately reflect the amount of physical memory being used by Go processes. Systems that are currently using GODEBUG=madvdontneed=1 to improve memory monitoring behavior no longer need to set this environment variable.

[...]
runtime

TODO: https://golang.org/cl/37222: make stack traces of endless recursion print only top and bottom 50

TODO: https://golang.org/cl/242258: add 24 byte allocation size class

TODO: https://golang.org/cl/254659: implement GODEBUG=inittrace=1 support

--- Per [golang.org/s/release](https://golang.org/s/release), it's a release blocker for Go 1.16 Beta 1 to have a complete draft of the eventual release notes, and so the TODO needs to be resolved. A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.16:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.16) and include ""For #40700. Fixes #{this issue}."" in the body. ",1,doc document runtime changes for go as of filing this issue the contained the following html runtime todo on linux the runtime now defaults to releasing memory to the operating system promptly using madv dontneed rather than lazily when the operating system is under memory pressure using madv free this means process level memory statistics like rss will more accurately reflect the amount of physical memory being used by go processes systems that are currently using godebug madvdontneed to improve memory monitoring behavior no longer need to set this environment variable runtime todo a href make stack traces of endless recursion print only top and bottom todo a href add byte allocation size class todo a href implement godebug inittrace support per it s a release blocker for go beta to have a complete draft of the eventual release notes and so the todo needs to be resolved a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes this issue in the body ,1 132994,12529201557.0,IssuesEvent,2020-06-04 10:54:18,golang/go,https://api.github.com/repos/golang/go,closed,io/ioutil: docs for WriteFile should make it clear that it does not change permissions,Documentation WaitingForInfo," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.1 linux/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/andrew/.cache/go-build""
GOENV=""/home/andrew/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/andrew/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.13""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.13/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/andrew/go/src/code.gitea.io/gitea/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-build028639981=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Say you had `some-extant-file` with mode 0644 and you run: ```go ioutil.WriteFile(""some-extant-file"", []byte(""new data""), 0777) ``` ### What did you expect to see? From a cursory glance of the documentation you would expect that the mode of `some-extant-file` would change to 0777. ### What did you see instead? It doesn't change mode - as is implied by the documentation saying it ""truncates the file"" I think the documentation for `ioutil.WriteFile` should be clearer that when the file is already extant its mode will not change. This is implied by the current documentation, but it is subtle and a quick review of the docs will lead to and has led to developers & reviewers missing this important note causing bugs.",1.0,"io/ioutil: docs for WriteFile should make it clear that it does not change permissions - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.1 linux/amd64
### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/andrew/.cache/go-build""
GOENV=""/home/andrew/.config/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/andrew/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/lib/go-1.13""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/lib/go-1.13/pkg/tool/linux_amd64""
GCCGO=""gccgo""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/home/andrew/go/src/code.gitea.io/gitea/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-build028639981=/tmp/go-build -gno-record-gcc-switches""
### What did you do? Say you had `some-extant-file` with mode 0644 and you run: ```go ioutil.WriteFile(""some-extant-file"", []byte(""new data""), 0777) ``` ### What did you expect to see? From a cursory glance of the documentation you would expect that the mode of `some-extant-file` would change to 0777. ### What did you see instead? It doesn't change mode - as is implied by the documentation saying it ""truncates the file"" I think the documentation for `ioutil.WriteFile` should be clearer that when the file is already extant its mode will not change. This is implied by the current documentation, but it is subtle and a quick review of the docs will lead to and has led to developers & reviewers missing this important note causing bugs.",1,io ioutil docs for writefile should make it clear that it does not change permissions what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home andrew cache go build goenv home andrew config go env goexe goflags gohostarch gohostos linux gonoproxy gonosumdb goos linux gopath home andrew go goprivate goproxy goroot usr lib go gosumdb sum golang org gotmpdir gotooldir usr lib go pkg tool linux gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod home andrew go src code gitea io gitea go mod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do say you had some extant file with mode and you run go ioutil writefile some extant file byte new data what did you expect to see from a cursory glance of the documentation you would expect that the mode of some extant file would change to what did you see instead it doesn t change mode as is implied by the documentation saying it truncates the file i think the documentation for ioutil writefile should be clearer that when the file is already extant its mode will not change this is implied by the current documentation but it is subtle and a quick review of the docs will lead to and has led to developers reviewers missing this important note causing bugs ,1 31244,4699124622.0,IssuesEvent,2016-10-12 14:52:28,golang/go,https://api.github.com/repos/golang/go,opened,x/tools/go/loader: tests fail at tip,Testing,"@griesemer, @alandonovan .... ``` bradfitz@dev-bradfitz:~/src/golang.org/x/tools$ go test -short ./go/loader cannot find package ""nosuchpkg"" in any of: /home/bradfitz/go/src/nosuchpkg (from $GOROOT) /home/bradfitz/src/nosuchpkg (from $GOPATH) cannot find package ""nosuchpkg"" in any of: /home/bradfitz/go/src/nosuchpkg (from $GOROOT) /home/bradfitz/src/nosuchpkg (from $GOPATH) open missing.go: no such file or directory open missing.go: no such file or directory testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF' testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF' /go/src/b/x.go:1:21: could not import c (cannot find package ""c"" in any of: /go/src/c (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath')) /go/src/b/x.go:1:21: could not import c (cannot find package ""c"" in any of: /go/src/c (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath')) /go/src/b/x.go:1:21: could not import c (/go/src/c/x.go:1:8: expected 'IDENT', found 'EOF') /go/src/c/x.go:1:20: expected operand, found 'EOF' cannot find package ""two/three"" in any of: /go/src/two/three (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath') cannot find package ""http"" in any of: /go/src/http (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath') /go/src/c/x.go:1:31: cannot convert false (untyped bool constant) to int --- FAIL: ExampleConfig_CreateFromFilenames (0.70s) got: created: [container/heap] imported: [] initial: [container/heap] all: [container/heap errors internal/race math reflect runtime runtime/internal/atomic runtime/internal/sys sort strconv sync sync/atomic unicode/utf8 unsafe] want: created: [container/heap] imported: [] initial: [container/heap] all: [container/heap sort] FAIL FAIL golang.org/x/tools/go/loader 5.288s ``` ",1.0,"x/tools/go/loader: tests fail at tip - @griesemer, @alandonovan .... ``` bradfitz@dev-bradfitz:~/src/golang.org/x/tools$ go test -short ./go/loader cannot find package ""nosuchpkg"" in any of: /home/bradfitz/go/src/nosuchpkg (from $GOROOT) /home/bradfitz/src/nosuchpkg (from $GOPATH) cannot find package ""nosuchpkg"" in any of: /home/bradfitz/go/src/nosuchpkg (from $GOROOT) /home/bradfitz/src/nosuchpkg (from $GOPATH) open missing.go: no such file or directory open missing.go: no such file or directory testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF' testdata/badpkgdecl.go:1:34: expected 'package', found 'EOF' /go/src/b/x.go:1:21: could not import c (cannot find package ""c"" in any of: /go/src/c (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath')) /go/src/b/x.go:1:21: could not import c (cannot find package ""c"" in any of: /go/src/c (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath')) /go/src/b/x.go:1:21: could not import c (/go/src/c/x.go:1:8: expected 'IDENT', found 'EOF') /go/src/c/x.go:1:20: expected operand, found 'EOF' cannot find package ""two/three"" in any of: /go/src/two/three (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath') cannot find package ""http"" in any of: /go/src/http (from $GOROOT) ($GOPATH not set. For more details see: 'go help gopath') /go/src/c/x.go:1:31: cannot convert false (untyped bool constant) to int --- FAIL: ExampleConfig_CreateFromFilenames (0.70s) got: created: [container/heap] imported: [] initial: [container/heap] all: [container/heap errors internal/race math reflect runtime runtime/internal/atomic runtime/internal/sys sort strconv sync sync/atomic unicode/utf8 unsafe] want: created: [container/heap] imported: [] initial: [container/heap] all: [container/heap sort] FAIL FAIL golang.org/x/tools/go/loader 5.288s ``` ",0,x tools go loader tests fail at tip griesemer alandonovan bradfitz dev bradfitz src golang org x tools go test short go loader cannot find package nosuchpkg in any of home bradfitz go src nosuchpkg from goroot home bradfitz src nosuchpkg from gopath cannot find package nosuchpkg in any of home bradfitz go src nosuchpkg from goroot home bradfitz src nosuchpkg from gopath open missing go no such file or directory open missing go no such file or directory testdata badpkgdecl go expected package found eof testdata badpkgdecl go expected package found eof go src b x go could not import c cannot find package c in any of go src c from goroot gopath not set for more details see go help gopath go src b x go could not import c cannot find package c in any of go src c from goroot gopath not set for more details see go help gopath go src b x go could not import c go src c x go expected ident found eof go src c x go expected operand found eof cannot find package two three in any of go src two three from goroot gopath not set for more details see go help gopath cannot find package http in any of go src http from goroot gopath not set for more details see go help gopath go src c x go cannot convert false untyped bool constant to int fail exampleconfig createfromfilenames got created imported initial all want created imported initial all fail fail golang org x tools go loader ,0 77278,21719007710.0,IssuesEvent,2022-05-10 21:08:08,golang/go,https://api.github.com/repos/golang/go,closed,x/build/internal/gomote: `response code: 502` in TestWriteFileFromURL on darwin/amd64,OS-Darwin Builders NeedsInvestigation release-blocker,"``` 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-1 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-2 for example () 2022/05/02 15:53:59 created buildlet user-x-linux-amd64-0 for user-x () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () --- FAIL: TestWriteFileFromURL (19.91s) gomote_test.go:797: client.WriteFileFromURL(ctx, req) = response, rpc error: code = Aborted desc = unable to get file from URL: response code: 502; want no error 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () FAIL FAIL golang.org/x/build/internal/gomote 20.428s ``` `greplogs -l -e 'FAIL: TestWriteFileFromURL' --since=2022-01-01` [2022-05-02T21:34:37-477369d-99f1bf5/darwin-amd64-12_0](https://build.golang.org/log/7c89c07f4ca3434d13bf9eeccc35ea6eb56397de) [2022-05-02T21:05:53-477369d-a887579/darwin-amd64-12_0](https://build.golang.org/log/8940674471ddf87a89a98dfedaca417d17622c55) [2022-05-02T20:59:21-477369d-94274d0/darwin-amd64-10_15](https://build.golang.org/log/ede52e744df6ce6a904aa0b9441898a0f24eb0af) [2022-05-02T20:59:21-477369d-94274d0/darwin-amd64-11_0](https://build.golang.org/log/fcdff1193ec459d2cbe2b7585c8bad9e48e213d9)",1.0,"x/build/internal/gomote: `response code: 502` in TestWriteFileFromURL on darwin/amd64 - ``` 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-1 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-2 for example () 2022/05/02 15:53:59 created buildlet user-x-linux-amd64-0 for user-x () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:53:59 created buildlet example-linux-amd64-0 for example () --- FAIL: TestWriteFileFromURL (19.91s) gomote_test.go:797: client.WriteFileFromURL(ctx, req) = response, rpc error: code = Aborted desc = unable to get file from URL: response code: 502; want no error 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () 2022/05/02 15:54:19 created buildlet example-linux-amd64-0 for example () FAIL FAIL golang.org/x/build/internal/gomote 20.428s ``` `greplogs -l -e 'FAIL: TestWriteFileFromURL' --since=2022-01-01` [2022-05-02T21:34:37-477369d-99f1bf5/darwin-amd64-12_0](https://build.golang.org/log/7c89c07f4ca3434d13bf9eeccc35ea6eb56397de) [2022-05-02T21:05:53-477369d-a887579/darwin-amd64-12_0](https://build.golang.org/log/8940674471ddf87a89a98dfedaca417d17622c55) [2022-05-02T20:59:21-477369d-94274d0/darwin-amd64-10_15](https://build.golang.org/log/ede52e744df6ce6a904aa0b9441898a0f24eb0af) [2022-05-02T20:59:21-477369d-94274d0/darwin-amd64-11_0](https://build.golang.org/log/fcdff1193ec459d2cbe2b7585c8bad9e48e213d9)",0,x build internal gomote response code in testwritefilefromurl on darwin created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet user x linux for user x created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example fail testwritefilefromurl gomote test go client writefilefromurl ctx req response rpc error code aborted desc unable to get file from url response code want no error created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example created buildlet example linux for example fail fail golang org x build internal gomote greplogs l e fail testwritefilefromurl since ,0 24988,5115853271.0,IssuesEvent,2017-01-06 23:19:17,golang/go,https://api.github.com/repos/golang/go,closed,CONTRIBUTING.md doesn't describe proper procedure for proposals in issues,Documentation,"### What did you do? Make a proposal for golang ### What did you expect to see? [guidelines for contributing](https://github.com/golang/go/blob/master/CONTRIBUTING.md) telling me when using issues is a proper venue for discussing things (rather than ex. go-nuts@) While I'm not quite sure myself, some GitHub-centric people might not even be aware of especially the mailing-lists used for discussing all things Go.",1.0,"CONTRIBUTING.md doesn't describe proper procedure for proposals in issues - ### What did you do? Make a proposal for golang ### What did you expect to see? [guidelines for contributing](https://github.com/golang/go/blob/master/CONTRIBUTING.md) telling me when using issues is a proper venue for discussing things (rather than ex. go-nuts@) While I'm not quite sure myself, some GitHub-centric people might not even be aware of especially the mailing-lists used for discussing all things Go.",1,contributing md doesn t describe proper procedure for proposals in issues what did you do make a proposal for golang what did you expect to see telling me when using issues is a proper venue for discussing things rather than ex go nuts while i m not quite sure myself some github centric people might not even be aware of especially the mailing lists used for discussing all things go ,1 236595,18103063521.0,IssuesEvent,2021-09-22 16:03:46,golang/go,https://api.github.com/repos/golang/go,opened,declare a standard for packaging Go for downstream distributions,Documentation,"I have spent the last hour or so very confused, because it seemed like the system's Go 1.17.1 I installed via Arch was very different from the `go version devel go1.18-051df0d722` I installed from source recently. After much digging, I ended up realising that my 1.17.1 was missing all test files and testdata directories, and this seems to be [by design](https://github.com/archlinux/svntogit-community/blob/bd9adbc5205ca199dbe1bf25c6ab077a5bd33113/trunk/PKGBUILD#L81-L82). I [filed a bug](https://bugs.archlinux.org/task/72209) on the distro in question, and hopefully they'll reconsider. At the very least, they should support some way to install those missing files, because otherwise my install of Go is incomplete; `go test std` gives a weird error and then prints a lot of ""no test files"" warnings. Similarly, `go test all` is (silently) broken for third party modules importing std. I'm raising this issue because I'm very surprised that downstreams are installing partial GOROOTs and giving the impression that they are full and complete Go installs. As far as I am aware, the only way that Go is supported is when the GOROOT is used from a binary distribution, or from the result of `make.bash` without removing files. Unfortunately, it seems like different distributions have their own definitions of a Go install, with varying degrees of what files are included. Some distros which don't install a full GOROOT: * Arch Linux, as discussed above, removes `*_test.go` and `testdata` files. * Alpine does the same as Arch; [link](https://git.alpinelinux.org/aports/tree/community/go/APKBUILD?id=1f51a7d64cd9c142f67fec3fd122ab825a5dcc5d#n167) * Fedora appears to do the same as Arch; cannot find any test files in [link](https://fedora.pkgs.org/34/fedora-x86_64/golang-src-1.16-2.fc34.noarch.rpm.html) * Homebrew seems to delete a couple of testdata dirs; [link](https://github.com/Homebrew/homebrew-core/blob/4fcd38ceae0b6043289018fd32a9c324511fe6c1/Formula/go.rb#L60-L64) * Gentoo appears to delete all testdata dirs; [link](https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/go/go-1.17.1.ebuild?id=453fb1ade81143f177daf7465d3620a65d3dce71#n166) * Nix seems to disable many tests, though it doesn't seem to delete files; [link](https://github.com/NixOS/nixpkgs/blob/a930f7da84786807bb105df40e76b541604c3e72/pkgs/development/compilers/go/1.17.nix#L72-L177) Distros which appear to install an entire GOROOT: * Debian appears to include all test files; [link for 1.15 on stable](https://packages.debian.org/bullseye/amd64/golang-1.15-src/filelist) * Ubuntu seems to do the same as Debian; [link](https://packages.ubuntu.com/hirsute/amd64/golang-1.16-src/filelist) * FreeBSD seems to also include all files; [link](https://cgit.freebsd.org/ports/tree/lang/go/Makefile?id=c72a8f3160a3d158ee6d095a35f5fed843c5ecb4#n82) * Winget just uses a full binary install; [link](https://github.com/microsoft/winget-pkgs/blob/8fa1fc3860a989034debc9098e4b129340fd9380/manifests/g/GoLang/Go/1.17.1/GoLang.Go.installer.yaml#L16) It's also worth noting that some distros split ""bin"", ""src"", and ""doc"" packages. I think I don't have any argument against that, as long as the ""full"" or ""default"" install includes all of them. I understand that it's normal for downstreams to apply light patches to software while packaging. However, I feel like there's a bit of a disconnect happening here: if I install Go with my system's package manager, right now it appears to be a coin toss whether or not that `GOROOT` will be complete with test files and testdata directories. I imagine there might be other inconsistencies too, such as the `misc` or `doc` directories. I think it's worthwhile to consider whether we want to be in this situation in the long term. I would say not - it's pretty confusing to the end user. One way I can imagine we could improve the situation in the long term is for the Go project to define a base set of guidelines for packaging Go. For example, if we declare that it should include `GOROOT/src` without deleting test files, then a common source of variance between distributions would go away. It could also declare whether or not it's OK to omit directories like `misc`, `api`, or `doc`. If we go the route of defining a ""minimal Go install"" which excludes some files such as `*_test.go` and `testdata`, then I reckon that should be properly tested and supported too. Right now, the experience is somewhat poor, as `go test std` fails with `[amd64] FuncPCTestFn: function FuncPCTestFn missing Go declaration`. Another route to consider is to reduce the incentive for downstreams to strip files. As far as I have seen, there are two common recurring themes: * Some files are large. For example, Arch argues that removing test files and data reduces the package size by 100MiB. Perhaps we could try to reduce some of the testdata file sizes. * Some tests fail or are flaky. For example, Nix seems to disable or patch dozens of tests. Perhaps we should encourage them to file bugs about those.",1.0,"declare a standard for packaging Go for downstream distributions - I have spent the last hour or so very confused, because it seemed like the system's Go 1.17.1 I installed via Arch was very different from the `go version devel go1.18-051df0d722` I installed from source recently. After much digging, I ended up realising that my 1.17.1 was missing all test files and testdata directories, and this seems to be [by design](https://github.com/archlinux/svntogit-community/blob/bd9adbc5205ca199dbe1bf25c6ab077a5bd33113/trunk/PKGBUILD#L81-L82). I [filed a bug](https://bugs.archlinux.org/task/72209) on the distro in question, and hopefully they'll reconsider. At the very least, they should support some way to install those missing files, because otherwise my install of Go is incomplete; `go test std` gives a weird error and then prints a lot of ""no test files"" warnings. Similarly, `go test all` is (silently) broken for third party modules importing std. I'm raising this issue because I'm very surprised that downstreams are installing partial GOROOTs and giving the impression that they are full and complete Go installs. As far as I am aware, the only way that Go is supported is when the GOROOT is used from a binary distribution, or from the result of `make.bash` without removing files. Unfortunately, it seems like different distributions have their own definitions of a Go install, with varying degrees of what files are included. Some distros which don't install a full GOROOT: * Arch Linux, as discussed above, removes `*_test.go` and `testdata` files. * Alpine does the same as Arch; [link](https://git.alpinelinux.org/aports/tree/community/go/APKBUILD?id=1f51a7d64cd9c142f67fec3fd122ab825a5dcc5d#n167) * Fedora appears to do the same as Arch; cannot find any test files in [link](https://fedora.pkgs.org/34/fedora-x86_64/golang-src-1.16-2.fc34.noarch.rpm.html) * Homebrew seems to delete a couple of testdata dirs; [link](https://github.com/Homebrew/homebrew-core/blob/4fcd38ceae0b6043289018fd32a9c324511fe6c1/Formula/go.rb#L60-L64) * Gentoo appears to delete all testdata dirs; [link](https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/go/go-1.17.1.ebuild?id=453fb1ade81143f177daf7465d3620a65d3dce71#n166) * Nix seems to disable many tests, though it doesn't seem to delete files; [link](https://github.com/NixOS/nixpkgs/blob/a930f7da84786807bb105df40e76b541604c3e72/pkgs/development/compilers/go/1.17.nix#L72-L177) Distros which appear to install an entire GOROOT: * Debian appears to include all test files; [link for 1.15 on stable](https://packages.debian.org/bullseye/amd64/golang-1.15-src/filelist) * Ubuntu seems to do the same as Debian; [link](https://packages.ubuntu.com/hirsute/amd64/golang-1.16-src/filelist) * FreeBSD seems to also include all files; [link](https://cgit.freebsd.org/ports/tree/lang/go/Makefile?id=c72a8f3160a3d158ee6d095a35f5fed843c5ecb4#n82) * Winget just uses a full binary install; [link](https://github.com/microsoft/winget-pkgs/blob/8fa1fc3860a989034debc9098e4b129340fd9380/manifests/g/GoLang/Go/1.17.1/GoLang.Go.installer.yaml#L16) It's also worth noting that some distros split ""bin"", ""src"", and ""doc"" packages. I think I don't have any argument against that, as long as the ""full"" or ""default"" install includes all of them. I understand that it's normal for downstreams to apply light patches to software while packaging. However, I feel like there's a bit of a disconnect happening here: if I install Go with my system's package manager, right now it appears to be a coin toss whether or not that `GOROOT` will be complete with test files and testdata directories. I imagine there might be other inconsistencies too, such as the `misc` or `doc` directories. I think it's worthwhile to consider whether we want to be in this situation in the long term. I would say not - it's pretty confusing to the end user. One way I can imagine we could improve the situation in the long term is for the Go project to define a base set of guidelines for packaging Go. For example, if we declare that it should include `GOROOT/src` without deleting test files, then a common source of variance between distributions would go away. It could also declare whether or not it's OK to omit directories like `misc`, `api`, or `doc`. If we go the route of defining a ""minimal Go install"" which excludes some files such as `*_test.go` and `testdata`, then I reckon that should be properly tested and supported too. Right now, the experience is somewhat poor, as `go test std` fails with `[amd64] FuncPCTestFn: function FuncPCTestFn missing Go declaration`. Another route to consider is to reduce the incentive for downstreams to strip files. As far as I have seen, there are two common recurring themes: * Some files are large. For example, Arch argues that removing test files and data reduces the package size by 100MiB. Perhaps we could try to reduce some of the testdata file sizes. * Some tests fail or are flaky. For example, Nix seems to disable or patch dozens of tests. Perhaps we should encourage them to file bugs about those.",1,declare a standard for packaging go for downstream distributions i have spent the last hour or so very confused because it seemed like the system s go i installed via arch was very different from the go version devel i installed from source recently after much digging i ended up realising that my was missing all test files and testdata directories and this seems to be i on the distro in question and hopefully they ll reconsider at the very least they should support some way to install those missing files because otherwise my install of go is incomplete go test std gives a weird error and then prints a lot of no test files warnings similarly go test all is silently broken for third party modules importing std i m raising this issue because i m very surprised that downstreams are installing partial goroots and giving the impression that they are full and complete go installs as far as i am aware the only way that go is supported is when the goroot is used from a binary distribution or from the result of make bash without removing files unfortunately it seems like different distributions have their own definitions of a go install with varying degrees of what files are included some distros which don t install a full goroot arch linux as discussed above removes test go and testdata files alpine does the same as arch fedora appears to do the same as arch cannot find any test files in homebrew seems to delete a couple of testdata dirs gentoo appears to delete all testdata dirs nix seems to disable many tests though it doesn t seem to delete files distros which appear to install an entire goroot debian appears to include all test files ubuntu seems to do the same as debian freebsd seems to also include all files winget just uses a full binary install it s also worth noting that some distros split bin src and doc packages i think i don t have any argument against that as long as the full or default install includes all of them i understand that it s normal for downstreams to apply light patches to software while packaging however i feel like there s a bit of a disconnect happening here if i install go with my system s package manager right now it appears to be a coin toss whether or not that goroot will be complete with test files and testdata directories i imagine there might be other inconsistencies too such as the misc or doc directories i think it s worthwhile to consider whether we want to be in this situation in the long term i would say not it s pretty confusing to the end user one way i can imagine we could improve the situation in the long term is for the go project to define a base set of guidelines for packaging go for example if we declare that it should include goroot src without deleting test files then a common source of variance between distributions would go away it could also declare whether or not it s ok to omit directories like misc api or doc if we go the route of defining a minimal go install which excludes some files such as test go and testdata then i reckon that should be properly tested and supported too right now the experience is somewhat poor as go test std fails with funcpctestfn function funcpctestfn missing go declaration another route to consider is to reduce the incentive for downstreams to strip files as far as i have seen there are two common recurring themes some files are large for example arch argues that removing test files and data reduces the package size by perhaps we could try to reduce some of the testdata file sizes some tests fail or are flaky for example nix seems to disable or patch dozens of tests perhaps we should encourage them to file bugs about those ,1 42619,6993127620.0,IssuesEvent,2017-12-15 10:05:40,golang/go,https://api.github.com/repos/golang/go,closed,x/perf/cmd/benchstat: documentation missing information about -alpha option,Documentation,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.10beta1 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ppc64le Ubuntu ### What did you do? Tried to use benchstat for comparing benchmark results. Thought something was wrong on ppc64le because the delta column was always ~ even though I could see significant differences in the results columns. Tried to use benchstat -h and found -alpha which I assumed is that I needed: ``` -alpha a consider change significant if p < a (default 0.001) ``` From this it was not clear what p is, so I went here: https://godoc.org/golang.org/x/perf/cmd/benchstat but this documentation doesn't even mention alpha. So after trial and error I found an alpha value that would give me what I want. ",1.0,"x/perf/cmd/benchstat: documentation missing information about -alpha option - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.10beta1 ### Does this issue reproduce with the latest release? yes ### What operating system and processor architecture are you using (`go env`)? ppc64le Ubuntu ### What did you do? Tried to use benchstat for comparing benchmark results. Thought something was wrong on ppc64le because the delta column was always ~ even though I could see significant differences in the results columns. Tried to use benchstat -h and found -alpha which I assumed is that I needed: ``` -alpha a consider change significant if p < a (default 0.001) ``` From this it was not clear what p is, so I went here: https://godoc.org/golang.org/x/perf/cmd/benchstat but this documentation doesn't even mention alpha. So after trial and error I found an alpha value that would give me what I want. ",1,x perf cmd benchstat documentation missing information about alpha option please answer these questions before submitting your issue thanks what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env ubuntu what did you do tried to use benchstat for comparing benchmark results thought something was wrong on because the delta column was always even though i could see significant differences in the results columns tried to use benchstat h and found alpha which i assumed is that i needed alpha a consider change significant if p a default from this it was not clear what p is so i went here but this documentation doesn t even mention alpha so after trial and error i found an alpha value that would give me what i want ,1 50245,7574484424.0,IssuesEvent,2018-04-23 21:07:41,golang/go,https://api.github.com/repos/golang/go,closed,proposal: decide & document policy for giving out golang.org emails,Documentation Proposal,"We should decide on & document the policy for who gets golang.org email addresses. The community is curious. Empirically, the policy seems to be ""anybody who's ever been paid by Google either now or in the past"". But it's not obvious that's the correct policy. (if that's even accurate) /cc @andybons @namusyaka ",1.0,"proposal: decide & document policy for giving out golang.org emails - We should decide on & document the policy for who gets golang.org email addresses. The community is curious. Empirically, the policy seems to be ""anybody who's ever been paid by Google either now or in the past"". But it's not obvious that's the correct policy. (if that's even accurate) /cc @andybons @namusyaka ",1,proposal decide document policy for giving out golang org emails we should decide on document the policy for who gets golang org email addresses the community is curious empirically the policy seems to be anybody who s ever been paid by google either now or in the past but it s not obvious that s the correct policy if that s even accurate cc andybons namusyaka ,1 53297,7822208513.0,IssuesEvent,2018-06-14 01:02:08,golang/go,https://api.github.com/repos/golang/go,closed,cmd/vet: more clearly document go tool vet on a single file,Documentation,"#### What did you do? After upgrading from 1.9.4 to 1.10, I ran `go vet` against a single test file. ``` $ go vet vetissue_test.go ``` I have simplified the code that gave me the original issue and uploaded it [here](https://github.com/ooesili/vetissue). #### What did you expect to see? No output, and a successful exit code. This command succeeded on Go 1.9.4. #### What did you see instead? ``` $ go vet vetissue_test.go # command-line-arguments ./vetissue_test.go:6:6: undefined: value ``` What's happening here is that `go vet` is complaining about not being able to find the definition of an identifier that was declared in a different file in the same package. It looks like this change in behaviour was introduced in an effort to run `go vet` in parallel with `go test`, specifically in https://golang.org/cl/74355 which causes `go vet` to fail when the type check fails. I'm not really sure what the best course of action is here. My thought is that when running go vet against a single file, you can never be guaranteed to have all of the type information you need, so we could ignore type check failures in vet against single files. #### System details ``` go version go1.10 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/wmerkel/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/wmerkel/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.10/libexec"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/1.10/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/52/h8r09kdd5t17prlr9whr4cs4pm06q9/T/go-build420935568=/tmp/go-build -gno-record-gcc-switches -fno-common"" GOROOT/bin/go version: go version go1.10 darwin/amd64 GOROOT/bin/go tool compile -V: compile version go1.10 uname -v: Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.3 BuildVersion: 17D47 lldb --version: lldb-900.0.64 Swift-4.0 ```",1.0,"cmd/vet: more clearly document go tool vet on a single file - #### What did you do? After upgrading from 1.9.4 to 1.10, I ran `go vet` against a single test file. ``` $ go vet vetissue_test.go ``` I have simplified the code that gave me the original issue and uploaded it [here](https://github.com/ooesili/vetissue). #### What did you expect to see? No output, and a successful exit code. This command succeeded on Go 1.9.4. #### What did you see instead? ``` $ go vet vetissue_test.go # command-line-arguments ./vetissue_test.go:6:6: undefined: value ``` What's happening here is that `go vet` is complaining about not being able to find the definition of an identifier that was declared in a different file in the same package. It looks like this change in behaviour was introduced in an effort to run `go vet` in parallel with `go test`, specifically in https://golang.org/cl/74355 which causes `go vet` to fail when the type check fails. I'm not really sure what the best course of action is here. My thought is that when running go vet against a single file, you can never be guaranteed to have all of the type information you need, so we could ignore type check failures in vet against single files. #### System details ``` go version go1.10 darwin/amd64 GOARCH=""amd64"" GOBIN="""" GOCACHE=""/Users/wmerkel/Library/Caches/go-build"" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/wmerkel/go"" GORACE="""" GOROOT=""/usr/local/Cellar/go/1.10/libexec"" GOTMPDIR="""" GOTOOLDIR=""/usr/local/Cellar/go/1.10/libexec/pkg/tool/darwin_amd64"" GCCGO=""gccgo"" CC=""clang"" CXX=""clang++"" CGO_ENABLED=""1"" 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/52/h8r09kdd5t17prlr9whr4cs4pm06q9/T/go-build420935568=/tmp/go-build -gno-record-gcc-switches -fno-common"" GOROOT/bin/go version: go version go1.10 darwin/amd64 GOROOT/bin/go tool compile -V: compile version go1.10 uname -v: Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 ProductName: Mac OS X ProductVersion: 10.13.3 BuildVersion: 17D47 lldb --version: lldb-900.0.64 Swift-4.0 ```",1,cmd vet more clearly document go tool vet on a single file what did you do after upgrading from to i ran go vet against a single test file go vet vetissue test go i have simplified the code that gave me the original issue and uploaded it what did you expect to see no output and a successful exit code this command succeeded on go what did you see instead go vet vetissue test go command line arguments vetissue test go undefined value what s happening here is that go vet is complaining about not being able to find the definition of an identifier that was declared in a different file in the same package it looks like this change in behaviour was introduced in an effort to run go vet in parallel with go test specifically in which causes go vet to fail when the type check fails i m not really sure what the best course of action is here my thought is that when running go vet against a single file you can never be guaranteed to have all of the type information you need so we could ignore type check failures in vet against single files system details go version darwin goarch gobin gocache users wmerkel library caches go build goexe gohostarch gohostos darwin goos darwin gopath users wmerkel go gorace goroot usr local cellar go libexec gotmpdir gotooldir usr local cellar go libexec pkg tool darwin gccgo gccgo cc clang cxx clang cgo enabled cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders t go tmp go build gno record gcc switches fno common goroot bin go version go version darwin goroot bin go tool compile v compile version uname v darwin kernel version sun dec pst root xnu release productname mac os x productversion buildversion lldb version lldb swift ,1 85742,10458255295.0,IssuesEvent,2019-09-20 08:07:36,golang/go,https://api.github.com/repos/golang/go,closed,"doc: Effective Go doc misuses word ""anew"", resulting in confusing usage rule",Documentation,"In Effective Go, in the section on ""Redeclaration and reassignment,"" it says that an existing variable may appear in a short declaration if ""there is at least one other variable in the declaration that is being declared anew."" Doesn't it really mean being declared for the first time? That's not what ""anew"" means; if anything, it means ""again.""",1.0,"doc: Effective Go doc misuses word ""anew"", resulting in confusing usage rule - In Effective Go, in the section on ""Redeclaration and reassignment,"" it says that an existing variable may appear in a short declaration if ""there is at least one other variable in the declaration that is being declared anew."" Doesn't it really mean being declared for the first time? That's not what ""anew"" means; if anything, it means ""again.""",1,doc effective go doc misuses word anew resulting in confusing usage rule in effective go in the section on redeclaration and reassignment it says that an existing variable may appear in a short declaration if there is at least one other variable in the declaration that is being declared anew doesn t it really mean being declared for the first time that s not what anew means if anything it means again ,1 100274,30664048053.0,IssuesEvent,2023-07-25 16:54:23,golang/go,https://api.github.com/repos/golang/go,closed,x/build/env/wasip1-wasm-wazero: wasip1 tests are failing,Builders WaitingForInfo NeedsFix arch-wasm,"``` #!watchflakes post <- pkg == ""test"" && test == ""Test"" && date >= ""2023-07-14"" && builder ~ `wazero` && `tmp__.go:\d+:\d+: syntax error:` ``` After enabling nonblocking io on stdin, stdout and stderr in [CL 498196](https://go-review.googlesource.com/c/go/+/498196), the wazero wasip1 runner started to fail. The errors look like this: ``` ##### ../test --- FAIL: Test (0.07s) --- FAIL: Test/fixedbugs/bug449.go (0.94s) testdir_test.go:141: exit status 1 # command-line-arguments ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3072:6: syntax error: unexpected package, expected name ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3866:53: syntax error: unexpected main at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3870:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:4660:53: syntax error: unexpected main at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:4664:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6214:13: syntax error: unexpected package, expected expression ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6216:1: syntax error: unexpected var at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6218:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:9285:6: syntax error: unexpected package, expected name ``` [Sample error log](https://build.golang.org/log/18d1ec37439d82ecb1447ad011e75c0731725294). The link to the standard I/O change seems pretty clear, but the cause is likely a runtime bug. [An issue](https://github.com/tetratelabs/wazero/issues/1538) has been filed with the wazero runtime project. The fix will likely be an update to the wazero version used in the builders. The wasmtime runner continues to pass all tests as expected.",1.0,"x/build/env/wasip1-wasm-wazero: wasip1 tests are failing - ``` #!watchflakes post <- pkg == ""test"" && test == ""Test"" && date >= ""2023-07-14"" && builder ~ `wazero` && `tmp__.go:\d+:\d+: syntax error:` ``` After enabling nonblocking io on stdin, stdout and stderr in [CL 498196](https://go-review.googlesource.com/c/go/+/498196), the wazero wasip1 runner started to fail. The errors look like this: ``` ##### ../test --- FAIL: Test (0.07s) --- FAIL: Test/fixedbugs/bug449.go (0.94s) testdir_test.go:141: exit status 1 # command-line-arguments ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3072:6: syntax error: unexpected package, expected name ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3866:53: syntax error: unexpected main at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:3870:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:4660:53: syntax error: unexpected main at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:4664:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6214:13: syntax error: unexpected package, expected expression ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6216:1: syntax error: unexpected var at end of statement ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:6218:6: syntax error: unexpected call, expected ( ../../tmp/Testfixedbugsbug449.go4132839843/001/tmp__.go:9285:6: syntax error: unexpected package, expected name ``` [Sample error log](https://build.golang.org/log/18d1ec37439d82ecb1447ad011e75c0731725294). The link to the standard I/O change seems pretty clear, but the cause is likely a runtime bug. [An issue](https://github.com/tetratelabs/wazero/issues/1538) has been filed with the wazero runtime project. The fix will likely be an update to the wazero version used in the builders. The wasmtime runner continues to pass all tests as expected.",0,x build env wasm wazero tests are failing watchflakes post builder wazero tmp go d d syntax error after enabling nonblocking io on stdin stdout and stderr in the wazero runner started to fail the errors look like this test fail test fail test fixedbugs go testdir test go exit status command line arguments tmp tmp go syntax error unexpected package expected name tmp tmp go syntax error unexpected main at end of statement tmp tmp go syntax error unexpected call expected tmp tmp go syntax error unexpected main at end of statement tmp tmp go syntax error unexpected call expected tmp tmp go syntax error unexpected package expected expression tmp tmp go syntax error unexpected var at end of statement tmp tmp go syntax error unexpected call expected tmp tmp go syntax error unexpected package expected name the link to the standard i o change seems pretty clear but the cause is likely a runtime bug has been filed with the wazero runtime project the fix will likely be an update to the wazero version used in the builders the wasmtime runner continues to pass all tests as expected ,0 25178,5142238813.0,IssuesEvent,2017-01-12 12:37:58,golang/go,https://api.github.com/repos/golang/go,opened,cmd/go: go bug help message is outdated,Documentation NeedsFix,"``` $ gotip version go version devel +39e31d5ec0 Thu Jan 12 04:50:46 2017 +0000 linux/amd64 ``` Change 896ac677b5e3e80278cc1ce179d8a077ac3a6d2f modified the `bug` subcommand to make it open the system browser and pre-fill an issue template (instead of just dumping the infos to the screen), but the subcommand help string was not updated accordingly. It is certainly unexpected that a command that is currently documented as such: ``` $ gotip bug -h usage: bug Bug prints information that helps file effective bug reports. Bugs may be reported at https://golang.org/issue/new. ``` opens my browser and uses it to display a pre-filled github page.",1.0,"cmd/go: go bug help message is outdated - ``` $ gotip version go version devel +39e31d5ec0 Thu Jan 12 04:50:46 2017 +0000 linux/amd64 ``` Change 896ac677b5e3e80278cc1ce179d8a077ac3a6d2f modified the `bug` subcommand to make it open the system browser and pre-fill an issue template (instead of just dumping the infos to the screen), but the subcommand help string was not updated accordingly. It is certainly unexpected that a command that is currently documented as such: ``` $ gotip bug -h usage: bug Bug prints information that helps file effective bug reports. Bugs may be reported at https://golang.org/issue/new. ``` opens my browser and uses it to display a pre-filled github page.",1,cmd go go bug help message is outdated gotip version go version devel thu jan linux change modified the bug subcommand to make it open the system browser and pre fill an issue template instead of just dumping the infos to the screen but the subcommand help string was not updated accordingly it is certainly unexpected that a command that is currently documented as such gotip bug h usage bug bug prints information that helps file effective bug reports bugs may be reported at opens my browser and uses it to display a pre filled github page ,1 338108,24571806268.0,IssuesEvent,2022-10-13 09:13:28,golang/go,https://api.github.com/repos/golang/go,closed,x/website: documentation no longer suggests to add $GOPATH/bin to the user's PATH,Documentation NeedsFix website," ### Does this issue reproduce with the latest release? Yes ### ### What did you do? I went to the installation page. ### What did you expect to see? That adding `$HOME/go/bin` to your path was necessary to make `go install` function as expected. ### What did you see instead? A lot of bug reports on my project that they can't run the project binary after installing. ",1.0,"x/website: documentation no longer suggests to add $GOPATH/bin to the user's PATH - ### Does this issue reproduce with the latest release? Yes ### ### What did you do? I went to the installation page. ### What did you expect to see? That adding `$HOME/go/bin` to your path was necessary to make `go install` function as expected. ### What did you see instead? A lot of bug reports on my project that they can't run the project binary after installing. ",1,x website documentation no longer suggests to add gopath bin to the user s path does this issue reproduce with the latest release yes what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best i went to the installation page what did you expect to see that adding home go bin to your path was necessary to make go install function as expected what did you see instead a lot of bug reports on my project that they can t run the project binary after installing ,1 184944,14291068603.0,IssuesEvent,2020-11-23 21:59:46,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/gopls: move circular dependency tests to regression tests,Testing Tools gopls,"These have always been finicky, and there are some special cases just for those tests. I think they would work better as regression tests.",1.0,"x/tools/gopls: move circular dependency tests to regression tests - These have always been finicky, and there are some special cases just for those tests. I think they would work better as regression tests.",0,x tools gopls move circular dependency tests to regression tests these have always been finicky and there are some special cases just for those tests i think they would work better as regression tests ,0 176411,14581262968.0,IssuesEvent,2020-12-18 10:27:08,golang/go,https://api.github.com/repos/golang/go,closed,x/website: Mention specifically that minor version is not allowed in Go directives,Documentation NeedsDecision,"I was trying out `Go` modules and find out that If I specify `1.15.4` instead of `1.15` my build failed with the following error: ``` invalid go version '1.15.4': must match format 1.23 ``` I referred to this documentation https://golang.org/ref/mod#go-mod-file-go. I think it will be better If we also recommend not to use the minor version or give examples of the wrong values for better understanding. ",1.0,"x/website: Mention specifically that minor version is not allowed in Go directives - I was trying out `Go` modules and find out that If I specify `1.15.4` instead of `1.15` my build failed with the following error: ``` invalid go version '1.15.4': must match format 1.23 ``` I referred to this documentation https://golang.org/ref/mod#go-mod-file-go. I think it will be better If we also recommend not to use the minor version or give examples of the wrong values for better understanding. ",1,x website mention specifically that minor version is not allowed in go directives i was trying out go modules and find out that if i specify instead of my build failed with the following error invalid go version must match format i referred to this documentation i think it will be better if we also recommend not to use the minor version or give examples of the wrong values for better understanding ,1 213574,16527619053.0,IssuesEvent,2021-05-26 22:42:08,golang/go,https://api.github.com/repos/golang/go,closed,doc/go1.17: document mime changes for Go 1.17,Documentation NeedsInvestigation help wanted release-blocker,"As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
mime

TODO: https://golang.org/cl/305230: support reading shared mime-info database on unix systems

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46013."" in the body.",1.0,"doc/go1.17: document mime changes for Go 1.17 - As of filing this issue, the [Go 1.17 draft release notes](https://tip.golang.org/doc/go1.17) contained the following HTML:
mime

TODO: https://golang.org/cl/305230: support reading shared mime-info database on unix systems

--- This TODO needs to be resolved by July 1 so that we can have complete release notes for [Beta 1](https://golang.org/s/release#june-1--december-1-beta-1-issued). A sequence of steps to resolve this issue may be: 1. Come up with a draft release note entry in this issue, then move the issue to NeedsFix state. 2. Send a CL with ""doc/go1.17:"" [prefix](https://go-review.googlesource.com/q/project:go+doc/go1.17) and include ""For #44513. Fixes #46013."" in the body.",1,doc document mime changes for go as of filing this issue the contained the following html mime todo a href support reading shared mime info database on unix systems this todo needs to be resolved by july so that we can have complete release notes for a sequence of steps to resolve this issue may be come up with a draft release note entry in this issue then move the issue to needsfix state send a cl with doc and include for fixes in the body ,1 333940,24397567520.0,IssuesEvent,2022-10-04 20:48:14,golang/go,https://api.github.com/repos/golang/go,opened,os: document concurrency properties for File methods,ExpertNeeded Documentation NeedsInvestigation,"### What version of Go are you using (`go version`)? https://pkg.go.dev/os@go1.19.1 ### Does this issue reproduce with the latest release? Yes. ### What did you do? For #50436, I'm attempting to unblock reads on a `*File` returned by `os.Pipe` while it is being read concurrently by a user-controlled goroutine. The user-controlled goroutine may legitimately call the `Close` method, and may expect to be able to access other methods (such as `SetDeadline`) via type-assertion. ### What did you expect to see? Given #6270, #7970, #9307, #17647 and https://go.dev/cl/65490, I expected the documentation for `*os.File to describe which methods are safe to invoke concurrently and under what conditions. ### What did you see instead? The only mention of concurrency I could find in https://pkg.go.dev/os@go1.19.1 says this: > Note: The maximum number of concurrent operations on a File may be limited by the OS or the system. The number should be high, but exceeding it may degrade performance or cause other issues. That seems to imply that at least some of the `File` methods may be invoked concurrently, but isn't explicit about which ones. I see unsynchronized writes in the `Close` implementation on both [`unix`](https://cs.opensource.google/go/go/+/master:src/os/file_unix.go;l=259;drc=6d8ec893039a39f495c8139012e47754e4518b70) and [`plan9`](https://cs.opensource.google/go/go/+/master:src/os/file_plan9.go;l=159;drc=81431c7aa7c5d782e72dec342442ea7664ef1783) (but maybe not `windows`?); it's not obvious to me which other methods are or aren't safe. (CC @rsc @ianlancetaylor @robpike from previous `*File` race issues.)",1.0,"os: document concurrency properties for File methods - ### What version of Go are you using (`go version`)? https://pkg.go.dev/os@go1.19.1 ### Does this issue reproduce with the latest release? Yes. ### What did you do? For #50436, I'm attempting to unblock reads on a `*File` returned by `os.Pipe` while it is being read concurrently by a user-controlled goroutine. The user-controlled goroutine may legitimately call the `Close` method, and may expect to be able to access other methods (such as `SetDeadline`) via type-assertion. ### What did you expect to see? Given #6270, #7970, #9307, #17647 and https://go.dev/cl/65490, I expected the documentation for `*os.File to describe which methods are safe to invoke concurrently and under what conditions. ### What did you see instead? The only mention of concurrency I could find in https://pkg.go.dev/os@go1.19.1 says this: > Note: The maximum number of concurrent operations on a File may be limited by the OS or the system. The number should be high, but exceeding it may degrade performance or cause other issues. That seems to imply that at least some of the `File` methods may be invoked concurrently, but isn't explicit about which ones. I see unsynchronized writes in the `Close` implementation on both [`unix`](https://cs.opensource.google/go/go/+/master:src/os/file_unix.go;l=259;drc=6d8ec893039a39f495c8139012e47754e4518b70) and [`plan9`](https://cs.opensource.google/go/go/+/master:src/os/file_plan9.go;l=159;drc=81431c7aa7c5d782e72dec342442ea7664ef1783) (but maybe not `windows`?); it's not obvious to me which other methods are or aren't safe. (CC @rsc @ianlancetaylor @robpike from previous `*File` race issues.)",1,os document concurrency properties for file methods what version of go are you using go version does this issue reproduce with the latest release yes what did you do for i m attempting to unblock reads on a file returned by os pipe while it is being read concurrently by a user controlled goroutine the user controlled goroutine may legitimately call the close method and may expect to be able to access other methods such as setdeadline via type assertion what did you expect to see given and i expected the documentation for os file to describe which methods are safe to invoke concurrently and under what conditions what did you see instead the only mention of concurrency i could find in says this note the maximum number of concurrent operations on a file may be limited by the os or the system the number should be high but exceeding it may degrade performance or cause other issues that seems to imply that at least some of the file methods may be invoked concurrently but isn t explicit about which ones i see unsynchronized writes in the close implementation on both and but maybe not windows it s not obvious to me which other methods are or aren t safe cc rsc ianlancetaylor robpike from previous file race issues ,1 319609,23781180211.0,IssuesEvent,2022-09-02 05:06:36,golang/go,https://api.github.com/repos/golang/go,closed,math/rand: document whether NewSource always implements Source64,Documentation NeedsInvestigation,"The [concrete type returned by `NewSource` happens to implement `Source64`](https://play.golang.org/p/gxPB1je9grf). However, this is not documented in any way. Is this always guaranteed?",1.0,"math/rand: document whether NewSource always implements Source64 - The [concrete type returned by `NewSource` happens to implement `Source64`](https://play.golang.org/p/gxPB1je9grf). However, this is not documented in any way. Is this always guaranteed?",1,math rand document whether newsource always implements the however this is not documented in any way is this always guaranteed ,1 14346,3829564672.0,IssuesEvent,2016-03-31 11:16:00,golang/go,https://api.github.com/repos/golang/go,closed,net/http: docs show insufficient way to cleanup Response Body,Documentation,"
What does 'go version' print?

go version go1.4rc1 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. View the docs at http://tip.golang.org/pkg/net/http/

What happened?

Docs show the following method for cleaning up response bodies:

resp, err := http.Get("http://example.com/";)
if err != nil {
	// handle error
}
defer resp.Body.Close()

What should have happened instead?

The method shown above does not handle the case where both resp and err are non-nil,
which was preserved for compatibility reasons in #3795. If the response was a redirect
and the CheckRedirect func returned an error, the http.Client will return both the
Response and an error. That response's Body would never be closed under the example
shown above, and its connection would leak.

Unfortunately, I suspect this compatibility fix has probably led to lots of potential
leaks in Go code in the wild. Since breaking Go 1 compatibility is not an option, the
docs for Go 1 should show people how to correctly clean up after responses without
leaking conns & file descriptors.

Instead, the following should work and would not leak:

resp, err := http.Get("http://example.com/";)
if resp != nil {
	defer resp.Body.Close()
}
if err != nil {
	// handle error
}

Please provide any additional information below.
",1.0,"net/http: docs show insufficient way to cleanup Response Body - 
What does 'go version' print?

go version go1.4rc1 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. View the docs at http://tip.golang.org/pkg/net/http/

What happened?

Docs show the following method for cleaning up response bodies:

resp, err := http.Get("http://example.com/";)
if err != nil {
	// handle error
}
defer resp.Body.Close()

What should have happened instead?

The method shown above does not handle the case where both resp and err are non-nil,
which was preserved for compatibility reasons in #3795. If the response was a redirect
and the CheckRedirect func returned an error, the http.Client will return both the
Response and an error. That response's Body would never be closed under the example
shown above, and its connection would leak.

Unfortunately, I suspect this compatibility fix has probably led to lots of potential
leaks in Go code in the wild. Since breaking Go 1 compatibility is not an option, the
docs for Go 1 should show people how to correctly clean up after responses without
leaking conns & file descriptors.

Instead, the following should work and would not leak:

resp, err := http.Get("http://example.com/";)
if resp != nil {
	defer resp.Body.Close()
}
if err != nil {
	// handle error
}

Please provide any additional information below.
",1,net http docs show insufficient way to cleanup response body what does go version print go version darwin what steps reproduce the problem if possible include a link to a program on play golang org view the docs at a href what happened docs show the following method for cleaning up response bodies resp err http get quot a href if err nil handle error defer resp body close what should have happened instead the method shown above does not handle the case where both resp and err are non nil which was preserved for compatibility reasons in if the response was a redirect and the checkredirect func returned an error the http client will return both the response and an error that response s body would never be closed under the example shown above and its connection would leak unfortunately i suspect this compatibility fix has probably led to lots of potential leaks in go code in the wild since breaking go compatibility is not an option the docs for go should show people how to correctly clean up after responses without leaking conns amp file descriptors instead the following should work and would not leak resp err http get quot a href if resp nil defer resp body close if err nil handle error please provide any additional information below ,1 3754,4028538609.0,IssuesEvent,2016-05-18 06:55:25,golang/go,https://api.github.com/repos/golang/go,closed,compress/flate: Add optimizations and re+balance.,Performance,"We should merge optimizations added to https://github.com/klauspost/compress Typical speedup is around 1.7x for web content, when maintaining roughly the same compression. With [re-balanced compression settings](https://github.com/klauspost/compress/pull/31), the default level will be 3.1x faster at a 7% compression loss. Mixed content (disk images) show a 3.1x speedup with a 3% compression loss. Extensive benchmarks in this [google spreadsheet](https://docs.google.com/spreadsheets/d/1nuNE2nPfuINCZJRMt6wFWhKpToF95I47XjSsc-1rbPQ/edit?usp=sharing).",True,"compress/flate: Add optimizations and re+balance. - We should merge optimizations added to https://github.com/klauspost/compress Typical speedup is around 1.7x for web content, when maintaining roughly the same compression. With [re-balanced compression settings](https://github.com/klauspost/compress/pull/31), the default level will be 3.1x faster at a 7% compression loss. Mixed content (disk images) show a 3.1x speedup with a 3% compression loss. Extensive benchmarks in this [google spreadsheet](https://docs.google.com/spreadsheets/d/1nuNE2nPfuINCZJRMt6wFWhKpToF95I47XjSsc-1rbPQ/edit?usp=sharing).",0,compress flate add optimizations and re balance we should merge optimizations added to typical speedup is around for web content when maintaining roughly the same compression with the default level will be faster at a compression loss mixed content disk images show a speedup with a compression loss extensive benchmarks in this ,0 75249,20740350934.0,IssuesEvent,2022-03-14 17:06:23,golang/go,https://api.github.com/repos/golang/go,closed,x/build: the linux-s390x-ibm builders will be unavailable due to maintenance,Builders,"The linux-s390x-ibm builders will be unavailable due to data center maintenance. The planned outage will start on Friday, March 11th, 5PM ET and servers will be brought back up automatically by 11:59 PM ET Sunday, March 13th. The builders should startup automatically once the servers are restarted. /cc @golang/release",1.0,"x/build: the linux-s390x-ibm builders will be unavailable due to maintenance - The linux-s390x-ibm builders will be unavailable due to data center maintenance. The planned outage will start on Friday, March 11th, 5PM ET and servers will be brought back up automatically by 11:59 PM ET Sunday, March 13th. The builders should startup automatically once the servers are restarted. /cc @golang/release",0,x build the linux ibm builders will be unavailable due to maintenance the linux ibm builders will be unavailable due to data center maintenance the planned outage will start on friday march et and servers will be brought back up automatically by pm et sunday march the builders should startup automatically once the servers are restarted cc golang release,0 11046,3454732978.0,IssuesEvent,2015-12-17 17:03:23,golang/go,https://api.github.com/repos/golang/go,closed,net/http: ServeMux unexpectedly redirecting to add trailing slash,Documentation,"`http.ServeMux` unexpectedly redirects to add a trailing slash if there is a route that matches with a trailing slash. Given the following `ServeMux`, I expect that a request for `/a` would match the path rooted as `/`. ```go http.HandleFunc(""/"", ...) http.HandleFunc(""/a/"", ...) ``` Instead, a 301 redirect is returned redirecting to `/a/` (see http://play.golang.org/p/65Skm2I5hq). The docs describe redirects as happening in path sanitization cases (ie: requests with `.` or `..` elements), but no mention of transparently adding slashes. The docs also describe the match as a `""rooted subtree""` so it's also unexpected that a pattern for `/a/` would affect requests that don't have that prefix (ie: w/o the trailing slash). In researching if this situation was reported before, I found a mailing list from 2010 implying this [was expected](https://groups.google.com/d/msg/golang-nuts/P-uq-cN4tjA/Mw9Ns2no35gJ) as well as a [code comment](http://golang.org/src/net/http/server.go#L1566). If that is still the case, then i think the docs should reflect that. (though i personally consider this a bug, i could understand that for some this could be a feature). ",1.0,"net/http: ServeMux unexpectedly redirecting to add trailing slash - `http.ServeMux` unexpectedly redirects to add a trailing slash if there is a route that matches with a trailing slash. Given the following `ServeMux`, I expect that a request for `/a` would match the path rooted as `/`. ```go http.HandleFunc(""/"", ...) http.HandleFunc(""/a/"", ...) ``` Instead, a 301 redirect is returned redirecting to `/a/` (see http://play.golang.org/p/65Skm2I5hq). The docs describe redirects as happening in path sanitization cases (ie: requests with `.` or `..` elements), but no mention of transparently adding slashes. The docs also describe the match as a `""rooted subtree""` so it's also unexpected that a pattern for `/a/` would affect requests that don't have that prefix (ie: w/o the trailing slash). In researching if this situation was reported before, I found a mailing list from 2010 implying this [was expected](https://groups.google.com/d/msg/golang-nuts/P-uq-cN4tjA/Mw9Ns2no35gJ) as well as a [code comment](http://golang.org/src/net/http/server.go#L1566). If that is still the case, then i think the docs should reflect that. (though i personally consider this a bug, i could understand that for some this could be a feature). ",1,net http servemux unexpectedly redirecting to add trailing slash http servemux unexpectedly redirects to add a trailing slash if there is a route that matches with a trailing slash given the following servemux i expect that a request for a would match the path rooted as go http handlefunc http handlefunc a instead a redirect is returned redirecting to a see the docs describe redirects as happening in path sanitization cases ie requests with or elements but no mention of transparently adding slashes the docs also describe the match as a rooted subtree so it s also unexpected that a pattern for a would affect requests that don t have that prefix ie w o the trailing slash in researching if this situation was reported before i found a mailing list from implying this as well as a if that is still the case then i think the docs should reflect that though i personally consider this a bug i could understand that for some this could be a feature ,1 143515,11568324951.0,IssuesEvent,2020-02-20 15:42:29,golang/go,https://api.github.com/repos/golang/go,opened,"net: TestDialCancel failure on linux-arm with ""network is unreachable""",NeedsInvestigation Testing,"In the fix for #15191, we skipped the test in case of a `connection refused` error. It looks like we may need to widen that to `network is unreachable` as well. ``` --- FAIL: TestDialCancel (0.00s) dial_test.go:820: dial error after 0 ticks (5 before cancel sent): dial tcp 198.18.0.254:1234: connect: network is unreachable FAIL FAIL net 27.044s ``` CC @ianlancetaylor @bradfitz [2020-02-19T20:40:29-2200b4f/linux-arm](https://build.golang.org/log/5523485f69960aa5dbec0ff4339f12cdd3b7fac4) [2020-01-23T21:01:12-ace25f8/linux-arm](https://build.golang.org/log/f4257efbd7a18e595d454c249d7a7894796b1cec) [2020-01-09T17:52:05-cec535b/linux-arm](https://build.golang.org/log/1c214d88ce74268ce8536f43b34342dafc3d1a6a) [2020-01-06T15:47:02-72f92de/linux-arm](https://build.golang.org/log/4b30aec77df3712ced1ab66ff6dfe8ec785d5d58) [2020-01-06T02:46:02-c6e8426/linux-arm](https://build.golang.org/log/aa738d6e0152d7541ffa81bcc862e9690af70174) [2019-11-18T18:14:37-f9dd99c/linux-arm](https://build.golang.org/log/0f5f4da21697db5280324ade62f3aa71155b95d3) [2019-10-30T08:17:29-f4e32ae/linux-arm](https://build.golang.org/log/019db9d64edc807077516ba20399da59bd7a949e) [2019-10-24T08:47:14-722b0e3/linux-arm](https://build.golang.org/log/7f8f96b8caaa1ad5f1f3b75f9cbc97cfde3b3c9b) [2019-10-23T18:41:38-7833302/linux-arm](https://build.golang.org/log/0a75fed0ef5bd75781360367b291954e19023408) [2019-10-11T17:03:37-df38069/linux-arm](https://build.golang.org/log/648f8fd836a73fc2f6f428772c21b9f5cda5ff31) [2019-09-25T04:18:18-7fc2625/linux-arm](https://build.golang.org/log/29ecd5fb9d6853a2370163d0d81c265a86343e70) [2019-09-06T20:05:29-5e43856/linux-arm](https://build.golang.org/log/424f85c190683239a5316a7c8915d39fb1dfcb03) [2019-09-01T02:31:50-d15dfdc/linux-arm](https://build.golang.org/log/806bf66f3ac7ce31e8a6f521e619d48485c65b97) [2019-08-02T17:51:34-2d1a1e0/linux-arm](https://build.golang.org/log/ed29640b1bf14bb32bc5c0f6be599c4da0c35ad9) [2019-06-19T07:09:13-18107ed/linux-arm](https://build.golang.org/log/7460cac43be8414f1f3766051dcc583aa7cbfb8f) [2019-06-14T19:37:52-f18aeb3/linux-arm](https://build.golang.org/log/962376bdb46f230de6dcae325f88b618745c3e7c) [2019-05-16T03:25:01-dccd5da/linux-arm](https://build.golang.org/log/acf3bbe6a1634db0fd3d45b1bfd7bef643b28a94) [2019-05-02T20:30:31-0a338f7/linux-arm](https://build.golang.org/log/d3a3d225d1bb468f5dddf76188b472d7036e3a2e) [2019-04-30T20:26:36-85387aa/linux-arm](https://build.golang.org/log/68ce4257c9e3a9bf6e2e01e41ec0e8e8897a5f9e) [2019-04-30T17:45:16-1fd1408/linux-arm](https://build.golang.org/log/f48f27568ebadd29cddb93e5d0f88e5ed91b0851) [2019-04-27T17:15:55-17a7f21/linux-arm](https://build.golang.org/log/1f0d8614f07980f3cca697a6de720f3b05266d9e) ",1.0,"net: TestDialCancel failure on linux-arm with ""network is unreachable"" - In the fix for #15191, we skipped the test in case of a `connection refused` error. It looks like we may need to widen that to `network is unreachable` as well. ``` --- FAIL: TestDialCancel (0.00s) dial_test.go:820: dial error after 0 ticks (5 before cancel sent): dial tcp 198.18.0.254:1234: connect: network is unreachable FAIL FAIL net 27.044s ``` CC @ianlancetaylor @bradfitz [2020-02-19T20:40:29-2200b4f/linux-arm](https://build.golang.org/log/5523485f69960aa5dbec0ff4339f12cdd3b7fac4) [2020-01-23T21:01:12-ace25f8/linux-arm](https://build.golang.org/log/f4257efbd7a18e595d454c249d7a7894796b1cec) [2020-01-09T17:52:05-cec535b/linux-arm](https://build.golang.org/log/1c214d88ce74268ce8536f43b34342dafc3d1a6a) [2020-01-06T15:47:02-72f92de/linux-arm](https://build.golang.org/log/4b30aec77df3712ced1ab66ff6dfe8ec785d5d58) [2020-01-06T02:46:02-c6e8426/linux-arm](https://build.golang.org/log/aa738d6e0152d7541ffa81bcc862e9690af70174) [2019-11-18T18:14:37-f9dd99c/linux-arm](https://build.golang.org/log/0f5f4da21697db5280324ade62f3aa71155b95d3) [2019-10-30T08:17:29-f4e32ae/linux-arm](https://build.golang.org/log/019db9d64edc807077516ba20399da59bd7a949e) [2019-10-24T08:47:14-722b0e3/linux-arm](https://build.golang.org/log/7f8f96b8caaa1ad5f1f3b75f9cbc97cfde3b3c9b) [2019-10-23T18:41:38-7833302/linux-arm](https://build.golang.org/log/0a75fed0ef5bd75781360367b291954e19023408) [2019-10-11T17:03:37-df38069/linux-arm](https://build.golang.org/log/648f8fd836a73fc2f6f428772c21b9f5cda5ff31) [2019-09-25T04:18:18-7fc2625/linux-arm](https://build.golang.org/log/29ecd5fb9d6853a2370163d0d81c265a86343e70) [2019-09-06T20:05:29-5e43856/linux-arm](https://build.golang.org/log/424f85c190683239a5316a7c8915d39fb1dfcb03) [2019-09-01T02:31:50-d15dfdc/linux-arm](https://build.golang.org/log/806bf66f3ac7ce31e8a6f521e619d48485c65b97) [2019-08-02T17:51:34-2d1a1e0/linux-arm](https://build.golang.org/log/ed29640b1bf14bb32bc5c0f6be599c4da0c35ad9) [2019-06-19T07:09:13-18107ed/linux-arm](https://build.golang.org/log/7460cac43be8414f1f3766051dcc583aa7cbfb8f) [2019-06-14T19:37:52-f18aeb3/linux-arm](https://build.golang.org/log/962376bdb46f230de6dcae325f88b618745c3e7c) [2019-05-16T03:25:01-dccd5da/linux-arm](https://build.golang.org/log/acf3bbe6a1634db0fd3d45b1bfd7bef643b28a94) [2019-05-02T20:30:31-0a338f7/linux-arm](https://build.golang.org/log/d3a3d225d1bb468f5dddf76188b472d7036e3a2e) [2019-04-30T20:26:36-85387aa/linux-arm](https://build.golang.org/log/68ce4257c9e3a9bf6e2e01e41ec0e8e8897a5f9e) [2019-04-30T17:45:16-1fd1408/linux-arm](https://build.golang.org/log/f48f27568ebadd29cddb93e5d0f88e5ed91b0851) [2019-04-27T17:15:55-17a7f21/linux-arm](https://build.golang.org/log/1f0d8614f07980f3cca697a6de720f3b05266d9e) ",0,net testdialcancel failure on linux arm with network is unreachable in the fix for we skipped the test in case of a connection refused error it looks like we may need to widen that to network is unreachable as well fail testdialcancel dial test go dial error after ticks before cancel sent dial tcp connect network is unreachable fail fail net cc ianlancetaylor bradfitz ,0 12057,3573604348.0,IssuesEvent,2016-01-27 07:37:39,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: document allowed Scan conversions,Documentation,"
What does 'go version' print?

go version go1.3.3 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

http://play.golang.org/p/mk7wJKtz4H

What happened?

NullString.Scan didn't accept a time.Time value:

error: unsupported driver -> Scan pair: time.Time -> *string

What should have happened instead?

It should have converted the time.Time value into a string, just it does with any other
type that Scan accepts.

Please provide any additional information below.

The contract for Scanner says:

        // Scan assigns a value from a database driver.
        //
        // The src value will be of one of the following restricted
        // set of types:
        //
        //    int64
        //    float64
        //    bool
        //    []byte
        //    string
        //    time.Time
        //    nil - for NULL values
        //
        // An error should be returned if the value can not be stored
        // without loss of information.
        Scan(src interface{}) error

All of the other types work by formatting the values as strings. Given that time.Time
has a String() function, I would assume it would be handled as well.
",1.0,"database/sql: document allowed Scan conversions - 
What does 'go version' print?

go version go1.3.3 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

http://play.golang.org/p/mk7wJKtz4H

What happened?

NullString.Scan didn't accept a time.Time value:

error: unsupported driver -> Scan pair: time.Time -> *string

What should have happened instead?

It should have converted the time.Time value into a string, just it does with any other
type that Scan accepts.

Please provide any additional information below.

The contract for Scanner says:

        // Scan assigns a value from a database driver.
        //
        // The src value will be of one of the following restricted
        // set of types:
        //
        //    int64
        //    float64
        //    bool
        //    []byte
        //    string
        //    time.Time
        //    nil - for NULL values
        //
        // An error should be returned if the value can not be stored
        // without loss of information.
        Scan(src interface{}) error

All of the other types work by formatting the values as strings. Given that time.Time
has a String() function, I would assume it would be handled as well.
",1,database sql document allowed scan conversions what does go version print go version darwin what steps reproduce the problem if possible include a link to a program on play golang org a href what happened nullstring scan didn t accept a time time value error unsupported driver gt scan pair time time gt string what should have happened instead it should have converted the time time value into a string just it does with any other type that scan accepts please provide any additional information below the contract for scanner says scan assigns a value from a database driver the src value will be of one of the following restricted set of types bool byte string time time nil for null values an error should be returned if the value can not be stored without loss of information scan src interface error all of the other types work by formatting the values as strings given that time time has a string function i would assume it would be handled as well ,1 22376,4793115396.0,IssuesEvent,2016-10-31 17:17:26,golang/go,https://api.github.com/repos/golang/go,closed,reflect: NumMethod doesn't return not exported members of method sets,Documentation,"### What version of Go are you using (`go version`)? go version go1.7.1 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` > go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/mlowicki/projects/golang/spec"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` ### Repro https://play.golang.org/p/eXoyuqajG6 ### Expected result I expect to see method `n` also printed out and language spec doesn't enforce that method set contains only exported identifiers. Currently it displays only info about `M`: ``` Number of methods: 1 Method {M func(main.T) %!s(int=0)} Name: M PkgPath: ```",1.0,"reflect: NumMethod doesn't return not exported members of method sets - ### What version of Go are you using (`go version`)? go version go1.7.1 darwin/amd64 ### What operating system and processor architecture are you using (`go env`)? ``` > go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/mlowicki/projects/golang/spec"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` ### Repro https://play.golang.org/p/eXoyuqajG6 ### Expected result I expect to see method `n` also printed out and language spec doesn't enforce that method set contains only exported identifiers. Currently it displays only info about `M`: ``` Number of methods: 1 Method {M func(main.T) %!s(int=0)} Name: M PkgPath: ```",1,reflect nummethod doesn t return not exported members of method sets what version of go are you using go version go version darwin what operating system and processor architecture are you using go env go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users mlowicki projects golang spec gorace goroot usr local go gotooldir usr local go pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length gno record gcc switches fno common cxx clang cgo enabled repro expected result i expect to see method n also printed out and language spec doesn t enforce that method set contains only exported identifiers currently it displays only info about m number of methods method m func main t s int name m pkgpath ,1 33407,6201046170.0,IssuesEvent,2017-07-06 04:04:43,golang/go,https://api.github.com/repos/golang/go,closed,spec: document the hint for make(map) better,Documentation Proposal Proposal-Accepted,"### What version of Go are you using (`go version`)? go version devel +2e108a1be6 Tue Apr 4 11:55:55 2017 -0700 darwin/amd64 In https://go-review.googlesource.com/c/40113/ Rob Pike asked to add documentation about reflect.MakeMapWithSize.",1.0,"spec: document the hint for make(map) better - ### What version of Go are you using (`go version`)? go version devel +2e108a1be6 Tue Apr 4 11:55:55 2017 -0700 darwin/amd64 In https://go-review.googlesource.com/c/40113/ Rob Pike asked to add documentation about reflect.MakeMapWithSize.",1,spec document the hint for make map better what version of go are you using go version go version devel tue apr darwin in rob pike asked to add documentation about reflect makemapwithsize ,1 61717,8552941804.0,IssuesEvent,2018-11-07 22:42:07,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: perhaps misleading 'require new/thing v2.3.4' example in documentation,Documentation NeedsFix modules,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Tip (devel +0e40889796 Wed Oct 24 21:23:54 2018 +0000). ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? N/A. ### What did you do? Go to: https://tip.golang.org/cmd/go/#hdr-The_go_mod_file ### What did you see? The documentation section on ""The go.mod file"" includes what I think might be a misleading example `require` directive: ``` require new/thing v2.3.4 ``` I suspect that would not be representative of how the 1.11 tooling would write that after resolving any module queries. In other words, I would expect that example `require` to either include the `/v2`: ``` require new/thing/v2 v2.3.4 ``` or include `+incompatible`: ``` require new/thing v2.3.4+incompatible ``` or perhaps something else. I've seen people get confused on whether or not the `/vN` is required in a `require` directive for a v2+ dependency that has opted in to modules, so might be worth updating that example. For context, here is a slightly larger snippet from the doc: > Each line holds a single directive, made up of a verb followed by arguments. For example: > > ``` > module my/thing > require other/thing v1.0.2 > require new/thing v2.3.4 > exclude old/thing v1.2.3 > replace bad/thing v1.4.5 => good/thing v1.4.5 > ``` ",1.0,"cmd/go: perhaps misleading 'require new/thing v2.3.4' example in documentation - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? Tip (devel +0e40889796 Wed Oct 24 21:23:54 2018 +0000). ### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)? N/A. ### What did you do? Go to: https://tip.golang.org/cmd/go/#hdr-The_go_mod_file ### What did you see? The documentation section on ""The go.mod file"" includes what I think might be a misleading example `require` directive: ``` require new/thing v2.3.4 ``` I suspect that would not be representative of how the 1.11 tooling would write that after resolving any module queries. In other words, I would expect that example `require` to either include the `/v2`: ``` require new/thing/v2 v2.3.4 ``` or include `+incompatible`: ``` require new/thing v2.3.4+incompatible ``` or perhaps something else. I've seen people get confused on whether or not the `/vN` is required in a `require` directive for a v2+ dependency that has opted in to modules, so might be worth updating that example. For context, here is a slightly larger snippet from the doc: > Each line holds a single directive, made up of a verb followed by arguments. For example: > > ``` > module my/thing > require other/thing v1.0.2 > require new/thing v2.3.4 > exclude old/thing v1.2.3 > replace bad/thing v1.4.5 => good/thing v1.4.5 > ``` ",1,cmd go perhaps misleading require new thing example in documentation please answer these questions before submitting your issue thanks what version of go are you using go version tip devel wed oct does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env n a what did you do go to what did you see the documentation section on the go mod file includes what i think might be a misleading example require directive require new thing i suspect that would not be representative of how the tooling would write that after resolving any module queries in other words i would expect that example require to either include the require new thing or include incompatible require new thing incompatible or perhaps something else i ve seen people get confused on whether or not the vn is required in a require directive for a dependency that has opted in to modules so might be worth updating that example for context here is a slightly larger snippet from the doc each line holds a single directive made up of a verb followed by arguments for example module my thing require other thing require new thing exclude old thing replace bad thing good thing ,1 312924,23448034054.0,IssuesEvent,2022-08-15 21:55:16,golang/go,https://api.github.com/repos/golang/go,closed,net/http: clarify use-cases of WithContext vs Clone on requests,Documentation NeedsInvestigation,"The `http.Request` struct had a `Clone` method added in go 1.13, prompted by this issue: https://github.com/golang/go/issues/23544. At that time, I believe the documentation for `WithContext` was updated to suggest that most uses of that method could be replaced with `Clone`. However, that issue also had this follow-up exchange: https://github.com/golang/go/issues/23544#issuecomment-564336662 > @bradfitz I just came across Clone as a first time user of contexts within net/http. I had a question about this bit of documentation on WithContext: > > > ...To change the context of a request (such as an incoming) you then also want to modify to send back out, use Request.Clone. Between those two uses, it's rare to need WithContext. > > I wanted to ask if Clone should be preferred over WithContext in all situations. Specifically I'm writing a server middleware and only need to annotate a request (adding a logged in user) so it can be used by other handlers. > > Is WithContext not appropriate for this situation? And @bradfitz responded: > WithContext works there. And this has come up occasionally in Slack as well, with people writing very simple middleware that wrap `http.Handler` and just stick a value into the context on the request using `WithContext`. An extremely simple version, for which `Clone` seems like overkill, might be: ``` func WithRequestId(base http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx := context.WithValue(r.Context(), ""request_id"", uuid.NewString()) base.ServeHTTP(w, r.WithContext(ctx)) }) } ``` So this issue is mostly asking: is this usage of `WithContext` in this sort of middleware context _correct_, and furthermore can we augment the `WithContext` documentation block to be less prescriptive that `Clone` is the obvious way to go, and that there are plenty of value use-cases for `WithContext`, especially when you're not looking to ""reuse"" the request to make a subsequent request?",1.0,"net/http: clarify use-cases of WithContext vs Clone on requests - The `http.Request` struct had a `Clone` method added in go 1.13, prompted by this issue: https://github.com/golang/go/issues/23544. At that time, I believe the documentation for `WithContext` was updated to suggest that most uses of that method could be replaced with `Clone`. However, that issue also had this follow-up exchange: https://github.com/golang/go/issues/23544#issuecomment-564336662 > @bradfitz I just came across Clone as a first time user of contexts within net/http. I had a question about this bit of documentation on WithContext: > > > ...To change the context of a request (such as an incoming) you then also want to modify to send back out, use Request.Clone. Between those two uses, it's rare to need WithContext. > > I wanted to ask if Clone should be preferred over WithContext in all situations. Specifically I'm writing a server middleware and only need to annotate a request (adding a logged in user) so it can be used by other handlers. > > Is WithContext not appropriate for this situation? And @bradfitz responded: > WithContext works there. And this has come up occasionally in Slack as well, with people writing very simple middleware that wrap `http.Handler` and just stick a value into the context on the request using `WithContext`. An extremely simple version, for which `Clone` seems like overkill, might be: ``` func WithRequestId(base http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx := context.WithValue(r.Context(), ""request_id"", uuid.NewString()) base.ServeHTTP(w, r.WithContext(ctx)) }) } ``` So this issue is mostly asking: is this usage of `WithContext` in this sort of middleware context _correct_, and furthermore can we augment the `WithContext` documentation block to be less prescriptive that `Clone` is the obvious way to go, and that there are plenty of value use-cases for `WithContext`, especially when you're not looking to ""reuse"" the request to make a subsequent request?",1,net http clarify use cases of withcontext vs clone on requests the http request struct had a clone method added in go prompted by this issue at that time i believe the documentation for withcontext was updated to suggest that most uses of that method could be replaced with clone however that issue also had this follow up exchange bradfitz i just came across clone as a first time user of contexts within net http i had a question about this bit of documentation on withcontext to change the context of a request such as an incoming you then also want to modify to send back out use request clone between those two uses it s rare to need withcontext i wanted to ask if clone should be preferred over withcontext in all situations specifically i m writing a server middleware and only need to annotate a request adding a logged in user so it can be used by other handlers is withcontext not appropriate for this situation and bradfitz responded withcontext works there and this has come up occasionally in slack as well with people writing very simple middleware that wrap http handler and just stick a value into the context on the request using withcontext an extremely simple version for which clone seems like overkill might be func withrequestid base http handler http handler return http handlerfunc func w http responsewriter r http request ctx context withvalue r context request id uuid newstring base servehttp w r withcontext ctx so this issue is mostly asking is this usage of withcontext in this sort of middleware context correct and furthermore can we augment the withcontext documentation block to be less prescriptive that clone is the obvious way to go and that there are plenty of value use cases for withcontext especially when you re not looking to reuse the request to make a subsequent request ,1 43468,7047463876.0,IssuesEvent,2018-01-02 13:40:17,golang/go,https://api.github.com/repos/golang/go,closed,reflect: Is reflect.Type guaranteed to be hashable?,Documentation,"
I want to construct a cache of properties computed from a reflect.Type.
(For an example application, see http://play.golang.org/p/csLP1bBXJV)

The natural representation for that is map[reflect.Type]properties, but the correctness
of that approach depends on the implementation details of reflect.Type.

The documentation for (reflect.Type).String() says, "To test for equality, compare
the Types directly."  So that gives me some indication that what I'm trying to do
is reasonable.  However, nothing in the package tells me whether I can rely on the fact
that a reflect.Type is hashable.  (In practice, it currently is.)


The other alternatives I've considered are:

    map[struct{ pkgPath, name string }]properties - fails for unnamed types.

    map[uintptr]properties using reflect.Value.UnsafeAddr(t) - seems much worse than relying on hashability.

    map[uintptr]struct{reflect.Type, properties} using a hand-rolled hash function - very, very messy.


Since reflect.Type is hashable in practice anyway, the simplest solution would be to
document that that must be the case.

Obviously that has some drawbacks - it prevents reflect.Type from ever acquiring a
non-hashable field - but that still seems preferable to adding some kind of user-side
hashing or a new method for retrieving a unique ID.

On the other hand, if reflect.Type is not hashable, it would be good to document the
preferred workaround for constructing maps with Types as keys.
",1.0,"reflect: Is reflect.Type guaranteed to be hashable? - 
I want to construct a cache of properties computed from a reflect.Type.
(For an example application, see http://play.golang.org/p/csLP1bBXJV)

The natural representation for that is map[reflect.Type]properties, but the correctness
of that approach depends on the implementation details of reflect.Type.

The documentation for (reflect.Type).String() says, "To test for equality, compare
the Types directly."  So that gives me some indication that what I'm trying to do
is reasonable.  However, nothing in the package tells me whether I can rely on the fact
that a reflect.Type is hashable.  (In practice, it currently is.)


The other alternatives I've considered are:

    map[struct{ pkgPath, name string }]properties - fails for unnamed types.

    map[uintptr]properties using reflect.Value.UnsafeAddr(t) - seems much worse than relying on hashability.

    map[uintptr]struct{reflect.Type, properties} using a hand-rolled hash function - very, very messy.


Since reflect.Type is hashable in practice anyway, the simplest solution would be to
document that that must be the case.

Obviously that has some drawbacks - it prevents reflect.Type from ever acquiring a
non-hashable field - but that still seems preferable to adding some kind of user-side
hashing or a new method for retrieving a unique ID.

On the other hand, if reflect.Type is not hashable, it would be good to document the
preferred workaround for constructing maps with Types as keys.
",1,reflect is reflect type guaranteed to be hashable i want to construct a cache of properties computed from a reflect type for an example application see a href the natural representation for that is map properties but the correctness of that approach depends on the implementation details of reflect type the documentation for reflect type string says quot to test for equality compare the types directly quot so that gives me some indication that what i m trying to do is reasonable however nothing in the package tells me whether i can rely on the fact that a reflect type is hashable in practice it currently is the other alternatives i ve considered are map properties fails for unnamed types map properties using reflect value unsafeaddr t seems much worse than relying on hashability map struct reflect type properties using a hand rolled hash function very very messy since reflect type is hashable in practice anyway the simplest solution would be to document that that must be the case obviously that has some drawbacks it prevents reflect type from ever acquiring a non hashable field but that still seems preferable to adding some kind of user side hashing or a new method for retrieving a unique id on the other hand if reflect type is not hashable it would be good to document the preferred workaround for constructing maps with types as keys ,1 41206,21557401163.0,IssuesEvent,2022-04-30 17:00:31,golang/go,https://api.github.com/repos/golang/go,opened,cmd/compile: optimized range memclr doesn't work with pointers to arrays,Performance,"```go package p type T struct { a *[10]int b [10]int } func (t *T) resetA() { for i := range t.a { t.a[i] = 0 } } func (t *T) resetB() { for i := range t.b { t.b[i] = 0 } } ``` resetA compiles to a loop. resetB compiles to a call to runtime.memclrNoHeapPointers. I believe that resetA should also call memclrNoHeapPointers. This showed up as a hot spot in my code today (with much larger arrays). cc @randall77 @cuonglm @mdempsky ",True,"cmd/compile: optimized range memclr doesn't work with pointers to arrays - ```go package p type T struct { a *[10]int b [10]int } func (t *T) resetA() { for i := range t.a { t.a[i] = 0 } } func (t *T) resetB() { for i := range t.b { t.b[i] = 0 } } ``` resetA compiles to a loop. resetB compiles to a call to runtime.memclrNoHeapPointers. I believe that resetA should also call memclrNoHeapPointers. This showed up as a hot spot in my code today (with much larger arrays). cc @randall77 @cuonglm @mdempsky ",0,cmd compile optimized range memclr doesn t work with pointers to arrays go package p type t struct a int b int func t t reseta for i range t a t a func t t resetb for i range t b t b reseta compiles to a loop resetb compiles to a call to runtime memclrnoheappointers i believe that reseta should also call memclrnoheappointers this showed up as a hot spot in my code today with much larger arrays cc cuonglm mdempsky ,0 318740,23737822697.0,IssuesEvent,2022-08-31 09:39:21,golang/go,https://api.github.com/repos/golang/go,closed,net/http/pprof: documentation doesn't mention some available endpoints,Documentation NeedsFix,"Looking at https://pkg.go.dev/net/http/pprof as of Go 1.18.4, the following endpoints are documented: * heap * profile * block * mutex * trace From looking at https://cs.opensource.google/go/go/+/refs/tags/go1.18.4:src/net/http/pprof/pprof.go;l=344-354, the following are seemingly undocumented: * allocs * cmdline * goroutine * threadcreate In particular, I think the `goroutine` endpoint is critically underused; goroutine leaks are a fairly common source of problems in long-lived Go servers, and being able to obtain a goroutine stack dump via `/debug/pprof/goroutine?debug=2` is invaluable. I've met a handful of people over the years who needed this and resorted to heavier alternatives like SIGQUIT because they weren't aware that `net/http/pprof` had it. cc @cherrymui @rsc per https://dev.golang.org/owners",1.0,"net/http/pprof: documentation doesn't mention some available endpoints - Looking at https://pkg.go.dev/net/http/pprof as of Go 1.18.4, the following endpoints are documented: * heap * profile * block * mutex * trace From looking at https://cs.opensource.google/go/go/+/refs/tags/go1.18.4:src/net/http/pprof/pprof.go;l=344-354, the following are seemingly undocumented: * allocs * cmdline * goroutine * threadcreate In particular, I think the `goroutine` endpoint is critically underused; goroutine leaks are a fairly common source of problems in long-lived Go servers, and being able to obtain a goroutine stack dump via `/debug/pprof/goroutine?debug=2` is invaluable. I've met a handful of people over the years who needed this and resorted to heavier alternatives like SIGQUIT because they weren't aware that `net/http/pprof` had it. cc @cherrymui @rsc per https://dev.golang.org/owners",1,net http pprof documentation doesn t mention some available endpoints looking at as of go the following endpoints are documented heap profile block mutex trace from looking at the following are seemingly undocumented allocs cmdline goroutine threadcreate in particular i think the goroutine endpoint is critically underused goroutine leaks are a fairly common source of problems in long lived go servers and being able to obtain a goroutine stack dump via debug pprof goroutine debug is invaluable i ve met a handful of people over the years who needed this and resorted to heavier alternatives like sigquit because they weren t aware that net http pprof had it cc cherrymui rsc per ,1 370129,25889801032.0,IssuesEvent,2022-12-14 17:02:20,golang/go,https://api.github.com/repos/golang/go,opened,"spec: ""type parameters are interfaces"" is confusing",Documentation,"Per the spec, the underlying type of a type parameter is its constraint interface. Similarly to how we talk about an X type (say, an array type) if the underlying type of a named type is X, we also talk about interface types for type parameters. This is confusing. Reminder issue to try clearer prose where needed. See also @findleyr 's comment [here](https://go-review.git.corp.google.com/c/go/+/457095/3/doc/go_spec.html#5137).",1.0,"spec: ""type parameters are interfaces"" is confusing - Per the spec, the underlying type of a type parameter is its constraint interface. Similarly to how we talk about an X type (say, an array type) if the underlying type of a named type is X, we also talk about interface types for type parameters. This is confusing. Reminder issue to try clearer prose where needed. See also @findleyr 's comment [here](https://go-review.git.corp.google.com/c/go/+/457095/3/doc/go_spec.html#5137).",1,spec type parameters are interfaces is confusing per the spec the underlying type of a type parameter is its constraint interface similarly to how we talk about an x type say an array type if the underlying type of a named type is x we also talk about interface types for type parameters this is confusing reminder issue to try clearer prose where needed see also findleyr s comment ,1 53761,7855096922.0,IssuesEvent,2018-06-20 23:36:15,golang/go,https://api.github.com/repos/golang/go,closed,doc: update gopherbot wiki to account for backporting command,Documentation NeedsFix,"In https://github.com/golang/go/wiki/gopherbot the section for backporting is currently empty. We should fill it out :) /cc @filippo @gopherbot needsfix",1.0,"doc: update gopherbot wiki to account for backporting command - In https://github.com/golang/go/wiki/gopherbot the section for backporting is currently empty. We should fill it out :) /cc @filippo @gopherbot needsfix",1,doc update gopherbot wiki to account for backporting command in the section for backporting is currently empty we should fill it out cc filippo gopherbot needsfix,1 28942,13900364601.0,IssuesEvent,2020-10-20 00:08:25,golang/go,https://api.github.com/repos/golang/go,closed,cmd/compile: support inlining OCALLPART,Performance,"`context.WithCancel` allocates three objects. One is a `*cancelCtx`, unavoidable. Another is a `chan struct{}`, hard to eliminate without runtime magic or a language change. The last is [a closure](https://golang.org/src/context/context.go#L232): ```go return &c, func() { c.cancel(true, Canceled) } ``` `Canceled` is a top-level var initialized with `errors.New`; it is an `*errorString` under the hood. Note that `true` and `Canceled` are both static data. And `c` has already leaked to the heap, courtesy of the `&c` return. The method `cancel` can be staticly resolved. So it seems like in principle it ought to be possible not to allocate for the closure; everything we need is either static or on the heap already. Here's a straw man for how this might be accomplished. Generate a wrapper method: ```go func (c * cancelCtx) cancelTrueCanceled() { c.cancel(true, Canceled) } ``` and rewrite the original return to: ```go return &c, c.cancelTrueCanceled ``` (This can also be done manually, if this first transformation is too hard.) Now we have a partial method call with no free variables instead of a closure. Now represent this partial method call as a tuple: . The receiver we already have. The method could be a function pointer. The receiver and function pointers are values and can be passed around safely on the stack. This is not dissimilar to what we do now, except that the existing formulation always requires heap allocation. In some (but not all) cases, the heap allocation could be avoided. This is might be too big a change relative to the benefits it would bring, but thought I'd record it anyway. And maybe someone else sees a simpler way to eliminate this allocation. ",True,"cmd/compile: support inlining OCALLPART - `context.WithCancel` allocates three objects. One is a `*cancelCtx`, unavoidable. Another is a `chan struct{}`, hard to eliminate without runtime magic or a language change. The last is [a closure](https://golang.org/src/context/context.go#L232): ```go return &c, func() { c.cancel(true, Canceled) } ``` `Canceled` is a top-level var initialized with `errors.New`; it is an `*errorString` under the hood. Note that `true` and `Canceled` are both static data. And `c` has already leaked to the heap, courtesy of the `&c` return. The method `cancel` can be staticly resolved. So it seems like in principle it ought to be possible not to allocate for the closure; everything we need is either static or on the heap already. Here's a straw man for how this might be accomplished. Generate a wrapper method: ```go func (c * cancelCtx) cancelTrueCanceled() { c.cancel(true, Canceled) } ``` and rewrite the original return to: ```go return &c, c.cancelTrueCanceled ``` (This can also be done manually, if this first transformation is too hard.) Now we have a partial method call with no free variables instead of a closure. Now represent this partial method call as a tuple: . The receiver we already have. The method could be a function pointer. The receiver and function pointers are values and can be passed around safely on the stack. This is not dissimilar to what we do now, except that the existing formulation always requires heap allocation. In some (but not all) cases, the heap allocation could be avoided. This is might be too big a change relative to the benefits it would bring, but thought I'd record it anyway. And maybe someone else sees a simpler way to eliminate this allocation. ",0,cmd compile support inlining ocallpart context withcancel allocates three objects one is a cancelctx unavoidable another is a chan struct hard to eliminate without runtime magic or a language change the last is go return c func c cancel true canceled canceled is a top level var initialized with errors new it is an errorstring under the hood note that true and canceled are both static data and c has already leaked to the heap courtesy of the c return the method cancel can be staticly resolved so it seems like in principle it ought to be possible not to allocate for the closure everything we need is either static or on the heap already here s a straw man for how this might be accomplished generate a wrapper method go func c cancelctx canceltruecanceled c cancel true canceled and rewrite the original return to go return c c canceltruecanceled this can also be done manually if this first transformation is too hard now we have a partial method call with no free variables instead of a closure now represent this partial method call as a tuple the receiver we already have the method could be a function pointer the receiver and function pointers are values and can be passed around safely on the stack this is not dissimilar to what we do now except that the existing formulation always requires heap allocation in some but not all cases the heap allocation could be avoided this is might be too big a change relative to the benefits it would bring but thought i d record it anyway and maybe someone else sees a simpler way to eliminate this allocation ,0 16184,4021735968.0,IssuesEvent,2016-05-16 23:19:34,golang/go,https://api.github.com/repos/golang/go,closed,crypto/tls: document how to use intermediate certs with LoadX509KeyPair,Documentation,"Document that tls.LoadX509KeyPair's cert file include concatenated intermediate certs. /cc @agl ",1.0,"crypto/tls: document how to use intermediate certs with LoadX509KeyPair - Document that tls.LoadX509KeyPair's cert file include concatenated intermediate certs. /cc @agl ",1,crypto tls document how to use intermediate certs with document that tls s cert file include concatenated intermediate certs cc agl ,1 60729,8459910430.0,IssuesEvent,2018-10-22 17:16:22,golang/go,https://api.github.com/repos/golang/go,closed,"x/tools/present: Docs say 'h' key in the browser will toggle extra emphasis of any highlighted lines, seemingly not true.",Documentation NeedsFix,"### What version of Go are you using (`go version`)? ``` go version go1.7.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build653232358=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` ### What did you do? I read the documentation for present slide format at https://godoc.org/golang.org/x/tools/present. It said: > Also, inside the displayed text a line that ends > > ``` > // HL > ``` > > will be highlighted in the display; the 'h' key in the browser will toggle extra emphasis of any highlighted lines. ### What did you expect to see? Pressing 'h' key in browser would have some effect on emphasis of highlighted lines. ### What did you see instead? Pressing 'h' key has no effect on emphasis of highlighted lines. Looking at the code, https://github.com/golang/tools/blob/b5358b5feea9734b97ff1e792ca6bc55170bc92a/cmd/present/static/slides.js#L408 It says `'H' hides the help text`. So something doesn't look right here. I don't know if the documentation is wrong, or if the implementation has a bug. ",1.0,"x/tools/present: Docs say 'h' key in the browser will toggle extra emphasis of any highlighted lines, seemingly not true. - ### What version of Go are you using (`go version`)? ``` go version go1.7.1 darwin/amd64 ``` ### What operating system and processor architecture are you using (`go env`)? ``` $ go env GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""darwin"" GOOS=""darwin"" GOPATH=""/Users/Dmitri/Dropbox/Work/2013/GoLanding:/Users/Dmitri/Dropbox/Work/2013/GoLand"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/darwin_amd64"" CC=""clang"" GOGCCFLAGS=""-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/kgz4v2kn4n7d7ryg5k_z3dk40000gn/T/go-build653232358=/tmp/go-build -gno-record-gcc-switches -fno-common"" CXX=""clang++"" CGO_ENABLED=""1"" ``` ### What did you do? I read the documentation for present slide format at https://godoc.org/golang.org/x/tools/present. It said: > Also, inside the displayed text a line that ends > > ``` > // HL > ``` > > will be highlighted in the display; the 'h' key in the browser will toggle extra emphasis of any highlighted lines. ### What did you expect to see? Pressing 'h' key in browser would have some effect on emphasis of highlighted lines. ### What did you see instead? Pressing 'h' key has no effect on emphasis of highlighted lines. Looking at the code, https://github.com/golang/tools/blob/b5358b5feea9734b97ff1e792ca6bc55170bc92a/cmd/present/static/slides.js#L408 It says `'H' hides the help text`. So something doesn't look right here. I don't know if the documentation is wrong, or if the implementation has a bug. ",1,x tools present docs say h key in the browser will toggle extra emphasis of any highlighted lines seemingly not true what version of go are you using go version go version darwin what operating system and processor architecture are you using go env go env goarch gobin goexe gohostarch gohostos darwin goos darwin gopath users dmitri dropbox work golanding users dmitri dropbox work goland gorace goroot usr local go gotooldir usr local go pkg tool darwin cc clang gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders tw t go tmp go build gno record gcc switches fno common cxx clang cgo enabled what did you do i read the documentation for present slide format at it said also inside the displayed text a line that ends hl will be highlighted in the display the h key in the browser will toggle extra emphasis of any highlighted lines what did you expect to see pressing h key in browser would have some effect on emphasis of highlighted lines what did you see instead pressing h key has no effect on emphasis of highlighted lines looking at the code it says h hides the help text so something doesn t look right here i don t know if the documentation is wrong or if the implementation has a bug ,1 14607,3869666475.0,IssuesEvent,2016-04-10 18:50:52,golang/go,https://api.github.com/repos/golang/go,closed,html: UnescapeString documentation error,Documentation,"Go 1.6, Go Playground environment Documentation of [`html.UnescapeString()`](https://golang.org/pkg/html/#UnescapeString) contains a mistake. Quoting: > It unescapes a larger range of entities than EscapeString escapes. For example, `""á""` unescapes to ""á"", as does `""á""` and **""&xE1;""**. It should be **`á`** (there is a missing hashmark `#` in the doc). The implementation is good, but it is documented falsely. fmt.Println(html.UnescapeString(`&xE1;`)) // Output: &xE1; fmt.Println(html.UnescapeString(`á`)) // Output: á Output is as expected. Playground example: http://play.golang.org/p/S5EaiVfMKs ",1.0,"html: UnescapeString documentation error - Go 1.6, Go Playground environment Documentation of [`html.UnescapeString()`](https://golang.org/pkg/html/#UnescapeString) contains a mistake. Quoting: > It unescapes a larger range of entities than EscapeString escapes. For example, `""á""` unescapes to ""á"", as does `""á""` and **""&xE1;""**. It should be **`á`** (there is a missing hashmark `#` in the doc). The implementation is good, but it is documented falsely. fmt.Println(html.UnescapeString(`&xE1;`)) // Output: &xE1; fmt.Println(html.UnescapeString(`á`)) // Output: á Output is as expected. Playground example: http://play.golang.org/p/S5EaiVfMKs ",1,html unescapestring documentation error go go playground environment documentation of contains a mistake quoting it unescapes a larger range of entities than escapestring escapes for example aacute unescapes to á as does and it should be there is a missing hashmark in the doc the implementation is good but it is documented falsely fmt println html unescapestring output fmt println html unescapestring output á output is as expected playground example ,1 216943,16675122578.0,IssuesEvent,2021-06-07 15:18:31,golang/go,https://api.github.com/repos/golang/go,closed,"fmt: package documentation doesn't have linkable subheadings under top-level ""Printing"" and ""Scanning"" sections",Documentation NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 windows/amd64
### Does this issue reproduce with the latest release? Yes, including on tip. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\zephyr\AppData\Local\go-build
set GOENV=C:\Users\zephyr\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=E:\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=E:\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.3
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\zephyr\AppData\Local\Temp
\go-build1861236026=/tmp/go-build -gno-record-gcc-switches
### What did you do? I explained the explicit argument syntax for printf formatting verbs to someone, then tried to get a useful link to an authoritative source in golang.org/pkg/fmt to explain more thoroughly. ### What did you expect to see? An anchored section on explicit argument indices in the package documentation. ### What did you see instead? A ""section"" on explicit argument indices, but not one recognized by godoc because the line ends with punctuation: https://github.com/golang/go/blob/6e189afd3e7a3722c72b320ef604bf2910aee9e7/src/fmt/doc.go#L191-L193 It seems plausible that this is intentional, as the current structure leaves ""Printing"" and ""Scanning"" as the only proper sections. However, not having explicit sections for this particular topic – which seems to be underused – makes it harder to explain and promote its usefulness, particularly because there is no hyperlink to it. The current document also flows less effectively as a result of these broken sections. There is another subsequent pseudo-section like this on ""Format errors:"", but also many earlier lines describing the flags for various types; those lines follow this format, but they do not seem to be intended to be distinct subsections. The explicit argument indices section itself is shortly preceded by the line ""convert the value before recurring:"", which makes it hard to recognize that the former is a distinct section.",1.0,"fmt: package documentation doesn't have linkable subheadings under top-level ""Printing"" and ""Scanning"" sections - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.16.3 windows/amd64
### Does this issue reproduce with the latest release? Yes, including on tip. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\zephyr\AppData\Local\go-build
set GOENV=C:\Users\zephyr\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=E:\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=E:\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.3
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\zephyr\AppData\Local\Temp
\go-build1861236026=/tmp/go-build -gno-record-gcc-switches
### What did you do? I explained the explicit argument syntax for printf formatting verbs to someone, then tried to get a useful link to an authoritative source in golang.org/pkg/fmt to explain more thoroughly. ### What did you expect to see? An anchored section on explicit argument indices in the package documentation. ### What did you see instead? A ""section"" on explicit argument indices, but not one recognized by godoc because the line ends with punctuation: https://github.com/golang/go/blob/6e189afd3e7a3722c72b320ef604bf2910aee9e7/src/fmt/doc.go#L191-L193 It seems plausible that this is intentional, as the current structure leaves ""Printing"" and ""Scanning"" as the only proper sections. However, not having explicit sections for this particular topic – which seems to be underused – makes it harder to explain and promote its usefulness, particularly because there is no hyperlink to it. The current document also flows less effectively as a result of these broken sections. There is another subsequent pseudo-section like this on ""Format errors:"", but also many earlier lines describing the flags for various types; those lines follow this format, but they do not seem to be intended to be distinct subsections. The explicit argument indices section itself is shortly preceded by the line ""convert the value before recurring:"", which makes it hard to recognize that the former is a distinct section.",1,fmt package documentation doesn t have linkable subheadings under top level printing and scanning sections please answer these questions before submitting your issue thanks for questions please use one of our forums what version of go are you using go version go version go version windows does this issue reproduce with the latest release yes including on tip what operating system and processor architecture are you using go env go env output go env set on set goarch set gobin set gocache c users zephyr appdata local go build set goenv c users zephyr appdata roaming go env set goexe exe set goflags set gohostarch set gohostos windows set goinsecure set gomodcache e go pkg mod set gonoproxy set gonosumdb set goos windows set gopath e go set goprivate set goproxy set goroot c go set gosumdb sum golang org set gotmpdir set gotooldir c go pkg tool windows set govcs set goversion set gccgo gccgo set ar ar set cc gcc set cxx g set cgo enabled set gomod nul set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags mthreads fmessage length fdebug prefix map c users zephyr appdata local temp go tmp go build gno record gcc switches 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 i explained the explicit argument syntax for printf formatting verbs to someone then tried to get a useful link to an authoritative source in golang org pkg fmt to explain more thoroughly what did you expect to see an anchored section on explicit argument indices in the package documentation what did you see instead a section on explicit argument indices but not one recognized by godoc because the line ends with punctuation it seems plausible that this is intentional as the current structure leaves printing and scanning as the only proper sections however not having explicit sections for this particular topic – which seems to be underused – makes it harder to explain and promote its usefulness particularly because there is no hyperlink to it the current document also flows less effectively as a result of these broken sections there is another subsequent pseudo section like this on format errors but also many earlier lines describing the flags for various types those lines follow this format but they do not seem to be intended to be distinct subsections the explicit argument indices section itself is shortly preceded by the line convert the value before recurring which makes it hard to recognize that the former is a distinct section ,1 116266,11905976622.0,IssuesEvent,2020-03-30 19:32:15,golang/go,https://api.github.com/repos/golang/go,closed,doc: BuildNameToCertificate deprecated in go 1.14 not mentioned in the release notes [1.14 backport] [1.14 backport],CherryPickApproved Documentation,"@Aboood412 requested issue #38030 to be considered for backport to the next 1.14 minor release. > > @FiloSottile requested issue #37626 to be considered for backport to the next 1.14 minor release. > > > > > @gopherbot please open a backport issue for Go 1.14, this is a documentation change that needs to go live on golang.org. ",1.0,"doc: BuildNameToCertificate deprecated in go 1.14 not mentioned in the release notes [1.14 backport] [1.14 backport] - @Aboood412 requested issue #38030 to be considered for backport to the next 1.14 minor release. > > @FiloSottile requested issue #37626 to be considered for backport to the next 1.14 minor release. > > > > > @gopherbot please open a backport issue for Go 1.14, this is a documentation change that needs to go live on golang.org. ",1,doc buildnametocertificate deprecated in go not mentioned in the release notes requested issue to be considered for backport to the next minor release filosottile requested issue to be considered for backport to the next minor release gopherbot please open a backport issue for go this is a documentation change that needs to go live on golang org ,1 66551,8951939944.0,IssuesEvent,2019-01-25 15:17:34,golang/go,https://api.github.com/repos/golang/go,closed,"go/build: update documentation referring to binary-only packages, to mention 1.12 being the last supported release for BOP",Documentation,"[The Binary-Only Packages section](https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages) discusses binary-only packages, and [the AllowBinary constant](https://tip.golang.org/pkg/go/build/#ImportMode) also mentions them. Although the 1.12 release notes [mention that ""Go 1.12 is the last release that will support binary-only packages""](https://tip.golang.org/doc/go1.12#binary-only), it seems to me that the Godoc in go/build should make some mention of it as well. There might be other packages referring to binary-only packages in their documentation; I just happened to stumble across it in go/build today. footer on tip.golang.org: `Build version devel +9d23975 Wed Jan 23 23:13:03 2019 +0000.`",1.0,"go/build: update documentation referring to binary-only packages, to mention 1.12 being the last supported release for BOP - [The Binary-Only Packages section](https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages) discusses binary-only packages, and [the AllowBinary constant](https://tip.golang.org/pkg/go/build/#ImportMode) also mentions them. Although the 1.12 release notes [mention that ""Go 1.12 is the last release that will support binary-only packages""](https://tip.golang.org/doc/go1.12#binary-only), it seems to me that the Godoc in go/build should make some mention of it as well. There might be other packages referring to binary-only packages in their documentation; I just happened to stumble across it in go/build today. footer on tip.golang.org: `Build version devel +9d23975 Wed Jan 23 23:13:03 2019 +0000.`",1,go build update documentation referring to binary only packages to mention being the last supported release for bop discusses binary only packages and also mentions them although the release notes it seems to me that the godoc in go build should make some mention of it as well there might be other packages referring to binary only packages in their documentation i just happened to stumble across it in go build today footer on tip golang org build version devel wed jan ,1 7754,2930276963.0,IssuesEvent,2015-06-29 01:37:00,golang/go,https://api.github.com/repos/golang/go,opened,x/net/websocket: TestClose fails on Plan 9,OS-Plan9 Testing,"See http://build.golang.org/log/86c5f54b2e864b4a89f8756c4c069739fb314cc9 ``` 015/06/28 17:48:38 Test WebSocket server listening on 127.0.0.1:51846 --- FAIL: TestClose (0.00s) websocket_test.go:447: ws.Close(): expected error, got FAIL ```",1.0,"x/net/websocket: TestClose fails on Plan 9 - See http://build.golang.org/log/86c5f54b2e864b4a89f8756c4c069739fb314cc9 ``` 015/06/28 17:48:38 Test WebSocket server listening on 127.0.0.1:51846 --- FAIL: TestClose (0.00s) websocket_test.go:447: ws.Close(): expected error, got FAIL ```",0,x net websocket testclose fails on plan see test websocket server listening on fail testclose websocket test go ws close expected error got fail ,0 10693,3418612338.0,IssuesEvent,2015-12-08 03:22:54,golang/go,https://api.github.com/repos/golang/go,opened,tour: better explanation about type declarations?,Documentation,"Context: https://tour.golang.org/moretypes/2 I just decided to look through the Go tour to see how it explains named types and assignability. As far as I can tell, the only explanation is the parenthetical sentence ""And a `type` declaration does what you'd expect."" Based on user questions like issue #13529, I suspect that `type` declarations do *not* necessarily do what users expect, and perhaps it's worth elaborating on this point somehow.",1.0,"tour: better explanation about type declarations? - Context: https://tour.golang.org/moretypes/2 I just decided to look through the Go tour to see how it explains named types and assignability. As far as I can tell, the only explanation is the parenthetical sentence ""And a `type` declaration does what you'd expect."" Based on user questions like issue #13529, I suspect that `type` declarations do *not* necessarily do what users expect, and perhaps it's worth elaborating on this point somehow.",1,tour better explanation about type declarations context i just decided to look through the go tour to see how it explains named types and assignability as far as i can tell the only explanation is the parenthetical sentence and a type declaration does what you d expect based on user questions like issue i suspect that type declarations do not necessarily do what users expect and perhaps it s worth elaborating on this point somehow ,1 32412,6060684286.0,IssuesEvent,2017-06-14 02:55:18,golang/go,https://api.github.com/repos/golang/go,closed,path: make path/filepath suggestion more visible,Documentation NeedsFix,"Forking from https://github.com/golang/go/issues/18581#issuecomment-294511925, it is not clear that `path/filepath` needs to be used for operating system path manipulation and path is only for slash-separated. Make it easier for users to see the `path/filepath` suggestion.",1.0,"path: make path/filepath suggestion more visible - Forking from https://github.com/golang/go/issues/18581#issuecomment-294511925, it is not clear that `path/filepath` needs to be used for operating system path manipulation and path is only for slash-separated. Make it easier for users to see the `path/filepath` suggestion.",1,path make path filepath suggestion more visible forking from it is not clear that path filepath needs to be used for operating system path manipulation and path is only for slash separated make it easier for users to see the path filepath suggestion ,1 21885,4756979204.0,IssuesEvent,2016-10-24 15:23:17,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: improve documentation in go help packages,Documentation NeedsFix,"From `loadPackage` documentation: `In addition to ordinary import paths, loadPackage accepts pseudo-paths beginning with cmd/ to denote commands in the Go command directory, as well as paths to those directories.`. However this is not documented. `go help package` only says: `""cmd"" expands to the Go repository's commands and their internal libraries.`.",1.0,"cmd/go: improve documentation in go help packages - From `loadPackage` documentation: `In addition to ordinary import paths, loadPackage accepts pseudo-paths beginning with cmd/ to denote commands in the Go command directory, as well as paths to those directories.`. However this is not documented. `go help package` only says: `""cmd"" expands to the Go repository's commands and their internal libraries.`.",1,cmd go improve documentation in go help packages from loadpackage documentation in addition to ordinary import paths loadpackage accepts pseudo paths beginning with cmd to denote commands in the go command directory as well as paths to those directories however this is not documented go help package only says cmd expands to the go repository s commands and their internal libraries ,1 35025,6401270271.0,IssuesEvent,2017-08-05 19:16:21,golang/go,https://api.github.com/repos/golang/go,opened,doc: document the lack of support for symlinks under GOPATH,Documentation,"Quick back story: I've spent much longer than I should publicly admit developing Go with go guru half working. Whenever I tried to jump to a symbol in the current package outside the current file, go guru would fail to find the identifier. This was annoying, but I've become accustomed enough to broken tooling that I didn't think too much of it after a search of the vim-go issue tracker didn't mention anything. Today I got annoyed enough by the issue that I searched a bit harder and came across #20981 which in turn led me to #15507. Since I had been symlinking my privately hosted repo into my GOPATH, I immediately understood what was wrong. Fixing the issue was as simple as swapping the source and destination of my symlink. Now go guru finds all my symbols, which is great. Anyway, the main issue here is that a lot of developers use symlinks for perfectly valid reasons, but GOPATH doesn't support them. This causes some elements of the go tooling to break without warning, and should therefore be prominently documented in `go help gopath` and https://golang.org/doc/code.html#GOPATH. I can go ahead and submit a change, but I wanted to create an issue first to make sure this was fine.",1.0,"doc: document the lack of support for symlinks under GOPATH - Quick back story: I've spent much longer than I should publicly admit developing Go with go guru half working. Whenever I tried to jump to a symbol in the current package outside the current file, go guru would fail to find the identifier. This was annoying, but I've become accustomed enough to broken tooling that I didn't think too much of it after a search of the vim-go issue tracker didn't mention anything. Today I got annoyed enough by the issue that I searched a bit harder and came across #20981 which in turn led me to #15507. Since I had been symlinking my privately hosted repo into my GOPATH, I immediately understood what was wrong. Fixing the issue was as simple as swapping the source and destination of my symlink. Now go guru finds all my symbols, which is great. Anyway, the main issue here is that a lot of developers use symlinks for perfectly valid reasons, but GOPATH doesn't support them. This causes some elements of the go tooling to break without warning, and should therefore be prominently documented in `go help gopath` and https://golang.org/doc/code.html#GOPATH. I can go ahead and submit a change, but I wanted to create an issue first to make sure this was fine.",1,doc document the lack of support for symlinks under gopath quick back story i ve spent much longer than i should publicly admit developing go with go guru half working whenever i tried to jump to a symbol in the current package outside the current file go guru would fail to find the identifier this was annoying but i ve become accustomed enough to broken tooling that i didn t think too much of it after a search of the vim go issue tracker didn t mention anything today i got annoyed enough by the issue that i searched a bit harder and came across which in turn led me to since i had been symlinking my privately hosted repo into my gopath i immediately understood what was wrong fixing the issue was as simple as swapping the source and destination of my symlink now go guru finds all my symbols which is great anyway the main issue here is that a lot of developers use symlinks for perfectly valid reasons but gopath doesn t support them this causes some elements of the go tooling to break without warning and should therefore be prominently documented in go help gopath and i can go ahead and submit a change but i wanted to create an issue first to make sure this was fine ,1 11952,3551159551.0,IssuesEvent,2016-01-21 01:35:29,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: go list documentation of the struct passed to template is incomplete,Documentation,"The go list --help command documents the struct passed to the template. However the Package struct Error and DepsError fields have type PackageError, and this type is not documented.",1.0,"cmd/go: go list documentation of the struct passed to template is incomplete - The go list --help command documents the struct passed to the template. However the Package struct Error and DepsError fields have type PackageError, and this type is not documented.",1,cmd go go list documentation of the struct passed to template is incomplete the go list help command documents the struct passed to the template however the package struct error and depserror fields have type packageerror and this type is not documented ,1 80116,10152326526.0,IssuesEvent,2019-08-05 23:13:56,golang/go,https://api.github.com/repos/golang/go,closed,doc: describe/summarize error value features in the Go 1.13 release notes,Documentation NeedsDecision release-blocker,"The error value changes landing in Go 1.13 are one piece of the headline Go 2 ""better error handling"" improvements. However, [the only mention in the Go 1.13 release notes](https://tip.golang.org/doc/go1.13#errors) right now is a short list of the new functions in the ""Minor changes to the library"" section. I think these changes are important enough to warrant a description/summary at the top level of the release notes. Perhaps we should link to the design or mention the expected upcoming changes that will also tie in. Additionally, if we expect people to be adopting these features widely, perhaps we should include some prescriptive language to that end. (Or will there be a blog post?) This is related to #33364, where the new features are also inadequately described in the package documentation. /cc @jba @neild ",1.0,"doc: describe/summarize error value features in the Go 1.13 release notes - The error value changes landing in Go 1.13 are one piece of the headline Go 2 ""better error handling"" improvements. However, [the only mention in the Go 1.13 release notes](https://tip.golang.org/doc/go1.13#errors) right now is a short list of the new functions in the ""Minor changes to the library"" section. I think these changes are important enough to warrant a description/summary at the top level of the release notes. Perhaps we should link to the design or mention the expected upcoming changes that will also tie in. Additionally, if we expect people to be adopting these features widely, perhaps we should include some prescriptive language to that end. (Or will there be a blog post?) This is related to #33364, where the new features are also inadequately described in the package documentation. /cc @jba @neild ",1,doc describe summarize error value features in the go release notes the error value changes landing in go are one piece of the headline go better error handling improvements however right now is a short list of the new functions in the minor changes to the library section i think these changes are important enough to warrant a description summary at the top level of the release notes perhaps we should link to the design or mention the expected upcoming changes that will also tie in additionally if we expect people to be adopting these features widely perhaps we should include some prescriptive language to that end or will there be a blog post this is related to where the new features are also inadequately described in the package documentation cc jba neild ,1 406363,27561139336.0,IssuesEvent,2023-03-07 22:08:46,golang/go,https://api.github.com/repos/golang/go,closed,net: document that on some systems SetLinger causes conn.Close to block,Documentation help wanted NeedsFix," ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.1 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/stephen/.cache/go-build""
GOENV=""/home/stephen/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/stephen/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/stephen/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.20.1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build223210887=/tmp/go-build -gno-record-gcc-switches""
### What did you do? We added an explicit call to `SetLinger(15)` here: https://github.com/ava-labs/avalanchego/commit/1a2dca18d22a7a78e421e95dbdbe038287ee8361 ### What did you expect to see? https://github.com/golang/go/blob/b94dc384cabf75e7e8703265cd80f5324f84b642/src/net/tcpsock.go#L161-L173 claims that providing `SetLinger` with a positive value will: > // If sec > 0, the data is sent in the background as with sec < 0. On > // some operating systems after sec seconds have elapsed any remaining > // unsent data may be discarded. We expected for the OS to flush any outstanding data over the TCP stream in the background. ### What did you see instead? It doesn't seem that the data is being sent in the backaground, but that `conn.Close()` may block until the specified timeout. I don't think this is actually unexpected for the behavior of [SO_LINGER](https://linux.die.net/man/3/setsockopt): > SO_LINGER > Lingers on a close() if data is present. This option controls the action taken when unsent messages queue on a socket and close() is performed. If SO_LINGER is set, the system shall block the process during close() until it can transmit the data or until the time expires. If SO_LINGER is not specified, and close() is issued, the system handles the call in a way that allows the process to continue as quickly as possible. This option takes a linger structure, as defined in the <[sys/socket.h](https://linux.die.net/include/sys/socket.h)> header, to specify the state of the option and linger interval. However, I feel like the comment on `SetLinger` seems to contradict the man pages. ",1.0,"net: document that on some systems SetLinger causes conn.Close to block - ### What version of Go are you using (`go version`)? 
$ go version
go version go1.20.1 linux/amd64
### Does this issue reproduce with the latest release? Yes. ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/home/stephen/.cache/go-build""
GOENV=""/home/stephen/.config/go/env""
GOEXE=""""
GOEXPERIMENT=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""linux""
GOINSECURE=""""
GOMODCACHE=""/home/stephen/go/pkg/mod""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""linux""
GOPATH=""/home/stephen/go""
GOPRIVATE=""""
GOPROXY=""https://proxy.golang.org,direct""
GOROOT=""/usr/local/go""
GOSUMDB=""sum.golang.org""
GOTMPDIR=""""
GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64""
GOVCS=""""
GOVERSION=""go1.20.1""
GCCGO=""gccgo""
GOAMD64=""v1""
AR=""ar""
CC=""gcc""
CXX=""g++""
CGO_ENABLED=""1""
GOMOD=""/dev/null""
GOWORK=""""
CGO_CFLAGS=""-O2 -g""
CGO_CPPFLAGS=""""
CGO_CXXFLAGS=""-O2 -g""
CGO_FFLAGS=""-O2 -g""
CGO_LDFLAGS=""-O2 -g""
PKG_CONFIG=""pkg-config""
GOGCCFLAGS=""-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build223210887=/tmp/go-build -gno-record-gcc-switches""
### What did you do? We added an explicit call to `SetLinger(15)` here: https://github.com/ava-labs/avalanchego/commit/1a2dca18d22a7a78e421e95dbdbe038287ee8361 ### What did you expect to see? https://github.com/golang/go/blob/b94dc384cabf75e7e8703265cd80f5324f84b642/src/net/tcpsock.go#L161-L173 claims that providing `SetLinger` with a positive value will: > // If sec > 0, the data is sent in the background as with sec < 0. On > // some operating systems after sec seconds have elapsed any remaining > // unsent data may be discarded. We expected for the OS to flush any outstanding data over the TCP stream in the background. ### What did you see instead? It doesn't seem that the data is being sent in the backaground, but that `conn.Close()` may block until the specified timeout. I don't think this is actually unexpected for the behavior of [SO_LINGER](https://linux.die.net/man/3/setsockopt): > SO_LINGER > Lingers on a close() if data is present. This option controls the action taken when unsent messages queue on a socket and close() is performed. If SO_LINGER is set, the system shall block the process during close() until it can transmit the data or until the time expires. If SO_LINGER is not specified, and close() is issued, the system handles the call in a way that allows the process to continue as quickly as possible. This option takes a linger structure, as defined in the <[sys/socket.h](https://linux.die.net/include/sys/socket.h)> header, to specify the state of the option and linger interval. However, I feel like the comment on `SetLinger` seems to contradict the man pages. ",1,net document that on some systems setlinger causes conn close to block please answer these questions before submitting your issue thanks what version of go are you using go version go version go version linux does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache home stephen cache go build goenv home stephen config go env goexe goexperiment goflags gohostarch gohostos linux goinsecure gomodcache home stephen go pkg mod gonoproxy gonosumdb goos linux gopath home stephen go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool linux govcs goversion gccgo gccgo ar ar cc gcc cxx g cgo enabled gomod dev null gowork cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread wl no gc sections fmessage length fdebug prefix map tmp go tmp go build gno record gcc switches what did you do if possible provide a recipe for reproducing the error a complete runnable program is good a link on go dev play is best we added an explicit call to setlinger here what did you expect to see claims that providing setlinger with a positive value will if sec the data is sent in the background as with sec on some operating systems after sec seconds have elapsed any remaining unsent data may be discarded we expected for the os to flush any outstanding data over the tcp stream in the background what did you see instead it doesn t seem that the data is being sent in the backaground but that conn close may block until the specified timeout i don t think this is actually unexpected for the behavior of so linger lingers on a close if data is present this option controls the action taken when unsent messages queue on a socket and close is performed if so linger is set the system shall block the process during close until it can transmit the data or until the time expires if so linger is not specified and close is issued the system handles the call in a way that allows the process to continue as quickly as possible this option takes a linger structure as defined in the header to specify the state of the option and linger interval however i feel like the comment on setlinger seems to contradict the man pages ,1 21770,4745725236.0,IssuesEvent,2016-10-21 08:31:44,golang/go,https://api.github.com/repos/golang/go,closed,database/sql: sql argument counts are off by one when reporting an error,Documentation NeedsFix,"I know this is pretty trivial, but when reporting an error the sql package seems to report arguments by counting them starting at zero. Since SQL arguments are generally numbered from 1 -- and indeed, for PostgreSQL they are numbered $1, $2, $3... in the SQL itself -- this confused me. e.g. sql: converting Exec argument #3's type: unsupported type main.Date, a struct It was actually argument #4 ($4 in the SQL statement). go version go1.6.2 linux/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/meta/go/tecdocs"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ",1.0,"database/sql: sql argument counts are off by one when reporting an error - I know this is pretty trivial, but when reporting an error the sql package seems to report arguments by counting them starting at zero. Since SQL arguments are generally numbered from 1 -- and indeed, for PostgreSQL they are numbered $1, $2, $3... in the SQL itself -- this confused me. e.g. sql: converting Exec argument #3's type: unsupported type main.Date, a struct It was actually argument #4 ($4 in the SQL statement). go version go1.6.2 linux/amd64 GOARCH=""amd64"" GOBIN="""" GOEXE="""" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" GOPATH=""/home/meta/go/tecdocs"" GORACE="""" GOROOT=""/usr/local/go"" GOTOOLDIR=""/usr/local/go/pkg/tool/linux_amd64"" GO15VENDOREXPERIMENT=""1"" CC=""gcc"" GOGCCFLAGS=""-fPIC -m64 -pthread -fmessage-length=0"" CXX=""g++"" CGO_ENABLED=""1"" ",1,database sql sql argument counts are off by one when reporting an error i know this is pretty trivial but when reporting an error the sql package seems to report arguments by counting them starting at zero since sql arguments are generally numbered from and indeed for postgresql they are numbered in the sql itself this confused me e g sql converting exec argument s type unsupported type main date a struct it was actually argument in the sql statement go version linux goarch gobin goexe gohostarch gohostos linux goos linux gopath home meta go tecdocs gorace goroot usr local go gotooldir usr local go pkg tool linux cc gcc gogccflags fpic pthread fmessage length cxx g cgo enabled ,1 56102,8051004225.0,IssuesEvent,2018-08-01 14:56:33,golang/go,https://api.github.com/repos/golang/go,opened,doc/install: define minimum supported VCS versions,Documentation,"`cmd/go` shells out to version control binaries to implement `go get`. [doc/install](https://tip.golang.org/doc/install) currently declares minimum supported OS versions for FreeBSD, macOS, and Windows, but only a minimum kernel version for Linux. Those requirements do not imply any particular version of the supported version control binaries, and those versions do matter in practice: in particular, `git` accrued a large number of flags in between 2.7 and 2.18 (https://github.com/golang/go/issues/26653). We should be explicit about which versions are supported for use with the `go` command. (CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)",1.0,"doc/install: define minimum supported VCS versions - `cmd/go` shells out to version control binaries to implement `go get`. [doc/install](https://tip.golang.org/doc/install) currently declares minimum supported OS versions for FreeBSD, macOS, and Windows, but only a minimum kernel version for Linux. Those requirements do not imply any particular version of the supported version control binaries, and those versions do matter in practice: in particular, `git` accrued a large number of flags in between 2.7 and 2.18 (https://github.com/golang/go/issues/26653). We should be explicit about which versions are supported for use with the `go` command. (CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)",1,doc install define minimum supported vcs versions cmd go shells out to version control binaries to implement go get currently declares minimum supported os versions for freebsd macos and windows but only a minimum kernel version for linux those requirements do not imply any particular version of the supported version control binaries and those versions do matter in practice in particular git accrued a large number of flags in between and we should be explicit about which versions are supported for use with the go command cc rsc ianlancetaylor bradfitz myitcv rogpeppe trashhalo ,1 39699,6761881045.0,IssuesEvent,2017-10-25 04:48:22,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: short commands description in 'go help' too vague for some command,Documentation NeedsDecision,"Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.8.1 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" ### What did you do? ``` $ go help Go is a tool for managing Go source code. ... The commands are: build compile packages and dependencies clean remove object files doc show documentation for package or symbol env print Go environment information bug start a bug report fix run go tool fix on packages fmt run gofmt on package sources generate generate Go files by processing source get download and install packages and dependencies install compile and install packages and dependencies list list packages run compile and run Go program test test packages tool run specified go tool version print Go version vet run go tool vet on packages ... ``` ### What did you expect to see? The help output for the `fix` and `vet` is not helpful. Is is just `(""run go tool %s on packages"", toolname)`. Also the `fmt` output could be improved. ### What did you see instead? The help-output should say what the command will effectively do (like for `vet`: check the source code for potential issues). ",1.0,"cmd/go: short commands description in 'go help' too vague for some command - Please answer these questions before submitting your issue. Thanks! ### What version of Go are you using (`go version`)? go1.8.1 ### What operating system and processor architecture are you using (`go env`)? GOARCH=""amd64"" GOHOSTARCH=""amd64"" GOHOSTOS=""linux"" GOOS=""linux"" ### What did you do? ``` $ go help Go is a tool for managing Go source code. ... The commands are: build compile packages and dependencies clean remove object files doc show documentation for package or symbol env print Go environment information bug start a bug report fix run go tool fix on packages fmt run gofmt on package sources generate generate Go files by processing source get download and install packages and dependencies install compile and install packages and dependencies list list packages run compile and run Go program test test packages tool run specified go tool version print Go version vet run go tool vet on packages ... ``` ### What did you expect to see? The help output for the `fix` and `vet` is not helpful. Is is just `(""run go tool %s on packages"", toolname)`. Also the `fmt` output could be improved. ### What did you see instead? The help-output should say what the command will effectively do (like for `vet`: check the source code for potential issues). ",1,cmd go short commands description in go help too vague for some command please answer these questions before submitting your issue thanks what version of go are you using go version what operating system and processor architecture are you using go env goarch gohostarch gohostos linux goos linux what did you do go help go is a tool for managing go source code the commands are build compile packages and dependencies clean remove object files doc show documentation for package or symbol env print go environment information bug start a bug report fix run go tool fix on packages fmt run gofmt on package sources generate generate go files by processing source get download and install packages and dependencies install compile and install packages and dependencies list list packages run compile and run go program test test packages tool run specified go tool version print go version vet run go tool vet on packages what did you expect to see the help output for the fix and vet is not helpful is is just run go tool s on packages toolname also the fmt output could be improved what did you see instead the help output should say what the command will effectively do like for vet check the source code for potential issues ,1 56758,8123710133.0,IssuesEvent,2018-08-16 15:18:54,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go: documentation typo in go help mod download [1.10 backport],CherryPickCandidate Documentation,"@bradfitz requested issue #27030 to be considered for backport to the next 1.10 minor release. > @gopherbot, please backport to 1.11. ",1.0,"cmd/go: documentation typo in go help mod download [1.10 backport] - @bradfitz requested issue #27030 to be considered for backport to the next 1.10 minor release. > @gopherbot, please backport to 1.11. ",1,cmd go documentation typo in go help mod download bradfitz requested issue to be considered for backport to the next minor release gopherbot please backport to ,1 306521,23163737507.0,IssuesEvent,2022-07-29 21:03:11,golang/go,https://api.github.com/repos/golang/go,closed,x/sys/windows: godoc is useless again,Documentation OS-Windows compiler/runtime,"The godoc for https://godoc.org/golang.org/x/sys/windows is empty, probably because of https://go-review.googlesource.com/24952 Maybe this is a gddo problem too. (Or maybe gddo can help or have better heuristics over which build context to use) /cc @alexbrainman @adg @broady @shantuo @alandonovan ",1.0,"x/sys/windows: godoc is useless again - The godoc for https://godoc.org/golang.org/x/sys/windows is empty, probably because of https://go-review.googlesource.com/24952 Maybe this is a gddo problem too. (Or maybe gddo can help or have better heuristics over which build context to use) /cc @alexbrainman @adg @broady @shantuo @alandonovan ",1,x sys windows godoc is useless again the godoc for is empty probably because of maybe this is a gddo problem too or maybe gddo can help or have better heuristics over which build context to use cc alexbrainman adg broady shantuo alandonovan ,1 423981,29040800028.0,IssuesEvent,2023-05-13 00:23:25,golang/go,https://api.github.com/repos/golang/go,closed,cmd/go/internal/modindex: index_format.txt is out of date,Documentation NeedsFix GoCommand,"As of Apr 2023 (87272bd1a18666ec38ac44c63e11c739f3054056), [`cmd/go/internal/modindex/index_format.go`](https://github.com/golang/go/blob/87272bd1a18666ec38ac44c63e11c739f3054056/src/cmd/go/internal/modindex/index_format.txt) describes `""go index v0""`. But the index format was updated to `""go index v1""` in 7510e597def68cee77e8ba280fc0f04d3cfd2a22 and `""go index v2""` in bd8ec78b08ead1fb34ec8dc7bc4bf2ff7a9e8b82",1.0,"cmd/go/internal/modindex: index_format.txt is out of date - As of Apr 2023 (87272bd1a18666ec38ac44c63e11c739f3054056), [`cmd/go/internal/modindex/index_format.go`](https://github.com/golang/go/blob/87272bd1a18666ec38ac44c63e11c739f3054056/src/cmd/go/internal/modindex/index_format.txt) describes `""go index v0""`. But the index format was updated to `""go index v1""` in 7510e597def68cee77e8ba280fc0f04d3cfd2a22 and `""go index v2""` in bd8ec78b08ead1fb34ec8dc7bc4bf2ff7a9e8b82",1,cmd go internal modindex index format txt is out of date as of apr describes go index but the index format was updated to go index in and go index in ,1 43714,7059294876.0,IssuesEvent,2018-01-05 00:37:55,golang/go,https://api.github.com/repos/golang/go,closed,net/http: document how to create client CONNECT requests,Documentation NeedsFix,"### What version of Go are you using (`go version`)? Go1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? windows/amd64 ### What did you do? This error is reproducible at https://play.golang.org/p/9m7rlnqsTm I attempted to create a new HTTP request with http.NewRequest() using a URI that starts with a number, with no protocol, that also contains a port: ```_, err = http.NewRequest(http.MethodConnect, ""0.docs.google.com:443"", nil)``` ### What did you expect to see? The request should be created with no error. ### What did you see instead? I get the error ""parse : first path segment in URL cannot contain colon"" ",1.0,"net/http: document how to create client CONNECT requests - ### What version of Go are you using (`go version`)? Go1.9 ### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)? windows/amd64 ### What did you do? This error is reproducible at https://play.golang.org/p/9m7rlnqsTm I attempted to create a new HTTP request with http.NewRequest() using a URI that starts with a number, with no protocol, that also contains a port: ```_, err = http.NewRequest(http.MethodConnect, ""0.docs.google.com:443"", nil)``` ### What did you expect to see? The request should be created with no error. ### What did you see instead? I get the error ""parse : first path segment in URL cannot contain colon"" ",1,net http document how to create client connect requests what version of go are you using go version does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env windows what did you do this error is reproducible at i attempted to create a new http request with http newrequest using a uri that starts with a number with no protocol that also contains a port err http newrequest http methodconnect docs google com nil what did you expect to see the request should be created with no error what did you see instead i get the error parse first path segment in url cannot contain colon ,1 97440,11013788834.0,IssuesEvent,2019-12-04 21:14:59,golang/go,https://api.github.com/repos/golang/go,closed,"math/rand: possibly ambiguous use of operator ""^"" in documentation",Documentation NeedsFix,"According to the doc here https://golang.org/pkg/math/rand/#Seed > Seed values that have the same remainder when divided by 2^31-1 generate the same pseudo-random sequence. This means seed 29 and 57 will generate the same pseudo random sequence. But I get different results. Am I missing something? ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/james/Library/Caches/go-build""
GOENV=""/Users/james/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/james/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=""""
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/sp/n3hrxcgd3wgb8zb_3mt1w9kr0000gn/T/go-build316781643=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://play.golang.org/p/AoWrOyO2rOP ### What did you expect to see? same pseudo random sequence ### What did you see instead? different results with seed 29 and 57 29: 3 57: 4 ",1.0,"math/rand: possibly ambiguous use of operator ""^"" in documentation - According to the doc here https://golang.org/pkg/math/rand/#Seed > Seed values that have the same remainder when divided by 2^31-1 generate the same pseudo-random sequence. This means seed 29 and 57 will generate the same pseudo random sequence. But I get different results. Am I missing something? ### What version of Go are you using (`go version`)? 
$ go version
go version go1.13.4 darwin/amd64
### Does this issue reproduce with the latest release? Yes ### What operating system and processor architecture are you using (`go env`)?
go env Output
$ go env
GO111MODULE=""""
GOARCH=""amd64""
GOBIN=""""
GOCACHE=""/Users/james/Library/Caches/go-build""
GOENV=""/Users/james/Library/Application Support/go/env""
GOEXE=""""
GOFLAGS=""""
GOHOSTARCH=""amd64""
GOHOSTOS=""darwin""
GONOPROXY=""""
GONOSUMDB=""""
GOOS=""darwin""
GOPATH=""/Users/james/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=""""
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/sp/n3hrxcgd3wgb8zb_3mt1w9kr0000gn/T/go-build316781643=/tmp/go-build -gno-record-gcc-switches -fno-common""
### What did you do? https://play.golang.org/p/AoWrOyO2rOP ### What did you expect to see? same pseudo random sequence ### What did you see instead? different results with seed 29 and 57 29: 3 57: 4 ",1,math rand possibly ambiguous use of operator in documentation according to the doc here seed values that have the same remainder when divided by generate the same pseudo random sequence this means seed and will generate the same pseudo random sequence but i get different results am i missing something what version of go are you using go version go version go version darwin does this issue reproduce with the latest release yes what operating system and processor architecture are you using go env go env output go env goarch gobin gocache users james library caches go build goenv users james library application support go env goexe goflags gohostarch gohostos darwin gonoproxy gonosumdb goos darwin gopath users james go goprivate goproxy goroot usr local go gosumdb sum golang org gotmpdir gotooldir usr local go pkg tool darwin gccgo gccgo ar ar cc clang cxx clang cgo enabled gomod cgo cflags g cgo cppflags cgo cxxflags g cgo fflags g cgo ldflags g pkg config pkg config gogccflags fpic pthread fno caret diagnostics qunused arguments fmessage length fdebug prefix map var folders sp t go tmp go build gno record gcc switches fno common what did you do what did you expect to see same pseudo random sequence what did you see instead different results with seed and ,1 430236,30122302858.0,IssuesEvent,2023-06-30 16:09:31,golang/go,https://api.github.com/repos/golang/go,closed,x/tools/go/packages/gopackages: better documentation of -mode flag,Documentation NeedsInvestigation Tools," ### What version of Go are you using (`go version`)? 
go version go1.20 windows/amd64
### What operating system and processor architecture are you using (`go env`)?
go env Output
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Steven\AppData\Local\go-build
set GOENV=C:\Users\Steven\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Steven\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Steven\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=D:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Windows\TEMP\go-build2434007380=/tmp/go-build -gno-record-gcc-switches
### What did you do? using this input: ~~~go package tls type dsaSignature struct { } type lruSessionCache struct {} func NewLRUClientSessionCache() lruSessionCache { return lruSessionCache{} } ~~~ ### What did you see instead? I get this result: ~~~ > gopackages -mode types -private tls Go package ""tls"": package tls has complete exported type info file D:\Desktop\etc\common.go func NewLRUClientSessionCache() lruSessionCache type lruSessionCache struct{} ~~~ one type is listed, but the other is not.",1.0,"x/tools/go/packages/gopackages: better documentation of -mode flag - ### What version of Go are you using (`go version`)? 
go version go1.20 windows/amd64
### What operating system and processor architecture are you using (`go env`)?
go env Output
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Steven\AppData\Local\go-build
set GOENV=C:\Users\Steven\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Steven\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Steven\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=D:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Windows\TEMP\go-build2434007380=/tmp/go-build -gno-record-gcc-switches
### What did you do? using this input: ~~~go package tls type dsaSignature struct { } type lruSessionCache struct {} func NewLRUClientSessionCache() lruSessionCache { return lruSessionCache{} } ~~~ ### What did you see instead? I get this result: ~~~ > gopackages -mode types -private tls Go package ""tls"": package tls has complete exported type info file D:\Desktop\etc\common.go func NewLRUClientSessionCache() lruSessionCache type lruSessionCache struct{} ~~~ one type is listed, but the other is not.",1,x tools go packages gopackages better documentation of mode flag what version of go are you using go version go version windows what operating system and processor architecture are you using go env go env output set set goarch set gobin set gocache c users steven appdata local go build set goenv c users steven appdata roaming go env set goexe exe set goexperiment set goflags set gohostarch set gohostos windows set goinsecure set gomodcache c users steven go pkg mod set gonoproxy set gonosumdb set goos windows set gopath c users steven go set goprivate set goproxy set goroot d go set gosumdb sum golang org set gotmpdir set gotooldir d go pkg tool windows set govcs set goversion set gccgo gccgo set set ar ar set cc gcc set cxx g set cgo enabled set gomod nul set gowork set cgo cflags g set cgo cppflags set cgo cxxflags g set cgo fflags g set cgo ldflags g set pkg config pkg config set gogccflags mthreads wl no gc sections fmessage length fdebug prefix map c windows temp go tmp go build gno record gcc switches what did you do using this input go package tls type dsasignature struct type lrusessioncache struct func newlruclientsessioncache lrusessioncache return lrusessioncache what did you see instead i get this result gopackages mode types private tls go package tls package tls has complete exported type info file d desktop etc common go func newlruclientsessioncache lrusessioncache type lrusessioncache struct one type is listed but the other is not ,1 50632,7614181443.0,IssuesEvent,2018-05-02 01:11:16,golang/go,https://api.github.com/repos/golang/go,closed,doc: clearer plain git contributing guidelines,Documentation,"### What: Change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git. ### What it is not: This issue is not a request or proposal to replace Gerrit or the review process. This issue is not a request or proposal to remove the `git-codereview` tool or to make drastic changes to how anyone on the Go team or existing contributors go about contributing. ### Why: There are other open issues proposing a switch to GitHub (#21956), or adding the ability to support pushing via GitHub (#18517). Based on my own experience I think much of the friction that GitHub users are experiencing is caused by the contributing guidelines centering around `git-codereview`, which abstracts git away from the developer. Abstracting git away from developers is jarring when developers know how to use that tool already. It gives them the experience that they are using something that is entirely different to what they use today, even though it is not. ### Context: I recently submitted my [first](https://go-review.googlesource.com/c/go/+/73890) [contribution](https://go-review.googlesource.com/c/go/+/73891) to Go and was surprised at how straight forward and refreshing Gerrit was in comparison to GitHub. I had delayed contributing because the process described at https://golang.org/doc/contribute.html appeared so different to what I was use to. In practice it wasn't. It only appeared that way because there was a layer of abstraction. Before contributing the main point of friction for me wasn't the use of Gerrit vs GitHub, but the fact that all of the examples centered around the use of `git-codereview`, a custom tool for interacting with the Go Gerrit instance. I realize this tool is optional, but it took time to read all of the text and note down which git commands each `git-codereview` command actually used. At the end it came down to: 1. Install two hooks 2. `git clone` 3. `git pull -r` 4. `git checkout -b ` 5. `git commit` 6. `git push -u origin HEAD:refs/for/master` (patch set 1) 7. `git commit --amend` 8. `git push -u origin HEAD:refs/for/master` (patch set 2) The above is almost identical to the workflows I use at work and on open source on GitHub, and it is instantly familiar to me as a git user. The contribution guidelines tell a different story: 1. `git codereview hooks` 2. `git clone` 3. `git sync` 4. `git change` 5. `git mail` (patch set 1) 6. `git change` (to amend) 7. `git mail` (patch set 2) While the above is technically less commands, it's four new commands that I had never seen before and had to learn about. These commands abstract git away from plain git users, unnecessarily. ### How: Some ideas for how the contributing guidelines document could be made more familiar to plain git users: * Replace examples using `git-codereview` with plain git commands where the corresponding git commands are simple and straight forward. e.g. `git sync` vs `git pull -r`, `git push` vs `git mail`, etc. * Display plain git commands side-by-side (not one after the other) in the same size, font, weight, etc. * Make `git-codereview` the recommended path for those not familiar with git, or power users. * Make plain git the recommended path for those familiar with git, with a suggestion to check out `git-codereview`. * Offer the pre-commit hook at a URL that can be curl'd like how the [commit-msg hook is available](http://go-review.googlesource.com/tools/hooks/commit-msg) so that it's simple for developers to install the commit hooks how they would any others for other projects. I've got a branch with changes to the contributing doc that I made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable. I'd love to be involved with improving the guidelines in this way if this is something that the community agrees with.",1.0,"doc: clearer plain git contributing guidelines - ### What: Change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git. ### What it is not: This issue is not a request or proposal to replace Gerrit or the review process. This issue is not a request or proposal to remove the `git-codereview` tool or to make drastic changes to how anyone on the Go team or existing contributors go about contributing. ### Why: There are other open issues proposing a switch to GitHub (#21956), or adding the ability to support pushing via GitHub (#18517). Based on my own experience I think much of the friction that GitHub users are experiencing is caused by the contributing guidelines centering around `git-codereview`, which abstracts git away from the developer. Abstracting git away from developers is jarring when developers know how to use that tool already. It gives them the experience that they are using something that is entirely different to what they use today, even though it is not. ### Context: I recently submitted my [first](https://go-review.googlesource.com/c/go/+/73890) [contribution](https://go-review.googlesource.com/c/go/+/73891) to Go and was surprised at how straight forward and refreshing Gerrit was in comparison to GitHub. I had delayed contributing because the process described at https://golang.org/doc/contribute.html appeared so different to what I was use to. In practice it wasn't. It only appeared that way because there was a layer of abstraction. Before contributing the main point of friction for me wasn't the use of Gerrit vs GitHub, but the fact that all of the examples centered around the use of `git-codereview`, a custom tool for interacting with the Go Gerrit instance. I realize this tool is optional, but it took time to read all of the text and note down which git commands each `git-codereview` command actually used. At the end it came down to: 1. Install two hooks 2. `git clone` 3. `git pull -r` 4. `git checkout -b ` 5. `git commit` 6. `git push -u origin HEAD:refs/for/master` (patch set 1) 7. `git commit --amend` 8. `git push -u origin HEAD:refs/for/master` (patch set 2) The above is almost identical to the workflows I use at work and on open source on GitHub, and it is instantly familiar to me as a git user. The contribution guidelines tell a different story: 1. `git codereview hooks` 2. `git clone` 3. `git sync` 4. `git change` 5. `git mail` (patch set 1) 6. `git change` (to amend) 7. `git mail` (patch set 2) While the above is technically less commands, it's four new commands that I had never seen before and had to learn about. These commands abstract git away from plain git users, unnecessarily. ### How: Some ideas for how the contributing guidelines document could be made more familiar to plain git users: * Replace examples using `git-codereview` with plain git commands where the corresponding git commands are simple and straight forward. e.g. `git sync` vs `git pull -r`, `git push` vs `git mail`, etc. * Display plain git commands side-by-side (not one after the other) in the same size, font, weight, etc. * Make `git-codereview` the recommended path for those not familiar with git, or power users. * Make plain git the recommended path for those familiar with git, with a suggestion to check out `git-codereview`. * Offer the pre-commit hook at a URL that can be curl'd like how the [commit-msg hook is available](http://go-review.googlesource.com/tools/hooks/commit-msg) so that it's simple for developers to install the commit hooks how they would any others for other projects. I've got a branch with changes to the contributing doc that I made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable. I'd love to be involved with improving the guidelines in this way if this is something that the community agrees with.",1,doc clearer plain git contributing guidelines what change the contributing guidelines document to make the recommended process more familiar and obvious to users of plain git what it is not this issue is not a request or proposal to replace gerrit or the review process this issue is not a request or proposal to remove the git codereview tool or to make drastic changes to how anyone on the go team or existing contributors go about contributing why there are other open issues proposing a switch to github or adding the ability to support pushing via github based on my own experience i think much of the friction that github users are experiencing is caused by the contributing guidelines centering around git codereview which abstracts git away from the developer abstracting git away from developers is jarring when developers know how to use that tool already it gives them the experience that they are using something that is entirely different to what they use today even though it is not context i recently submitted my to go and was surprised at how straight forward and refreshing gerrit was in comparison to github i had delayed contributing because the process described at appeared so different to what i was use to in practice it wasn t it only appeared that way because there was a layer of abstraction before contributing the main point of friction for me wasn t the use of gerrit vs github but the fact that all of the examples centered around the use of git codereview a custom tool for interacting with the go gerrit instance i realize this tool is optional but it took time to read all of the text and note down which git commands each git codereview command actually used at the end it came down to install two hooks git clone git pull r git checkout b git commit git push u origin head refs for master patch set git commit amend git push u origin head refs for master patch set the above is almost identical to the workflows i use at work and on open source on github and it is instantly familiar to me as a git user the contribution guidelines tell a different story git codereview hooks git clone git sync git change git mail patch set git change to amend git mail patch set while the above is technically less commands it s four new commands that i had never seen before and had to learn about these commands abstract git away from plain git users unnecessarily how some ideas for how the contributing guidelines document could be made more familiar to plain git users replace examples using git codereview with plain git commands where the corresponding git commands are simple and straight forward e g git sync vs git pull r git push vs git mail etc display plain git commands side by side not one after the other in the same size font weight etc make git codereview the recommended path for those not familiar with git or power users make plain git the recommended path for those familiar with git with a suggestion to check out git codereview offer the pre commit hook at a url that can be curl d like how the so that it s simple for developers to install the commit hooks how they would any others for other projects i ve got a branch with changes to the contributing doc that i made to experiment with these ideas and to confirm if focusing on plain git commands would make it appear more familiar and approachable i d love to be involved with improving the guidelines in this way if this is something that the community agrees with ,1 41126,6892208147.0,IssuesEvent,2017-11-22 20:01:44,golang/go,https://api.github.com/repos/golang/go,closed,net/rpc: data race on non-net transport,Documentation HelpWanted,"
Here is the reproducer:
https://golang.org/cl/10613043/diff/3001/src/pkg/net/rpc/server_test.go

Report is below.

The gist: it's impossible to use net/rpc client/server with any non-thread-safe
transport as pipe or socketpair. It's inevitably produces races between read/write and
close. Such races corrupt arbitrary files and write data to random network connections.

=== RUN TestUnixPipe
==================
WARNING: DATA RACE
Read by goroutine 59:
  os.(*File).read()
      src/pkg/os/file_unix.go:175 +0x5b
  os.(*File).Read()
      src/pkg/os/file.go:95 +0xb9
  bufio.(*Reader).fill()
      src/pkg/bufio/bufio.go:119 +0x272
  bufio.(*Reader).Read()
      src/pkg/bufio/bufio.go:187 +0x3b1
  io.ReadAtLeast()
      src/pkg/io/io.go:284 +0x11a
  io.ReadFull()
      src/pkg/io/io.go:302 +0x7c
  encoding/gob.decodeUintReader()
      src/pkg/encoding/gob/decode.go:65 +0xba
  encoding/gob.(*Decoder).recvMessage()
      src/pkg/encoding/gob/decoder.go:73 +0x81
  encoding/gob.(*Decoder).decodeTypeSequence()
      src/pkg/encoding/gob/decoder.go:159 +0x92
  encoding/gob.(*Decoder).DecodeValue()
      src/pkg/encoding/gob/decoder.go:223 +0x124
  encoding/gob.(*Decoder).Decode()
      src/pkg/encoding/gob/decoder.go:202 +0x227
  net/rpc.(*gobClientCodec).ReadResponseHeader()
      src/pkg/net/rpc/client.go:218 +0x5d
  net/rpc.(*Client).input()
      src/pkg/net/rpc/client.go:106 +0x118

Previous write by goroutine 57:
  os.(*file).close()
      src/pkg/os/file_unix.go:110 +0x164
  os.(*File).Close()
      src/pkg/os/file_unix.go:99 +0x43
  net/rpc.(*gobClientCodec).Close()
      src/pkg/net/rpc/client.go:226 +0x48
  net/rpc.(*Client).Close()
      src/pkg/net/rpc/client.go:280 +0xc6
  net/rpc.TestUnixPipe()
      src/pkg/net/rpc/server_test.go:567 +0x3d5
  testing.tRunner()
      src/pkg/testing/testing.go:361 +0x10c

Goroutine 59 (running) created at:
  net/rpc.NewClientWithCodec()
      src/pkg/net/rpc/client.go:196 +0xd5
  net/rpc.NewClient()
      src/pkg/net/rpc/client.go:186 +0x18d
  net/rpc.TestUnixPipe()
      src/pkg/net/rpc/server_test.go:566 +0x3c7
  testing.tRunner()
      src/pkg/testing/testing.go:361 +0x10c

Goroutine 57 (running) created at:
  testing.RunTests()
      src/pkg/testing/testing.go:441 +0xaef
  testing.Main()
      src/pkg/testing/testing.go:373 +0xab
  main.main()
      net/rpc/_test/_testmain.go:74 +0xda
==================
",1.0,"net/rpc: data race on non-net transport - 
Here is the reproducer:
https://golang.org/cl/10613043/diff/3001/src/pkg/net/rpc/server_test.go

Report is below.

The gist: it's impossible to use net/rpc client/server with any non-thread-safe
transport as pipe or socketpair. It's inevitably produces races between read/write and
close. Such races corrupt arbitrary files and write data to random network connections.

=== RUN TestUnixPipe
==================
WARNING: DATA RACE
Read by goroutine 59:
  os.(*File).read()
      src/pkg/os/file_unix.go:175 +0x5b
  os.(*File).Read()
      src/pkg/os/file.go:95 +0xb9
  bufio.(*Reader).fill()
      src/pkg/bufio/bufio.go:119 +0x272
  bufio.(*Reader).Read()
      src/pkg/bufio/bufio.go:187 +0x3b1
  io.ReadAtLeast()
      src/pkg/io/io.go:284 +0x11a
  io.ReadFull()
      src/pkg/io/io.go:302 +0x7c
  encoding/gob.decodeUintReader()
      src/pkg/encoding/gob/decode.go:65 +0xba
  encoding/gob.(*Decoder).recvMessage()
      src/pkg/encoding/gob/decoder.go:73 +0x81
  encoding/gob.(*Decoder).decodeTypeSequence()
      src/pkg/encoding/gob/decoder.go:159 +0x92
  encoding/gob.(*Decoder).DecodeValue()
      src/pkg/encoding/gob/decoder.go:223 +0x124
  encoding/gob.(*Decoder).Decode()
      src/pkg/encoding/gob/decoder.go:202 +0x227
  net/rpc.(*gobClientCodec).ReadResponseHeader()
      src/pkg/net/rpc/client.go:218 +0x5d
  net/rpc.(*Client).input()
      src/pkg/net/rpc/client.go:106 +0x118

Previous write by goroutine 57:
  os.(*file).close()
      src/pkg/os/file_unix.go:110 +0x164
  os.(*File).Close()
      src/pkg/os/file_unix.go:99 +0x43
  net/rpc.(*gobClientCodec).Close()
      src/pkg/net/rpc/client.go:226 +0x48
  net/rpc.(*Client).Close()
      src/pkg/net/rpc/client.go:280 +0xc6
  net/rpc.TestUnixPipe()
      src/pkg/net/rpc/server_test.go:567 +0x3d5
  testing.tRunner()
      src/pkg/testing/testing.go:361 +0x10c

Goroutine 59 (running) created at:
  net/rpc.NewClientWithCodec()
      src/pkg/net/rpc/client.go:196 +0xd5
  net/rpc.NewClient()
      src/pkg/net/rpc/client.go:186 +0x18d
  net/rpc.TestUnixPipe()
      src/pkg/net/rpc/server_test.go:566 +0x3c7
  testing.tRunner()
      src/pkg/testing/testing.go:361 +0x10c

Goroutine 57 (running) created at:
  testing.RunTests()
      src/pkg/testing/testing.go:441 +0xaef
  testing.Main()
      src/pkg/testing/testing.go:373 +0xab
  main.main()
      net/rpc/_test/_testmain.go:74 +0xda
==================
",1,net rpc data race on non net transport here is the reproducer a href report is below the gist it s impossible to use net rpc client server with any non thread safe transport as pipe or socketpair it s inevitably produces races between read write and close such races corrupt arbitrary files and write data to random network connections run testunixpipe warning data race read by goroutine os file read src pkg os file unix go os file read src pkg os file go bufio reader fill src pkg bufio bufio go bufio reader read src pkg bufio bufio go io readatleast src pkg io io go io readfull src pkg io io go encoding gob decodeuintreader src pkg encoding gob decode go encoding gob decoder recvmessage src pkg encoding gob decoder go encoding gob decoder decodetypesequence src pkg encoding gob decoder go encoding gob decoder decodevalue src pkg encoding gob decoder go encoding gob decoder decode src pkg encoding gob decoder go net rpc gobclientcodec readresponseheader src pkg net rpc client go net rpc client input src pkg net rpc client go previous write by goroutine os file close src pkg os file unix go os file close src pkg os file unix go net rpc gobclientcodec close src pkg net rpc client go net rpc client close src pkg net rpc client go net rpc testunixpipe src pkg net rpc server test go testing trunner src pkg testing testing go goroutine running created at net rpc newclientwithcodec src pkg net rpc client go net rpc newclient src pkg net rpc client go net rpc testunixpipe src pkg net rpc server test go testing trunner src pkg testing testing go goroutine running created at testing runtests src pkg testing testing go testing main src pkg testing testing go main main net rpc test testmain go ,1 16497,6217791642.0,IssuesEvent,2017-07-08 18:18:57,golang/go,https://api.github.com/repos/golang/go,opened,x/build/devapp: HelpWanted handler supports title prefix filtering ,Builders,"https://dev.golang.org/imfeelinghelpful is pretty useful for those who are trying to randomly help to open issues. But individuals often specialize in a few packages and it would be nice to be able to filter the HelpWanted issues by title prefixes. For example, the following query can only return `cmd/go` and `go/parser` issues. ``` https://dev.golang.org/imfeelinghelpful?pkg=cmd/go,go/parser ``` Then, I can all day long browse random issues related to the packages I am interested to maintain. /cc @andybons @bradfitz ",1.0,"x/build/devapp: HelpWanted handler supports title prefix filtering - https://dev.golang.org/imfeelinghelpful is pretty useful for those who are trying to randomly help to open issues. But individuals often specialize in a few packages and it would be nice to be able to filter the HelpWanted issues by title prefixes. For example, the following query can only return `cmd/go` and `go/parser` issues. ``` https://dev.golang.org/imfeelinghelpful?pkg=cmd/go,go/parser ``` Then, I can all day long browse random issues related to the packages I am interested to maintain. /cc @andybons @bradfitz ",0,x build devapp helpwanted handler supports title prefix filtering is pretty useful for those who are trying to randomly help to open issues but individuals often specialize in a few packages and it would be nice to be able to filter the helpwanted issues by title prefixes for example the following query can only return cmd go and go parser issues then i can all day long browse random issues related to the packages i am interested to maintain cc andybons bradfitz ,0 43197,7031691134.0,IssuesEvent,2017-12-26 19:51:53,golang/go,https://api.github.com/repos/golang/go,closed,tools/present: Documentation link to sam documentation is dead,Documentation,"The documentation for the [`tools/present` tool](https://godoc.org/golang.org/x/tools/present) includes a link to http://plan9.bell-labs.com/sys/doc/sam/sam.html, which according to me and according to http://downforeveryoneorjustme.com/plan9.bell-labs.com cannot be reached. This means it's hard to find out how the `.code` _address syntax_ works.",1.0,"tools/present: Documentation link to sam documentation is dead - The documentation for the [`tools/present` tool](https://godoc.org/golang.org/x/tools/present) includes a link to http://plan9.bell-labs.com/sys/doc/sam/sam.html, which according to me and according to http://downforeveryoneorjustme.com/plan9.bell-labs.com cannot be reached. This means it's hard to find out how the `.code` _address syntax_ works.",1,tools present documentation link to sam documentation is dead the documentation for the includes a link to which according to me and according to cannot be reached this means it s hard to find out how the code address syntax works ,1 75480,9856121863.0,IssuesEvent,2019-06-19 21:11:16,golang/go,https://api.github.com/repos/golang/go,closed,wiki: CodeReviewComments#NamedResultParameters,Documentation NeedsDecision,"> On the other hand, [...] if the meaning of a result isn't clear from context, adding names may be useful in some contexts. In general, this will almost always be true. Humans are extremely bad at assessing how obvious an inference is if they already know the fact to be inferred. This is a special case of the [illusion of transparency](https://en.wikipedia.org/wiki/Illusion_of_transparency). In general, the meaning of a result isn't clear from context even if it feels to the author like it's extremely clear from context. Because of this, the advice given in this section is harmful in most cases.",1.0,"wiki: CodeReviewComments#NamedResultParameters - > On the other hand, [...] if the meaning of a result isn't clear from context, adding names may be useful in some contexts. In general, this will almost always be true. Humans are extremely bad at assessing how obvious an inference is if they already know the fact to be inferred. This is a special case of the [illusion of transparency](https://en.wikipedia.org/wiki/Illusion_of_transparency). In general, the meaning of a result isn't clear from context even if it feels to the author like it's extremely clear from context. Because of this, the advice given in this section is harmful in most cases.",1,wiki codereviewcomments namedresultparameters on the other hand if the meaning of a result isn t clear from context adding names may be useful in some contexts in general this will almost always be true humans are extremely bad at assessing how obvious an inference is if they already know the fact to be inferred this is a special case of the in general the meaning of a result isn t clear from context even if it feels to the author like it s extremely clear from context because of this the advice given in this section is harmful in most cases ,1 35128,6415848860.0,IssuesEvent,2017-08-08 13:41:39,golang/go,https://api.github.com/repos/golang/go,closed,wiki: apt-get install golang-1.8-go: did not work,Documentation,"### What operating system and processor architecture are you using (`go env`)? ubuntu 16.x ### What did you do? provision vagrant box to run some go app, ``` $provision = <