The Go standard library retrofitted context support onto existing APIs
using context.Background and later offered variants that directly
supported user-defined context value specification. This commit makes
that behavior clear in documentation and suggests context-aware
alternatives if the user is looking for one.
An example motivation is supporting code for use in systems that expect
APIs to be cancelable for lifecycle correctness or load
shedding/management reasons, as alluded to in
https://blog.golang.org/context-and-structs.
Updates #44143
Change-Id: I2d7f954ddf9b48264d5ebc8d0007058ff9bddf14
Reviewed-on: https://go-review.googlesource.com/c/go/+/296152
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jean de Klerk <deklerk@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It turns out that if you write Go pointers to Go memory, the Go compiler
must be involved so that it generates various calls to the GC in the
process. Letting Windows write Go pointers to Go memory violated this.
So, we replace that with just a boring call to runtime.KeepAlive. That's
not a great API, but this is all internal code anyway. We fix it up
more elegantly for external consumption in x/sys/windows with CL 300369.
Fixes#44900.
Change-Id: Id6599a793af9c4815f6c9387b00796923f32cb97
Reviewed-on: https://go-review.googlesource.com/c/go/+/300349
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The implementation of GetRandom for Linux, FreeBSD and DragonflyBSD can
be shared.
Also remove GRND_INSECURE on DragonflyBSD as pointed out by Ian in the
review of CL 269999.
Change-Id: I5bf4c1bd51ddb2ad600652a57e0bc1bafa1cf40d
Reviewed-on: https://go-review.googlesource.com/c/go/+/299133
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, the cmd/dist runs test cases in misc/cgo/testsantizers only
when memeory sanitizer is supported, but the tsan tests in
misc/cgo/testsanitizers do not require support for -msan option, which
makes tsan tests can not be run on some unsupported -msan option platforms.
Therefore, this patch moves the test constraints from cmd/dist to
msan_test.go, so that the tsan tests in misc/cgo/testsanitizers
can be run on any system where the C compiler supports -fsanitize=thread
option.
Change-Id: I779c92eedd0270050f1a0b1a69ecce50c3712bc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/297774
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the case of partially inferred type arguments, we need to use the
IndexExpr as the key in g.info.Inferred[] rather than the CallExpr.
Added an extra fromStrings1 call in the settable.go test that tests
partially inferred type arguments. This new call uses a new concrete
type SettableString as well.
I also added another implementation fromStrings3 (derived from a go2go
tests) that typechecks but intentionally causes a panic.
Change-Id: I74d35c5a741f72f37160a96fbec939451157f392
Reviewed-on: https://go-review.googlesource.com/c/go/+/300309
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is rarely used, and is implied based on the
memory type of the operand. This is a step towards
simplifying the MOV* pseudo opcodes on ppc64.
Similarly, remove the bogus param value from AVMULESB.
Change-Id: Ibad4d045ec6d8c5163a468b2db1dfb762ef674ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/300177
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Ian Lance Taylor <iant@golang.org>
The timerpMask optimization updates a mask of Ps (potentially)
containing timers in pidleget / pidleput. For correctness, it depends on
the assumption that new timers can only be added to a P's own heap.
addtimer violates this assumption if it is preempted after computing pp.
That G may then run on a different P, but adding a timer to the original
P's heap.
Avoid this by disabling preemption while pp is in use.
Other uses of doaddtimer should be OK:
* moveTimers: always moves to the current P's heap
* modtimer, cleantimers, addAdjustedTimers, runtimer: does not add net
new timers to the heap while locked
Fixes#44868
Change-Id: I4a5d080865e854931d0a3a09a51ca36879101d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/300610
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The new Graph type implements an incremental version of the MVS
algorithm, with requirements pushed in by the caller instead of pulled
by an internal MVS traversal.
To avoid redundancy going forward (and to ensure adequate test
coverage of the incremental implementation), the existing buildList
function is reimplemented in terms of Graph.
For #36460
Change-Id: Idd0b6ab8f17cc41d83a2a4c25a95f82e9ce1eab0
Reviewed-on: https://go-review.googlesource.com/c/go/+/244760
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
For #36460
Change-Id: I8dd6e6f998a217a4287212815ce61209df6f007f
Reviewed-on: https://go-review.googlesource.com/c/go/+/296609
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Previosly, EditBuildList performed an mvs.Upgrade followed by an
mvs.Downgrade, with the Downgrade building on the result of the
Upgrade. Unfortunately, that approach potentially folds in irrelevant
dependencies from the first Upgrade, which are then preserved
unnecessarily by the Downgrade (see mod_get_downup_artifact.txt).
Now, we use the initial Upgrade only to compute the maximum allowed
versions of transitive dependencies, and apply the module upgrades and
downgrades together in a single operation.
For #36460
Change-Id: I7590c137111fed4a3b06531c88d90efd49e6943a
Reviewed-on: https://go-review.googlesource.com/c/go/+/290770
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Follow-up to CL 297530.
For #43985
For #34992
Change-Id: I2cfa6c41c013e627c3464c383ca42f5c9ebe521a
Reviewed-on: https://go-review.googlesource.com/c/go/+/297634
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In the ppc64 ISA DS form loads and stores are restricted to offset
fields that are a multiple of 4. This is currently handled with checks
in the rules that generate MOVDload, MOVWload, MOVDstore and
MOVDstorezero to prevent invalid instructions from getting to the
assembler.
An unhandled case was discovered which led to the search for a better
solution to this problem. Now, instead of checking the offset in the
rules, this will be detected when processing these Ops in
ssaGenValues in ppc64/ssa.go. If the offset is not valid, the address
of the symbol to be loaded or stored will be computed using the base
register + offset, and that value used in the new base register.
With the full address in the base register, the offset field can be
zero in the instruction.
Updates #44739
Change-Id: I4f3c0c469ae70a63e3add295c9b55ea0e30ef9b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/299789
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
To ease readability we typically keep the partial order lists sorted by
rank. This isn't required for correctness, it just makes it (slightly)
easier to read the lists.
Currently we must notice out-of-order entries during code review, which
is an error-prone process.
Add a test to enforce ordering, and fix the errors that have crept in.
Most of the existing errors were misordered lockRankHchan or
lockRankPollDesc.
While we're here, I've moved the correctness check that the partial
ordering satisfies the total ordering from init to a test case. This
will allow us to catch these errors without even running
staticlockranking.
Change-Id: I9c11abe49ea26c556439822bb6a3183129600c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/300171
Trust: Michael Pratt <mpratt@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This change properly handles a TokenReader which
returns an EOF in the middle of an open XML
element.
Thanks to Sam Whited for reporting this.
Fixes CVE-2021-27918
Fixes#44913
Change-Id: Id02a3f3def4a1b415fa2d9a8e3b373eb6cb0f433
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1004594
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/300391
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When operating on a Zip file that contains a file prefixed with "../",
Open(...) would cause a panic in toValidName when attempting to strip
the prefixed path components.
Fixes CVE-2021-27919
Fixes#44916
Change-Id: Ic755d8126cb0897e2cbbdacf572439c38dde7b35
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1004761
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/300489
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Deal with cases like: 'type P[T any] T' (used to add methods to an
arbitrary type T), In this case, P[T] has kind types.TTYPEPARAM (as does
T itself), but requires more code to substitute than a simple TTYPEPARAM
T. See the comment near the beginning of subster.typ() in stencil.go.
Add new test absdiff.go. This test has a case for complex types (which
I've commented out) that will only work when we deal better with Go
builtins in generic functions (like real and imag).
Remove change in fmt.go for TTYPEPARAMS that is no longer needed (since
all TTYPEPARAMS have a sym) and was sometimes causing an extra prefix
when formatting method names.
Separate out the setting of a TTYPEPARAM bound, since it can reference
the TTYPEPARAM being defined, so must be done separately. Also, we don't
currently (and may not ever) need bounds after types2 typechecking.
Change-Id: Id173057e0c4563b309b95e665e9c1151ead4ba77
Reviewed-on: https://go-review.googlesource.com/c/go/+/300049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The const parseTypeParams was grouped with printer-related consts in
gofmt.go, implicitly suggesting that it must be kept in sync with
go/format/format.go.
Change-Id: Ia65dc15c27fef2c389f963071252adee32ec6bd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/300451
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This file has a go:build comment without a corresponding +build comment.
Change-Id: Id01604242a14d8ead16ffb9aa1b45eef7706956a
Reviewed-on: https://go-review.googlesource.com/c/go/+/300450
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
LLVM changed their main branch name, so this link didn't work anymore.
Change-Id: I4c3a67b26e2bda012071281e29ea3c932c185130
Reviewed-on: https://go-review.googlesource.com/c/go/+/300469
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
reflectcall tail calls runtime.call{16,32,...} functions, so they
have the same signature as reflectcall. It is important for them
to have the correct arg map, because those functions, as well as
the function being reflectcall'd, could move the stack. When that
happens, its pointer arguments, in particular regArgs, need to be
adjusted. Otherwise it will still point to the old stack, causing
memory corruption.
This only caused failures on the regabi builder because it is the
only place where internal/abi.RegArgs is not a zero-sized type.
May fix#44821.
Change-Id: Iab400ea6b60c52360d0b43a793f6bfe50ca9989b
Reviewed-on: https://go-review.googlesource.com/c/go/+/300154
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In some cases, this test would prompt for interactive SSH passwords in
order to authenticate to github.com over SSH. Setting GIT_SSH_COMMAND
to /bin/false prevents that, while still provoking the desired Git
failure mode.
Updates #44904.
Change-Id: Idc9fe9f47d2ccb6c8a4ea988b73d9c8c774e4079
Reviewed-on: https://go-review.googlesource.com/c/go/+/300156
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Kevin Burke <kev@inburke.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Kevin Burke <kev@inburke.com>
Since the 5.7 release, DragonFlyBSD supports as well
the getrandom function, the actual stable is 5.8.
Change-Id: I2b8fc468771b10ac12b38ea7e8e5314342de6375
GitHub-Last-Rev: c5c496f418
GitHub-Pull-Request: golang/go#42617
Reviewed-on: https://go-review.googlesource.com/c/go/+/269999
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
In scenarios where splice() is called, splice() is usually called not just once, but many times,
which means that a lot of pipes will be created and destroyed frequently, costing an amount of system resources
and slowing down performance, thus I suggest that we add a pipe pool for reusing pipes.
Benchmark tests:
goos: linux
goarch: amd64
pkg: internal/poll
cpu: AMD EPYC 7K62 48-Core Processor
name old time/op new time/op delta
SplicePipe-8 1.36µs ± 1% 0.02µs ± 0% -98.57% (p=0.001 n=7+7)
SplicePipeParallel-8 747ns ± 4% 4ns ± 0% -99.41% (p=0.001 n=7+7)
name old alloc/op new alloc/op delta
SplicePipe-8 24.0B ± 0% 0.0B -100.00% (p=0.001 n=7+7)
SplicePipeParallel-8 24.0B ± 0% 0.0B -100.00% (p=0.001 n=7+7)
name old allocs/op new allocs/op delta
SplicePipe-8 1.00 ± 0% 0.00 -100.00% (p=0.001 n=7+7)
SplicePipeParallel-8 1.00 ± 0% 0.00 -100.00% (p=0.001 n=7+7)
Fixes#42740
Change-Id: Idff654b7264342084e089b5ba796c87c380c471b
Reviewed-on: https://go-review.googlesource.com/c/go/+/271537
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
This change upgrades x/mod to pull in the fix from CL 300149.
Fixes#44776.
Change-Id: I273f41df2abfff76d91315b7f19fce851c8770d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/300176
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a 1:1 port of the respective change in go/types
in https://golang.org/cl/299590.
Change-Id: I65ad723f2e21e3d95fc0b94665e0121e31871a48
Reviewed-on: https://go-review.googlesource.com/c/go/+/300250
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Until now, errors which came with additional details (e.g., a declaration
cycle error followed by the list of objects involved in the cycle, one per
line) were reported as an ordinary error followed by "secondary" errors,
with the secondary errors marked as such by having a tab-indented error
message.
This approach often required clients to filter these secondary errors
(as they are not new errors, they are just clarifying a previously
reported error).
This CL introduces a new internal error_ type which permits accumulating
various error information that may then be reported as a single error.
Change-Id: I25b2f094facd37e12737e517f7ef8853d465ff77
Reviewed-on: https://go-review.googlesource.com/c/go/+/296689
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The heuristic gopls uses to guess error spans can get tripped-up on
certain valid characters in an import path (for example '-').
Update the error for broken imports to capture the full import path
span, so that gopls doesn't need to rely on heuristics.
Change-Id: Ieb8e0dce11933643f701b32271ff5f3477fecaaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/300169
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
These instructions are actually 5 argument opcodes as specified
by the ISA. Prior to this patch, the MB and ME arguments were
merged into a single bitmask operand to workaround the limitations
of the ppc64 assembler backend.
This limitation no longer exists. Thus, we can pass operands for
these opcodes without having to merge the MB and ME arguments in
the assembler frontend or compiler backend.
Likewise, support for 4 operand variants is unchanged.
Change-Id: Ib086774f3581edeaadfd2190d652aaaa8a90daeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/298750
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
If runtime.MemProfile is unreachable, default to not collecting any
memory profiling samples, to save memory on the hash table.
Fixes#42347
Change-Id: I9a4894a5fc77035fe59b1842e1ec77a1182e70c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/299671
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Keith Randall <khr@golang.org>
TXT records are not domain names, so no need to call absDomainName.
The output now matches the pure Go resolver.
Fixes#44619
Change-Id: I1ebf09152ff5c0446d2e2b4c26671358892d9dc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/296589
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David du Colombier <0intro@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
ABI info producer and consumer had different ideas for register
order for parameters.
Includes a test, includes improvements to debugging output.
Updates #44816.
Change-Id: I4812976f7a6c08d6fc02aac1ec0544b1f141cca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/299570
Trust: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Old: return the ABI register index of the result (wrong!)
New: return the index w/in sequence of result registers (right!)
Fixed bug:
genCaller0/genCaller0.go:43:9: internal compiler error: 'Caller0':
panic during schedule while compiling Caller0:
runtime error: index out of range [10] with length 9
Updates #44816.
Change-Id: I1111e283658a2d6422986ae3d61bd95d1b9bde5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/299549
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Includes more enhancements to debugging output.
Updates #44816.
Change-Id: I5b21815cf37ed21e7dec6c06f538090f32260203
Reviewed-on: https://go-review.googlesource.com/c/go/+/299409
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We'll need to attach types to these operations, so we need to
represent them in the import/export data.
Some of the operations use a selector indicating a different package,
so we need to provide an option to encode the package of a selector.
The default selector() function can't encode that extra information,
as selector's exact encoding is used by go/types.
Change-Id: I4c110fe347b3d915f88a722834bc4058baea7854
Reviewed-on: https://go-review.googlesource.com/c/go/+/299771
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Change-Id: I05ba944e189a884b727e40a9526d212612c3e923
Reviewed-on: https://go-review.googlesource.com/c/go/+/299770
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
gscan is taken during stack growth, which may occur while pollDesc is
held.
mallocgc may also be called while pollDesc is held. mallocgc may take
mheap or mheapSpecial. The former exists, but is out of order; the
latter is missing.
Fixes#44881
Change-Id: Ie25935d9d433e813c11a528ee47255b317a09f41
Reviewed-on: https://go-review.googlesource.com/c/go/+/300009
Trust: Michael Pratt <mpratt@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Just add a simple magic number with each op, to detect when
the reader gets desynchronized from the writer.
Change-Id: Iac7dab7f465b0021b1d7ae31c8f8a353ac3663a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/299769
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Get instantiatiated generic types working with interfaces, including
typechecking assignments to interfaces and instantiating all the methods
properly. To get it all working, this change includes:
- Add support for substituting in interfaces in subster.typ()
- Fill in the info for the methods for all instantiated generic types,
so those methods will be available for later typechecking (by the old
typechecker) when assigning an instantiated generic type to an
interface. We also want those methods available so we have the list
when we want to instantiate all methods of an instantiated type. We
have both for instantiated types encountered during the initial noder
phase, and for instantiated types created during stenciling of a
function/method.
- When we first create a fully-instantiated generic type (whether
during initial noder2 pass or while instantiating a method/function),
add it to a list so that all of its methods will also be
instantiated. This is needed so that an instantiated type can be
assigned to an interface.
- Properly substitute type names in the names of instantiated methods.
- New accessor methods for types.Type.RParam.
- To deal with generic types which are empty structs (or just don't use
their type params anywhere), we want to set HasTParam if a named type
has any type params that are not fully instantiated, even if the
type param is not used in the type.
- In subst.typ() and elsewhere, always set sym.Def for a new forwarding
type we are creating, so we always create a single unique type for
each generic type instantiation. This handles recursion within a
type, and also recursive relationships across many types or methods.
We remove the seen[] hashtable, which was serving the same purpose,
but for subst.typ() only. We now handle all kinds of recursive types.
- We don't seem to need to force types.CheckSize() on
created/substituted generic types anymore, so commented out for now.
- Add an RParams accessor to types2.Signature, and also a new
exported types2.AsSignature() function.
Change-Id: If6c5dd98427b20bfe9de3379cc16f83df9c9b632
Reviewed-on: https://go-review.googlesource.com/c/go/+/298449
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Replace ioutil.Discard which is deprecated as of Go 1.16.
This was already done in CL 263142 but accidentially re-introduced in
CL 285914.
Change-Id: Ife0944d416294b1ba7c8f6b602aa68a3b9213c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/299989
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Over a dozen of the ld tests were missing closes. That was less
obvious before CL 299670 started using T.TempDir instead, which fails
a test when the tempdir can't be cleaned up (as it can't on Windows
when things are still open), insteading of leaving tempdirs around on
disk after the test.
Most of the missing closes were fixed in CL 299670, but the builders
helpfully pointed out that I missed at least this one.
Change-Id: I35f695bb7cbfba31e16311c5af965c148f9d7943
Reviewed-on: https://go-review.googlesource.com/c/go/+/299929
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Dan Scales <danscales@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
The ValAndOff type is a 64bit integer holding a 32bit value and a
32bit offset in each half, but for historical reasons its Val and Off
methods returned an int64. This was convenient when AuxInt was always
an int64, but now that AuxInts are typed we can return int32 from Val
and Off and get rid of a several casts and now unnecessary range
checks.
This change:
- changes the Val and Off methods to return an int32 (from int64);
- adds Val64 and Off64 methods for convenience in the few remaining
places (in the ssa.go files) where Val and Off are stored in int64
fields;
- deletes makeValAndOff64, renames makeValAndOff32 to makeValAndOff
- deletes a few ValAndOff methods that are now unused;
- removes several validOff/validValAndOff check that will always
return true.
Passes:
GOARCH=amd64 gotip build -toolexec 'toolstash -cmp' -a std
GOARCH=386 gotip build -toolexec 'toolstash -cmp' -a std
GOARCH=s390x gotip build -toolexec 'toolstash -cmp' -a std
(the three GOARCHs with SSA rules files impacted by the change).
Change-Id: I2abbbf42188c798631b94d3a55ca44256f140be7
Reviewed-on: https://go-review.googlesource.com/c/go/+/299149
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Document that network poller implementations need to define
netpollclose.
Change-Id: Idc73dea7cfd503d4de7e1d95902f0f102cf5ed8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297809
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brings in the static analyzer "sigchanyzer", that we created at
Orijtech, Inc, and already submitted in CL 274352, as
golang.org/x/tools/go/analysis/passes/sigchanyzer
and add it to cmd/vet as one of the passes.
Fixes#9399
Change-Id: I83708b8ea5ca8ede5ee31efab55cbce7419434ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/299532
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
