To be consistent with go/types.
Passes toolstash-check.
Change-Id: I5e02f529064a904310a164f8765082aa533cc799
Reviewed-on: https://go-review.googlesource.com/c/go/+/260699
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Instead of using untype(Ctype) to get corresponding untyped type.
Passes toolstash-check.
Change-Id: I311fe6c94b1f8eb2e1615101a379cd06dcab835b
Reviewed-on: https://go-review.googlesource.com/c/go/+/260698
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The current specification does not foresee a SameSite attribute without
a value. While the existing implementation would serialize SameSite in a
way that would likely be ignored by well-impelemented clients, it is
better to not rely on this kind of quirks.
Specification: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-4.1.1Fixes#36990
Change-Id: Ie51152741d7e84bab64d3e4e4f780286932acbde
Reviewed-on: https://go-review.googlesource.com/c/go/+/256498
Trust: Roberto Clapis <roberto@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This brings over the architectures that the gofrontend knows about.
This permits using the main cgo tool for those architectures,
as cgo can be used with -godefs without gc support.
This will help add golang.org/x/sys/unix support for other architectures.
For #37443
Change-Id: I63632b9c5139e71b9ccab8edcc7acdb464229b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/260657
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Updated cmd/pprof.objTool.Disasm to accept
an additional bool param introduced in
https://github.com/google/pprof/pull/520 to support
intel syntax in the assembly report.
Returns an error if the intelSyntax param is set. We use
src/cmd/internal/objfile to disassemble and print assembly
so I am not sure if it is relevant, and if so, how.
Fixes#38802
Updates #36905
Change-Id: Iae2b4322404f232196705f05210f00e2495588d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/248499
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Don't emit it for jumps. In particular, not for the return
instruction, which is JMP (LR).
Reduce some binary size and linker resources.
Change-Id: Idb3242b86c5a137597fb8accb8aadfe0244c14cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/260341
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Also add a few more TODOs as found by the relnote command.
It's an incomplete list due to #41849.
For #40700.
Change-Id: Id17a9be86d3338e1fcb281d26e7298ff26e92864
Reviewed-on: https://go-review.googlesource.com/c/go/+/260337
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Prior to this commit, the profiling code had a sleep() function that
waits and unblocks on either time.After() or a channel provided by an
http.CloseNotifier derived from a supplied http.ResponseWriter.
According to the documentation, http.CloseNotifier is deprecated:
Deprecated: the CloseNotifier interface predates Go's context package.
New code should use Request.Context instead.
This patch does just that -- sleep() now takes an *http.Request and uses
http.Request.Context() to signal when a request has been cancelled.
Change-Id: I98702314addf494f5743a4f99172dc607389dbb8
GitHub-Last-Rev: c1e37a03ca
GitHub-Pull-Request: golang/go#41756
Reviewed-on: https://go-review.googlesource.com/c/go/+/259157
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It's faster to append to a []byte and only convert to string at the
end then it is to build up a string by concatenating characters.
Fixes#41825
Change-Id: I45ddf77dcc62726c919f0533c95d483cee8ba366
Reviewed-on: https://go-review.googlesource.com/c/go/+/259978
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
We already do this for OpStore, but we didn't do this for OpMove.
Do the same, to ensure that no two memories are live at the same
time.
Fixes#41846.
Change-Id: Iad77ff031b3c4459d1217e0b04aeb0e692eb474d
Reviewed-on: https://go-review.googlesource.com/c/go/+/260237
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change makes go env -w check if GOTMPDIR is an absolute path.
If GOTMPDIR is not an absolute and not existing path there will be an
error at every `work.Builder.Init()`. If `go env` has `-u/-w` as
argument `work.Builder.Init()` is not called.
`go env -w GOTMPDIR=` work in the same way as `go env -u GOTMPDIR`.
Fixes#40932
Change-Id: I6b0662302eeace7f20460b6d26c6e59af1111da2
Reviewed-on: https://go-review.googlesource.com/c/go/+/250198
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
So we don't use SSE instructions under GO386=softfloat.
Change-Id: I8ecc92340ee567f84a22501df2543ec041d25ef2
Reviewed-on: https://go-review.googlesource.com/c/go/+/260137
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The implementation has been ported from reflect, but to avoid
introducing a dependency on strconv, Kind.String() falls back to
"invalid" if the Kind is unknown rather than "kind" + strconv.Itoa(int(k))
Fixes#39286
Change-Id: I82277242a6c41d0146dabd9d20339fe72d562500
Reviewed-on: https://go-review.googlesource.com/c/go/+/235522
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
It just works, after the plugin work.
Updates #38485.
Change-Id: I55aa11b380a33a729fccb731b77f48bc7d0dea2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/259443
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
On macOS/ARM64 everything must be PIE, and we already build PIE
in exe buildmode. Support PIE buildmode as well.
Updates #38485.
Change-Id: I10b68c2f6eb77714e31c26116c61a0e28bf9a358
Reviewed-on: https://go-review.googlesource.com/c/go/+/259442
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
On iOS, when running under lldb, we install xx_cgo_panicmem as
EXC_BAD_ACCESS handler so we can get a proper Go panic for
SIGSEGV. Only build it on iOS.
Updates #38485.
Change-Id: I801c477439e05920a4bb8fdf5eae6f4923ab8274
Reviewed-on: https://go-review.googlesource.com/c/go/+/259440
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Backstop support for non-sse2 chips now that 387 is gone.
RELNOTE=yes
Change-Id: Ib10e69c4a3654c15a03568f93393437e1939e013
Reviewed-on: https://go-review.googlesource.com/c/go/+/260017
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Unlike iOS, macOS ARM64 is more of a fully featured OS. Enable
more tests.
Updates #38485.
Change-Id: I2e2240c848d21996db2b950a4a6856987f7a652c
Reviewed-on: https://go-review.googlesource.com/c/go/+/256919
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apparently macOS/ARM64 has 47-bit addresses, instead of 33-bit as
on ios/ARM64. Enable more address bits.
Updates #38485.
Change-Id: I8aa64ba22a3933e3d9c4fffd17d902b5f31c30e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/256918
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently we don't use sigaltstack on darwin/arm64, as is not
supported on iOS. However, it is supported on macOS. Use it.
(iOS remains unchanged.)
Change-Id: Icc154c5e2edf2dbdc8ca68741ad9157fc15a72ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/256917
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is no correctness reason to zero out the w.bytes array in (w
*huffmanBitWriter).reset, since w.nbytes is correctly set to zero. The elements of
the bytes array are always written sequentially, with nbytes indicating how many
elements have been written, and are only read up to the current value of nybytes.
We have a pprof profile of a web server that compresses its request/responses, and
the zeroing in reset() is taking up 2.6% of the CPU time of the server (and could
be causing more slowdowns elsewhere due to its effects on the cache). This
overhead may be showing up especially because there are many request/responses
that are all fairly small.
I'm not sure if the zeroing of the bytes array was intended as extra protection of
data across reset uses in the same program, but no protection is needed as long as
the huffman_bit_writer code remains correct.
Change-Id: I67f2b2f56cff9dcc38d8fc0aea885bb010aeedbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/258577
Run-TryBot: Dan Scales <danscales@google.com>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Klaus Post <klauspost@gmail.com>
Reviewed-by: Joe Tsai <joetsai@google.com>
Trust: Joe Tsai <joetsai@google.com>
Trust: Dan Scales <danscales@google.com>
This CL adds basic support for listing packages with overlays.
The new cmd/go/internal/fs package adds an abstraction for communicating
with the file system that will open files according to their overlaid paths,
and provides functions to override those in the build context to open
overlaid files. There is also some support for executing builds on packages
with overlays. In cmd/go/internal/work.(*Builder).build, paths are mapped
to their overlaid paths before they are given as arguments to tools.
For #39958
Change-Id: I5ec0eb9ebbca303e2f1e7dbe22ec32613bc1fd17
Reviewed-on: https://go-review.googlesource.com/c/go/+/253747
Trust: Michael Matloob <matloob@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Two part fix:
1) bring the type "correction" forward from a later CL in the expand calls series
2) when a leaf-selwect is rewritten in place, update the type (it might have been
changed by the type correction in 1).
Fixes#41736.
Change-Id: Id097efd10481bf0ad92aaead81a7207221c144b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/259203
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#40281
Change-Id: Ie624bce3a78a06d7ed71bba1f501e66802dffd13
Reviewed-on: https://go-review.googlesource.com/c/go/+/248341
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Support for GO386=387 is being dropped in Go 1.16. There
is no need for the target to be available for testing on
the master branch (where Go 1.16 development is ongoing).
For #40255.
Change-Id: I4a4ee80b0c0a535b6b0b246fe991f26964eb07ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/257963
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Mobile targets are not supported by misc-compile trybots, as tracked in
golang.org/issue/25963, and need to be filtered out. The buildall.bash
script was created in CL 9438, back when it was a single all-compile
builder, and it was easier to filter out mobile targets in the script
than to come up with a pattern that matches all non-mobile targets.
As of CL 254740, all mobile targets (Android and iOS) have unique GOOS
values. That makes it it easy to filter them out in x/build/dashboard.
This was done in CL 258057. As a result, it's now viable to simplify
this script and perform all misc-compile target selection in x/build,
rather than having it spread it across two places.
Also, as of CL 10750, the all-compile builder has turned into multiple
misc-compile builders, so update the script description accordingly.
Updates #41610.
Change-Id: I1e33260ac18cf0a70bb68cd8e3db5587100c7e87
Reviewed-on: https://go-review.googlesource.com/c/go/+/257962
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
In the rare case when a cgo type makes it into an object file, we need
the go:notinheap annotation to go with it.
Fixes#41761
Change-Id: I541500cb1a03de954881aef659f96fc0b7738848
Reviewed-on: https://go-review.googlesource.com/c/go/+/259297
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#37272
Change-Id: I6554fd5e5400acb20c5a7e96b1d6cb1a1afb9871
Reviewed-on: https://go-review.googlesource.com/c/go/+/259299
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This is a step toward porting https://golang.org/cl/219817 from the
gofrontend repo to the main repo.
Note that this also corrects the implementation of the v2 mangling
scheme to use ..u and ..U where appropriate.
For #37272
Change-Id: I64a1e7ca1c84348efcbf1cf62049eeb05c830ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/259298
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Most of the cmd/go tests build the cmd/go binary and run that binary to
test it, but TestAbsolutePath used the GOROOT's cmd/go instead, which
makes debugging confusing and means that make.bash has to be run in each
iteration cycle. Update TestAbsolutePath to use the same go binary as
the rest of the cmd/go tests.
Change-Id: Ib4e8ae707b66f1f75ceb346b98358f5604fd28c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/256979
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
It is tested on darwin/arm64. Don't lose it when using GOOS=ios.
Updates #38485.
Change-Id: I7157d6b6f2850f2fd361e35ae310dd1ba9f31aa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/259439
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ARM64 used to require that all assembly frame sizes were of the form
16*N+8 because ARM64 requires 16-byte SP alignment and the assembler
added an 8 byte LR slot. This made all of the runtime.call* frame
sizes wonky. The assembler now rounds up the frame size appropriately
after adding any additional slots it needs, so this is no longer
necessary.
This CL cleans up the frame sizes of these functions so they look the
way you'd expect and match all other architectures.
Change-Id: I47819092296b8983c43eadf2e66c7c1e0d518555
Reviewed-on: https://go-review.googlesource.com/c/go/+/259448
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, runtime.call16 is defined and used only on 32-bit
architectures, while 64-bit architectures all start at call32 and go
up from there. This led to unnecessary complexity because call16's
prototype needed to be in a different file, separate from all of the
other call* prototypes, which in turn led to it getting out of sync
with the other call* prototypes. This CL adds call16 on 64-bit
architectures, bringing them all into sync, and moves the call16
prototype to live with the others.
Prior to CL 31655 (in 2016), call16 couldn't be implemented on 64-bit
architectures because it needed at least four words of argument space
to invoke "callwritebarrier" after copying back the results. CL 31655
changed the way call* invoked the write barrier in preparation for the
hybrid barrier; since the hybrid barrier had to be invoked prior to
copying back results, it needed a different solution that didn't reuse
call*'s stack space. At this point, call16 was no longer a problem on
64-bit, but we never added it. Until now.
Change-Id: Id10ade0e4f75c6ea76afa6229ddaee2b994c27dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/259339
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The signature of call16 is currently missing the "typ" parameter. This
CL fixes this. This wasn't caught by vet because call16 is defined by
macro expansion (see #17544), and we didn't notice the mismatch with
the other call* functions because call16 is defined only on 32-bit
architectures and lives alone in stubs32.go.
Unfortunately, this means its GC signature is also wrong: the "arg"
parameter is treated as a scalar rather than a pointer, so GC won't
trace it and stack copying won't adjust it. This turns out to matter
in exactly one case right now: on 32-bit architectures (which are the
only architectures where call16 is defined), a stack-allocated defer
of a function with a 16-byte or smaller argument frame including a
non-empty result area can corrupt memory if the deferred function
grows the stack and is invoked during a panic. Whew. All other current
uses of reflectcall pass a heap-allocated "arg" frame (which happens
to be reachable from other stack roots, so tracing isn't a problem).
Curiously, in 2016, the signatures of all call* functions were wrong
in exactly this way. CL 31654 fixed all of them in stubs.go, but
missed the one in stubs32.go.
Fixes#41795.
Change-Id: I31e3c0df201f79ee5707eeb8dc4ff0d13fc10ada
Reviewed-on: https://go-review.googlesource.com/c/go/+/259338
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This change clarifies the usage of the SET type name suffix. Previously
the documentation was somewhat confusing about where the suffix should
be used, and when used what it applied to. For instance the previous
language could be interpreted such that []exampleSET would be parsed as
a SEQUENCE OF SET, which is incorrect as the SET suffix only applies to
slice types, such as type exampleSET []struct{} which is parsed as a
SET OF SEQUENCE.
Change-Id: I74201d9969f931f69391c236559f66cb460569ec
GitHub-Last-Rev: d0d2ddc587
GitHub-Pull-Request: golang/go#38543
Reviewed-on: https://go-review.googlesource.com/c/go/+/229078
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I247fc9e0e26e706e6af07367f953eaa1b7e544c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/259577
Trust: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Add a case for gohostos == "ios" along with "darwin".
Updates #38485.
Change-Id: Ic7310e6c97d405f78a5e5db1a639860455e61327
Reviewed-on: https://go-review.googlesource.com/c/go/+/259337
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
There are no tethered iOS builders left, and should they appear in
the future, they should use all.bash.
Change-Id: I3217789514ffa725e4d2584e4991d899c5fda995
Reviewed-on: https://go-review.googlesource.com/c/go/+/259278
Trust: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Update the README to mention the emulator. Remove reference to gomobile
while here; there are multiple ways to develop for iOS today, including
using the c-archive buildmode directly.
Updates #38485
Change-Id: Iccef75e646ea8e1b9bc3fc37419cc2d6bf3dfdf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/255257
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Update #40995
Change-Id: I2cf9b85a960f479eaa59bf58081d03a0467bc2b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/250582
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
