Roland Shoemaker [Wed, 5 Jul 2023 18:56:03 +0000 (11:56 -0700)]
html/template: support parsing complex JS template literals
This change undoes the restrictions added in CL 482079, which added a
blanket ban on using actions within JS template literal strings, and
adds logic to support actions while properly applies contextual escaping
based on the correct context within the literal.
Since template literals can contain both normal strings, and nested JS
contexts, logic is required to properly track those context switches
during parsing.
ErrJsTmplLit is deprecated, and the GODEBUG flag jstmpllitinterp no
longer does anything.
Fixes #61619
Change-Id: I0338cc6f663723267b8f7aaacc55aa28f60906f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/507995
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Jonathan Amsterdam [Wed, 20 Sep 2023 19:45:08 +0000 (15:45 -0400)]
log/slog: JSONHandler elides empty groups even with replacement
Previously, the built-in handlers assumed a group was empty if and
only if it had no attributes. But a ReplaceAttr function that
returned an empty Attr could produce an empty group even if the group
had attrs prior to replacement.
The obvious solution, doing the replacement first and then checking,
would require allocating storage to hold the replaced Attrs. Instead,
we write to the buffer, and if no attributes were written, we back up
to before the group name.
Fixes #62512.
Change-Id: I140e0901f4b157e36594d8d476f1ab326f8f2c2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/529855
Run-TryBot: Jonathan Amsterdam <jba@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Than McIntosh [Thu, 7 Sep 2023 15:06:35 +0000 (11:06 -0400)]
internal,cmd/internal: relocate covcmd package from std to cmd
Relocate the 'covcmd' package from .../internal/coverage to
.../cmd/internal/cov, to reflect the fact that the definitions in this
package are used only in cmd, not in std.
Than McIntosh [Tue, 16 May 2023 17:31:11 +0000 (13:31 -0400)]
cmd/go: fix percent covered problems with -coverpkg
This patch fixes some problems with how "go test -cover" was handling
tests involving A) multiple package tests and B) multiple packages
matched by "-coverpkg". In such scenarios the expectation is that the
percent statements covered metric for each package needs to be
relative to all statements in all packages matched by the -coverpkg
arg (this aspect of the reporting here was broken as part of
GOEXPERIMENT=coverageredesign).
The new scheme works as follows. If -coverpkg is in effect and is
matching multiple packages, and we have multiple test targets, then:
- each time a package is built for coverage, capture a meta-data
file fragment corresponding to just the meta-data for that package.
- create a new "writeCoverMeta" action, and interpose it between the
build actions for the covered packages and the run actions. The
"writeCoverMeta" action at runtime will emit a file
"metafiles.txt" containing a table mapping each covered package
(by import path) to its corresponding meta-data file fragment.
- pass in the "metafiles.txt" file to each run action, so that
when the test finishes running it will have an accurate picture
of _all_ covered packages, permitting it to calculate the correct
percentage.
Concrete example: suppose we have a top level directory with three
package subdirs, "a", "b", and "c", and from the top level, a user
runs "go test -coverpkg=./... ./...". This will result in (roughly)
the following action graph:
A note on init functions: prior to GOEXPERIMENT=coverageredesign
the "-coverpkg=..." flag was implemented by force-importing
all packages matched by "-coverpkg" into each instrumented package.
This meant that for the example above, when executing "a.test",
the init function for package "c" would fire even if package "a"
did not ordinarily import package "c". The new implementation
does not do this sort of forced importing, meaning that the coverage
percentages can be slightly different between 1.21 and 1.19 if
there are user-written init funcs.
Than McIntosh [Tue, 9 May 2023 19:40:41 +0000 (15:40 -0400)]
cmd/go: improve handling of no-test packages for coverage
This patch improves the way the go command handles coverage testing
of packages that have functions but don't have any test files. Up to
this point if you ran "go test -cover" on such a package, you would
see:
? mymod/mypack [no test files]
While "no test files" is true, it is also very unhelpful; if the
package contains functions, it would be better instead to capture the
fact that these functions are not executed when "go test -cover" is
run on the package.
With this patch, for the same no-test package "go test -cover" will
output:
mymod/mypack coverage: 0.0% of statements
The inclusion of such packages in coverage reporting also extends to
"-coverprofile" as well (we'll see entries for the "mypack" functions
in this case.
Note that if a package has no functions at all, then we'll still fall
back to reporting "no test files" in this case; it doesn't make sense
to report "0.0% statements covered" if there are no statements.
Than McIntosh [Fri, 29 Sep 2023 18:19:17 +0000 (14:19 -0400)]
cmd/link: split text sections for arm 32-bit
This CL is a roll-forward (tweaked slightly) of CL 467715, which
turned on text section splitting for GOARCH=arm. The intent is to
avoid recurrent problems with external linking where there is a
disagreement between the Go linker and the external linker over
whether a given branch will reach. In the past our approach has been
to tweak the reachability calculations slightly to try to work around
potential linker problems, but this hasn't proven to be very robust;
section splitting seems to offer a better long term fix.
Fixes #58425.
Change-Id: I7372d41abce84097906a3d0805b6b9c486f345d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/531795 Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Jes Cok [Fri, 29 Sep 2023 06:06:40 +0000 (06:06 +0000)]
syscall: make origRlimitNofile atomic.Pointer[Rlimit]
Currently we are bootstrapping with Go 1.20, origRlimitNofile can
be changed to atomic.Pointer[Rlimit].
Change-Id: I00ce9d1a9030bd5dbd34e3dc6c4e38683a87be86
GitHub-Last-Rev: f2ccdb38412019d10661ed6be42086b445e411bf
GitHub-Pull-Request: golang/go#63274
Reviewed-on: https://go-review.googlesource.com/c/go/+/531516
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Paul E. Murphy [Tue, 12 Sep 2023 20:39:56 +0000 (15:39 -0500)]
cmd/internal/obj/ppc64: fix rebuilding of optab for asm tests
The end-to-end asm tests reinitialize the assembler using different
GOPPC64 values. This caused duplicate entries to amass from the
prefix and generated optab entries. This bug only affects the
asm end-to-end tests.
On reinitialization, optab contains the previous prefixedOptab
and optabGen entries, not just the initial values. Rework the
initialization to avoid the stale optab entries.
Change-Id: I310499915a5272ed0174ed8135d60788e6b4b716
Reviewed-on: https://go-review.googlesource.com/c/go/+/528316 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Alexander Yastrebov [Thu, 28 Sep 2023 22:26:57 +0000 (22:26 +0000)]
internal/zstd: reset reader buffer
Reset r.buffer on Reset to avoid subsequent Read calls
observing previously decoded data.
For #62513
Change-Id: Icb65e76b5c5c0af32b36ec3a5999dca86407cbc8
GitHub-Last-Rev: 99c0a6fa72ad67cba5d29593fd3b28d14ddce4a4
GitHub-Pull-Request: golang/go#63288
Reviewed-on: https://go-review.googlesource.com/c/go/+/531735
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Daniel Martí [Sun, 24 Sep 2023 13:41:10 +0000 (14:41 +0100)]
path/filepath: reuse os.ReadDir
While reading the source code, I noticed that readDir
seemed extremely similar to os.ReadDir. They indeed appear to be copies.
Note that there's readDirNames as well, but it has no corresponding
os.ReadDirNames top-level helper to be replaced by.
Change-Id: I6fe1d0aeda35dc69bb4531986fe3a21ebda1d877
Reviewed-on: https://go-review.googlesource.com/c/go/+/530795 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
syscall: simplify and optimize environment block creation on Windows
createEnvBlock currently allocates multiple times: at least one to
convert the slice of strings into a NULL separated slice of bytes, and
then again to encode it as UTF-16. The logic to do so is also quite
complex.
This CL simplifies the logic by allocating only once by encoding the
slice of strings into UTF-16 directly using utf16.AppendRune.
goos: windows
goarch: amd64
pkg: syscall
cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
CreateEnvBlock-12 37.92µ ± 24% 21.36µ ± 8% -43.66% (p=0.000 n=10)
Alexander Yastrebov [Wed, 27 Sep 2023 15:25:40 +0000 (15:25 +0000)]
internal/zstd: handle match extending past window
For #62513
Change-Id: I59c24b254d5073140811b41497eabb91fb0046e9
GitHub-Last-Rev: 4dd16fcfa813da2b612d5753e11c163476d44b53
GitHub-Pull-Request: golang/go#63248
Reviewed-on: https://go-review.googlesource.com/c/go/+/531255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Alexander Yastrebov [Wed, 27 Sep 2023 23:53:37 +0000 (23:53 +0000)]
internal/zstd: allow zero dictionary id
A value of 0 has same meaning as no Dictionary_ID,
in which case the frame may or may not need a dictionary to be decoded,
and the ID of such a dictionary is not specified.
See https://github.com/facebook/zstd/issues/2172
For #62513
Change-Id: If0eafcbc5d2188576f0cb687234e30c9eb4037a6
GitHub-Last-Rev: 9cf12dcf194a90367a74b808bbe464815f71f42a
GitHub-Pull-Request: golang/go#63268
Reviewed-on: https://go-review.googlesource.com/c/go/+/531515
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
As best as I can tell, it is another instance of #38370. The deferred
call to backend.close() ought to be enough to ensure that the t.Logf
happens before the end of the test, but in practice it is not, and
with enough scheduling delay we can manage to trip the race detector
on a call to Logf after the test function has returned.
Updates #38370.
Change-Id: I5ee45df45c6bfad3239d665df65a138f1c4573a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/531195
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Adam Cmiel [Tue, 19 Sep 2023 07:22:26 +0000 (07:22 +0000)]
cmd/go: make malformed go.sum a fatal error
In CL 197062, many errors related to go.sum were changed from base.Fatal
to error returns. The malformed go.sum error was lost in the process.
Currently, when go encounters a malformed go.sum file, go will read the
well-formed part of the file and then silently ignore the rest.
The motivation behind moving away from base.Fatal was to make the errors
show up in -json output. Simply propagating the malformed go.sum error
would not achieve this:
- For an argument-less 'go mod download -json' with a go>=1.17 module,
a malformed go.sum causes an error during LoadModGraph already, before
go ever starts downloading modules and printing their JSON.
- In other cases, a malformed go.sum would be reported as Error for one
of the modules (presumably the one which gets downloaded first) but
none of the others.
- In either case, 'go mod download' manages to download enough data to
succeed on a re-run, making the error look intermittent.
Switch the error back to a Fatal one, but give 'go mod tidy' an
exception to let it fix broken go.sum files.
Jes Cok [Sat, 23 Sep 2023 04:15:40 +0000 (04:15 +0000)]
go/build/constraint: delete, replace stringsCut calls with strings.Cut
Currently, the Go bootstrap toolchain is bumped to 1.20.
Change-Id: I6467768c0640a8e9aadbfea79cfdfb14b4b80679
GitHub-Last-Rev: 7cf2d54a4865b4c6c15af374a6c0fbdbcce8c3b6
GitHub-Pull-Request: golang/go#63174
Reviewed-on: https://go-review.googlesource.com/c/go/+/530676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Kir Kolyshkin [Fri, 22 Sep 2023 20:42:50 +0000 (13:42 -0700)]
log/slog: fix time regexp in test
CL 525556 started using timeRE regexp to match time output from JSON
handler, and relaxed it to allow arbitrary (rather than fixed 3 digit)
precision.
What it missed is in JSON handler the fractional part is omitted
entirely (together with the decimal dot) when the nanoseconds field is
0.
As a result, there are occasional CI failures in js/wasm (which, I guess,
has better chances to return zero nanoseconds).
To fix the flaky test, let's use two different regular expressions,
tailored to text and JSON.
Change-Id: Ie98990fcf278bb0916ab31c9177e6b22a523062a
Reviewed-on: https://go-review.googlesource.com/c/go/+/530675
Run-TryBot: Kirill Kolyshkin <kolyshkin@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Andy Pan <panjf2000@gmail.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
Jonathan Amsterdam [Mon, 25 Sep 2023 13:22:48 +0000 (09:22 -0400)]
log/slog: ensure ReplaceAttr does not see a group
The ReplaceAttr function should not see groups, only leaf attributes.
Previously, we checked an Value for being a group, then resolved it,
then called ReplaceAttr. We neglected to see if it was a group
after resolving it.
Now we resolve first, then check.
Fixes #62731.
Change-Id: I2fc40758e77c445f82deb2c9de8cae7a3b0e22cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/530478 Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I1553de35d5ebd9c7df9727242e888de91caca4ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/527095
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tim King <taking@google.com> Reviewed-by: Tim King <taking@google.com>
Holger Hans Peter Freyther [Sun, 24 Sep 2023 12:05:37 +0000 (12:05 +0000)]
cmd/go: permit additional cflags when compiling
In CL 475375 the Go command started to generate the "preferlinkext"
token file for "strange/dangerous" compiler flags. This serves as a hint
to the Go linker whether to call the external linker or not.
Permit compiler flags used by bazel and bazelbuild/rules_go during
compilation of cgo code to not prefer external linking. This restores
the behavior of previous versions of Go.
As a side effect, it also allows these flags to appear
in #cgo directives in source code. We don't know of any cases
where that is actually useful, but it appears to be harmless
and simplifies the implementation of the internal linking change.
Jonathan Amsterdam [Fri, 22 Sep 2023 19:57:46 +0000 (15:57 -0400)]
net/http: unescape paths and patterns by segment
When parsing patterns and matching, split the path into segments at
slashes, then unescape each segment.
This behaves as most people would expect:
- The pattern "/%61" matches the paths "/a" and "/%61".
- The pattern "/%7B" matches the path "/{". (If we did not unescape
patterns, there would be no way to write that pattern: because "/{"
is a parse error because it is an invalid wildcard.)
- The pattern "/user/{u}" matches "/user/john%2Fdoe" with u set to
"john/doe".
- The unexpected redirections of #21955 will not occur.
A later CL will restore the old behavior behind a GODEBUG setting.
Updates #61410.
Fixes #21955.
Change-Id: I99025e149021fc94bf87d351699270460db532d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/530575
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Carl Johnson [Fri, 22 Sep 2023 21:03:27 +0000 (21:03 +0000)]
cmp: add Or
Fixes #60204
Change-Id: I1234cacf0f25097d034038bcfb33f6630373a057
GitHub-Last-Rev: e9098ed8b3dd9125661e4340ffe01d846670ba0f
GitHub-Pull-Request: golang/go#60931
Reviewed-on: https://go-review.googlesource.com/c/go/+/504883
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Jes Cok [Fri, 22 Sep 2023 23:27:51 +0000 (23:27 +0000)]
all: use the indefinite article an in comments
Change-Id: I8787458f9ccd3b5cdcdda820d8a45deb4f77eade
GitHub-Last-Rev: be865d67ef68815b8c1c2a9ad222fff594620e66
GitHub-Pull-Request: golang/go#63165
Reviewed-on: https://go-review.googlesource.com/c/go/+/530120
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Ian Lance Taylor [Wed, 20 Sep 2023 22:15:45 +0000 (15:15 -0700)]
fmt: clarify that we don't call String for %#v
Change-Id: I4edf8bd6f9ab813acf1d05c603f6f562fa00cb48
Reviewed-on: https://go-review.googlesource.com/c/go/+/529975
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Rob Pike [Sat, 16 Sep 2023 05:22:44 +0000 (15:22 +1000)]
runtime: reword the documentation for Pinner
I found the documentation for Pinner itself to contain too little information.
Rewrite it to give a summary and redirect to the relevant methods.
Also reformat the ragged comment for Pin.
Change-Id: I9c786817f43dfc9c72178127c141c35dae221104
Reviewed-on: https://go-review.googlesource.com/c/go/+/528855 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
SECURITY.md: update the Reporting a Vulnerability link
The https://go.dev/security is about: "This page provides
resources for Go developers to improve security for their
projects.", https://go.dev/security/policy is about Go Security Policy.
go.dev/security links to go.dev/security/policy,
but I think it is better to link directly to go.dev/security/policy
in this case.
Change-Id: Ic6515961dc48055236bb06cc814072caa10a8f54
GitHub-Last-Rev: 37ac8ab440a42679833b67ce96b7fd19ecac6ca3
GitHub-Pull-Request: golang/go#63163
Reviewed-on: https://go-review.googlesource.com/c/go/+/530119
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
Ian Lance Taylor [Fri, 22 Sep 2023 20:24:37 +0000 (13:24 -0700)]
slices: use strings.EqualFold in ExampleCompactFunc
Change-Id: Ie7d495b2a53520ce89b16bc8a66b81a3955bf32f
Reviewed-on: https://go-review.googlesource.com/c/go/+/530635 Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
reflect: remove broken support for embedding of interfaces from StructOf.
When reviewing https://go-review.googlesource.com/c/go/+/522435,
Cherry Mui cherryyz@google.com noticed that the implementation of
StructOf was broken, and produced junk if an interface was embedded
into a struct. For example, StructOf messed up the calling convention
for methods of the embedded interface:
> The main problem is that the method wrappers created by reflect.MakeFunc
> expects to be called with a closure calling convention, with a closure
> context passed in the context register. But methods are called with
> a different calling convention, without setting the closure register,
> because (besides this case) all methods are top level functions.
> So there is no way to pass that makefunc closure context.
It is curious that StructOf did not break in go 1.17 which introduced
the regabi. I've tried to run the following example program, and it
fails even in 1.7 which introduced StructOf.
As the embedding of interfaces has been broken since forever,
let us not perpetuate the complexity that this feature brings,
and just remove the support for embedding altogether.
The test program:
package main
import (
"fmt"
"reflect"
)
type I interface {
F()
}
type T int
func (t T) F() { println(t) }
func main() {
var i I
t := reflect.StructOf([]reflect.StructField{
{
Anonymous: true,
Name: "I",
Type: reflect.TypeOf(&i).Elem(),
},
})
v := reflect.New(t).Elem()
v.Field(0).Set(reflect.ValueOf(T(42)))
fmt.Println(v)
v.Interface().(interface{ F() }).F() // fatal error
}
Change-Id: I7b2115c22d66ea4ed746f0f9d22b2c94f604e185
Reviewed-on: https://go-review.googlesource.com/c/go/+/526075
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Jes Cok [Tue, 19 Sep 2023 10:36:19 +0000 (10:36 +0000)]
all: clean unnecessary casts for test files
This is a follow up of CL 528696.
Change-Id: I5b71eabedb12567c4b1b36f7182a3d2b0ed662a5
GitHub-Last-Rev: acaf3ac11c38042ad27b99e1c70a3c9f1a554a15
GitHub-Pull-Request: golang/go#62713
Reviewed-on: https://go-review.googlesource.com/c/go/+/529197 Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Paul E. Murphy [Wed, 17 May 2023 18:26:11 +0000 (13:26 -0500)]
cmd/cgo/internal/test: test PPC64 ELFv2 call/plt stub generation
Verify functional stubs are inserted between TOC and NOTOC functions.
The implementation of the stub varies depending on -buildmode and
GOPPC64. Today, the type of stub generated by the internal linker
is roughly determined by the following
{GOPPC64 < 10, GOPPC64 >= 10} x {-buildmode=pie, -buildmode=default}
Change-Id: Ib9b3eef252bfcd357a476134d3503cb996bc285b
Reviewed-on: https://go-review.googlesource.com/c/go/+/496916
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Paul E. Murphy [Mon, 18 Sep 2023 16:29:20 +0000 (11:29 -0500)]
cmd/compile/internal/ssa: optimize (AND (MOVDconst [-1] x)) on PPC64
This sequence can show up in the lowering pass on PPC64. If it
makes it to the latelower pass, it will cause an error because
it looks like it can be turned into RLDICL, but -1 isn't an
accepted mask.
Also, print more debug info if panic is called from
encodePPC64RotateMask.
Fixes #62698
Change-Id: I0f3322e2205357abe7fc28f96e05e3f7ad65567c
Reviewed-on: https://go-review.googlesource.com/c/go/+/529195 Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Tim King [Thu, 21 Sep 2023 18:00:01 +0000 (11:00 -0700)]
cmd: go get golang.org/x/tools@f9b8da7 and revendor
go get golang.org/x/tools@f9b8da7 # CL 529915
go mod tidy
go mod vendor
Change-Id: Ib0824e66ab8889bfab438e79bf3f7bb4b4f45879
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/530175
Run-TryBot: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Tim King <taking@google.com>
Jes Cok [Wed, 20 Sep 2023 23:37:59 +0000 (23:37 +0000)]
runtime: no need to convert 'c.fault()' to uintptr in sighandler
After CL 528817, *sigctxt.fault of all arches return uintptr, so
there is no need to convert 'c.fault()' to uintptr anymore.
Change-Id: I062283b578adaaee69d8f439b109a573eeb15110
GitHub-Last-Rev: 3ce3a75a66557d1a8ff089fd532ac694bfa0104f
GitHub-Pull-Request: golang/go#63133
Reviewed-on: https://go-review.googlesource.com/c/go/+/529995 Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
runtime: implement usleep in Go instead of assembly on Windows
Windows APIs are normally not arch-specific, so it's better to
implement them in Go instead of assembly.
It was previously implemented in assembly because it was the only way
to support calls without a valid g. This CL defines a new function,
stdcall_no_g, that can be used in such cases.
While here, I've also replaced the use of the deprecated syscall
NtWaitForSingleObject with WaitForSingleObject. The former may
give the illusion of being more accurate, as it takes a higher
resolution timeout, but it's not. Windows time resolution is 15.6ms,
and can be as high as 1ms when using a high resolution timer, which
WaitForSingleObject supports.
Change-Id: I903400220ade4d4ccc15685c8da47182430f8686
Reviewed-on: https://go-review.googlesource.com/c/go/+/526477 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Ian Lance Taylor [Thu, 14 Sep 2023 20:36:38 +0000 (13:36 -0700)]
debug/elf: don't crash on empty symbol section
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
Fixes #62649
Change-Id: Ia40b4d415e3bbffaffd143ee280949ba41346579
Reviewed-on: https://go-review.googlesource.com/c/go/+/528655
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Kir Kolyshkin [Wed, 13 Sep 2023 01:46:45 +0000 (18:46 -0700)]
all: stop using fmt.Sprintf in t.Error/t.Fatal
Change-Id: Id63e1e5ae7e225e4a6a721673bf2d43b6c398c25
Reviewed-on: https://go-review.googlesource.com/c/go/+/527701 Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Kirill Che [Fri, 8 Sep 2023 07:51:47 +0000 (07:51 +0000)]
cmd/go: improve go build documentation
The existing documentation for `go help build` does not match the current behavior of `go build`. This commit fixes inconsistency between documentation and behavior as suggested in #60836 ticket.
Jes Cok [Sat, 16 Sep 2023 00:07:59 +0000 (00:07 +0000)]
runtime: unify the method signature for *sigctxt.fault
Currently, *sigctxt.fault of freebsd-arm64 and openbsd-arm64 return
uint64 which is different from other arches (return uintptr). Change
the method signature for consistency.
Change-Id: I81185123c1ea40e456075fd86b931aa860c38a42
GitHub-Last-Rev: 82934ecd3d2c712c2f47378e5b2c802427874d4d
GitHub-Pull-Request: golang/go#62672
Reviewed-on: https://go-review.googlesource.com/c/go/+/528817
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Oleksandr Redko [Wed, 6 Sep 2023 12:14:28 +0000 (15:14 +0300)]
all: simplify bool conditions
Change-Id: Id2079f7012392dea8dfe2386bb9fb1ea3f487a4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/526015 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Change-Id: Ic03fabfc575c5e6d18bcd5ba1c845aa502c12497
GitHub-Last-Rev: 16cb1e13ff61f0fc8c9209cb034f31ec6c37f596
GitHub-Pull-Request: golang/go#62625
Reviewed-on: https://go-review.googlesource.com/c/go/+/528318 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
runtime: implement osyield in Go instead of assembly on Windows
Windows APIs are normally not arch-specific, so it's better to
implement them in Go instead of assembly.
It was previously implemented in assembly because it was the only way
to support calls without a valid g. This CL defines a new function,
stdcall_no_g, that can be used in such cases.
net/http: eliminate a goroutine leak in (*persistConn.addTLS)
In case of a handshake timeout, the goroutine running addTLS
closes the underlying connection, which should unblock the call
to tlsConn.HandshakeContext. However, it didn't then wait for
HandshakeContext to actually return.
I thought this might have something to do with #57602, but as
far as I can tell it does not. Still, it seems best to avoid the leak:
if tracing is enabled we emit a TLSHandshakeDone event, and it seems
misleading to produce that event when the handshake is still in
progress.
For #57602.
Change-Id: Ibfc0cf4ef8df2ccf11d8897f23d7d79ee482d5fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/529755
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Commit-Queue: Bryan Mills <bcmills@google.com>
Cherry Mui [Wed, 16 Aug 2023 23:49:04 +0000 (19:49 -0400)]
cmd/link, runtime: initialize packages in shared build mode
Currently, for the shared build mode, we don't generate the module
inittasks. Instead, we rely on the main executable to do the
initialization, for both the executable and the shared library.
But, with the model as of CL 478916, the main executable only
has relocations to packages that are directly imported. It won't
see the dependency edges between packages within a shared library.
Therefore indirect dependencies are not included, and thus not
initialized. E.g. main imports a, which imports b, but main
doesn't directly import b. a and b are in a shared object. When
linking main, it sees main depends on a, so it generates main's
inittasks to run a's init before main's, but it doesn't know b,
so b's init doesn't run.
This CL makes it initialize all packages in a shared library when
the library is loaded, as any of them could potentially be
imported, directly or indirectly.
Also, in the runtime, when running the init functions, make sure
to go through the DSOs in dependency order. Otherwise packages
can be initialized in the wrong order.
Fixes #61973.
Change-Id: I2a090336fe9fa0d6c7e43912f3ab233c9c47e247
Reviewed-on: https://go-review.googlesource.com/c/go/+/520375 Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Jonathan Amsterdam [Tue, 19 Sep 2023 21:03:45 +0000 (17:03 -0400)]
net/http: test index exhaustively
Replace the fuzz test with one that enumerates all relevant patterns
up to a certain length.
For conflict detection, we don't need to check every possible method,
host and segment, only a few that cover all the possibilities. There
are only 2400 distinct patterns in the corpus we generate, and the
test generates, indexes and compares them all in about a quarter of a
second.
Change-Id: I9fde88e87cec07b1b244306119e4e71f7205bb77
Reviewed-on: https://go-review.googlesource.com/c/go/+/529556
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Michael Pratt [Fri, 8 Sep 2023 18:54:29 +0000 (14:54 -0400)]
runtime: set stackguard1 on extra M g0
[This is an unmodified redo of CL 527056.]
Standard Ms set g0.stackguard1 to the same value as stackguard0 in
mstart0. For consistency, extra Ms should do the same for their g0. Do
this in needm -> callbackUpdateSystemStack.
Background: getg().stackguard1 is used as the stack guard for the stack
growth prolouge in functions marked //go:systemstack [1]. User Gs set
stackguard1 to ^uintptr(0) so that the check always fail, calling
morestackc, which throws to report a //go:systemstack function call on a
user stack.
g0 setting stackguard1 is unnecessary for this functionality. 0 would be
sufficient, as g0 is always allowed to call //go:systemstack functions.
However, since we have the check anyway, setting stackguard1 to the
actual stack bound is useful to detect actual stack overflows on g0
(though morestackc doesn't detect this case and would report a
misleading message about user stacks).
[1] cmd/internal/obj calls //go:systemstack functions AttrCFunc. This is
a holdover from when the runtime contained actual C functions. But since
CL 2275, it has simply meant "pretend this is a C function, which would
thus need to use the system stack". Hence the name morestackc. At this
point, this terminology is pretty far removed from reality and should
probably be updated to something more intuitive.
Change-Id: If315677217354465fbbfbd0d406d79be20db0cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/527716
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Jonathan Amsterdam [Mon, 18 Sep 2023 19:51:04 +0000 (15:51 -0400)]
net/http: index patterns for faster conflict detection
Add an index so that pattern registration isn't always quadratic.
If there were no index, then every pattern that was registered would
have to be compared to every existing pattern for conflicts. This
would make registration quadratic in the number of patterns, in every
case.
The index in this CL should help most of the time. If a pattern has a
literal segment, it will weed out all other patterns that have a
different literal in that position.
The worst case will still be quadratic, but it is unlikely that a set
of such patterns would arise naturally.
One novel (to me) aspect of the CL is the use of fuzz testing on data
that is neither a string nor a byte slice. The test uses fuzzing to
generate a byte slice, then decodes the byte slice into a valid
pattern (most of the time). This test actually caught a bug: see
https://go.dev/cl/529119.
Change-Id: Ice0be6547decb5ce75a8062e4e17227815d5d0b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/529121
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
The riscv64 assembler and linker generate three types of calls.
Most calls are made via a single JAL instruction, however this is
limited to +/-1MB of text. In the case where a call target is
unreachable (or unknown), the JAL targets an AUIPC+JALR trampoline.
All other cases use AUIPC+JALR pairs, including the case where a
single function exceeds 1MB in text size, potentially making it
impossible to reach trampolines.
Currently, the single instruction JAL call is marked with R_RISCV_CALL
and the two instruction AUIPC+JALR call is marked with
R_RISCV_PCREL_ITYPE, which is also used for memory load instructions.
This means that we have no way to identify that the latter is a call.
Switch to using R_RISCV_CALL to mark the AUIPC+JALR pair (aligning
somewhat with the elf.R_RISCV_CALL, which is deprecated in favour of
elf.R_RISCV_CALL_PLT). Add R_RISCV_JAL and use this to mark the single
instruction JAL direct calls. This is clearer and allows us to map
elf.R_RISCV_CALL_PLT to Go's R_RISCV_CALL.
Add all three types to IsDirectCall, so that direct calls are correctly
identified when a function exceeds 1MB of text.
Fixes #62465
Change-Id: Id3eea09688a2b7d6e481eae9ed0aa0d1f9a3a48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/520095
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Than McIntosh <thanm@google.com>
net/http: buffer the testConn close channel in TestHandlerFinishSkipBigContentLengthRead
Previously the test used an unbuffered channel, but testConn.Close
sends to it with a select-with-default, so the send would be dropped
if the test goroutine happened not to have parked on the receive yet.
To make this kind of bug less likely in future tests, use a
newTestConn helper function instead of constructing testConn channel
literals in each test individually.
Fixes #62622.
Change-Id: I016cd0a89cf8a2a748ed57a4cdbd01a178f04dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/529475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Cherry Mui [Fri, 15 Sep 2023 16:13:09 +0000 (12:13 -0400)]
cmd/compile: add pgohash for debugging/bisecting PGO optimizations
When a PGO build fails or produces incorrect program, it is often
unclear what the problem is. Add pgo hash so we can bisect to
individual optimization decisions, which often helps debugging.
Related to #58153.
Change-Id: I651ffd9c53bad60f2f28c8ec2a90a3f532982712
Reviewed-on: https://go-review.googlesource.com/c/go/+/528400
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
CL 457995 introduced syscall_linux_accept.go which is used on linux/arm
to generate accept and use it in Accept. However, that CL forgot to
include the file in the list of files used with mksyscall.pl to generate
the syscall wrappers. This lead to accept no longer being generated when
re-running mkall.sh on linux/arm.
cmd/go: in TestScript/gotoolchain_path, remove the user's PATH
This test checks a behavior of GOTOOLCHAIN when an appropriate
toolchain is found in PATH. That requires it to exclude any suitable
toolchain binaries from the user's $PATH, which may otherwise
interfere.
Fixes #62709.
Change-Id: Ie9161e52d33a65be0b5265cb49e9f2bc8473e057
Reviewed-on: https://go-review.googlesource.com/c/go/+/529217
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Jonathan Amsterdam [Mon, 18 Sep 2023 17:55:42 +0000 (13:55 -0400)]
net/http: fix bugs in comparePaths and combineRelationships
combineRelationships was wrong on one case: if one part of a pattern
overlaps and the other is disjoint, the result is disjoint, not overlaps.
For example:
/a/{x}/c
/{x}/b/d
Here the prefix consisting of the first two segments overlaps, but the
third segments are disjoint. The patterns as a whole are disjoint.
comparePaths was wrong in a couple of ways:
First, the loop shouldn't exit early when it sees an overlap,
for the reason above: later information may change that.
Once the loop was allowed to continue, we had to handle the "overlaps"
case at the end. The insight there, which generalized the existing
code, is that if the shorter path ends in a multi, that multi matches
the remainder of the longer path and more. (It must be "and more": the
longer path has at least two segments, so it couldn't match one
segment while the shorter path's multi can.) That means we can treat
the result as the combination moreGeneral and the relationship of the
common prefix.
Change-Id: I11dab2c020d820730fb38296d9d6b072bd2a5350
Reviewed-on: https://go-review.googlesource.com/c/go/+/529119 Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
cmd/go: avoid writing non-JSON "build failed" errors from 'go test -json'
In 'go test -json' we expect stdout to contain only JSON events,
not unstructured text. Unstructured text should either go to stderr
or be wrapped in a JSON event.
(If we add structured build output in #62067, we can emit this output
as a build event instead of a test event.)
Jes Cok [Fri, 15 Sep 2023 21:15:56 +0000 (21:15 +0000)]
all: clean unnecessary casts
Run 'unconvert -safe -apply' (https://github.com/mdempsky/unconvert)
Change-Id: I24b7cd7d286cddce86431d8470d15c5f3f0d1106
GitHub-Last-Rev: 022e75384c08bb899a8951ba0daffa0f2e14d5a7
GitHub-Pull-Request: golang/go#62662
Reviewed-on: https://go-review.googlesource.com/c/go/+/528696
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Ian Lance Taylor [Sun, 17 Sep 2023 00:15:09 +0000 (17:15 -0700)]
doc/go1.22: correct tipo languague => language
Change-Id: I11d0947d6d2ffa91745c8e36a3984ffee85abbd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/528896
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Wed, 30 Aug 2023 14:06:18 +0000 (10:06 -0400)]
net: enable most tests on wasip1 and js
To get them to pass, implement more fake syscalls.
To make those syscalls easier to reason about, replace
the use of sync.Cond with selectable channels.
Fixes #59718.
Fixes #50216.
Change-Id: I135a6656f5c48f0e5c43dc4d4bcbdb48ee5535d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/526117
Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Achille Roussel <achille.roussel@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Thu, 7 Sep 2023 16:27:50 +0000 (09:27 -0700)]
context: avoid key collisions in test afterfunc map
The afterFuncContext type, used only in tests, contains a
set of registered afterfuncs indexed by an arbitrary unique key.
That key is currently a *struct{}. Unfortunately, all
*struct{} pointers are equal to each other, so all registered
funcs share the same key. Fortunately, the tests using this
type never register more than one afterfunc.
Patrick Steinhardt [Sat, 16 Sep 2023 11:12:12 +0000 (11:12 +0000)]
cmd/link: allow deriving GNU build ID from Go build ID ID
While it is possible to embed a GNU build ID into the linked
executable by passing `-B 0xBUILDID` to the linker, the build ID will
need to be precomputed by the build system somehow. This makes it
unnecessarily complex to generate a deterministic build ID as it
either requires the build system to hash all inputs manually or to
build the binary twice, once to compute its hash and once with the GNU
build ID derived from that hash. Despite being complex, it is also
inefficient as it requires the build system to duplicate some of the
work that the Go linker already performs anyway.
Introduce a new argument "gobuildid" that can be passed to `-B` that
causes the linker to automatically derive the GNU build ID from the Go
build ID. Given that the Go build ID is deterministically computed
from all of its inputs, the resulting GNU build ID should be
deterministic in the same way, which is the desired behaviour.
Furthermore, given that the `-B` flag currently requires a "0x" prefix
for all values passed to it, using "gobuildid" as value is a backwards
compatible change.
An alternative would be to unconditionally calculate the GNU build ID
unless otherwise specified. This would require some larger rework
though because building the Go toolchain would not converge anymore
due the GNU build ID changing on every stage, which in turn would
cause the Go build ID to change as well.
Fixes #41004
Change-Id: I707c5fc321749c00761643d6cc79d44bf2cd744d
GitHub-Last-Rev: 5483305a8566937836e5f39149a3df805d94580b
GitHub-Pull-Request: golang/go#61469
Reviewed-on: https://go-review.googlesource.com/c/go/+/511475 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Egon Elbre [Sun, 17 Sep 2023 06:27:41 +0000 (09:27 +0300)]
cmd/cgo: silence unaligned-access
Clang 14+ introduced a warning when using mixed packed and unpacked structs.
This can cause problems when taking an address of the unpacked struct, which
may end up having a different alignment than expected.
This is not a problem in cgo, which does not take pointers from the packed
struct.
Updated version of https://go.dev/cl/526915, which includes
"-Wunknown-warning-option" for compilers that do not have the specific flag.
Fixes #62480
Change-Id: I788c6604d0ed5267949f4367f148fa26d2116f51
Reviewed-on: https://go-review.googlesource.com/c/go/+/528935
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>