Reviewed the code and simplified slightly. No semantic changes.
Change-Id: Ib785b912fbee97746324af87ac0c14a4bdb69477
Reviewed-on: https://go-review.googlesource.com/c/go/+/363440
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL enables the mode in which the underlying type of
type parameters is the underlying type of their constraints.
Change-Id: Id3471578dab098695dbd1e0429356ebcc9c5e224
Reviewed-on: https://go-review.googlesource.com/c/go/+/363155
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, the type checker operated with the definition that the
underlying type of a type parameter is itself. This leads to some
inconcistencies and caused us to disallow type declarations where
the RHS is a stand-alone type parameter.
This change implements an alernative definition: the underlying
type of a type parameter is the underlying type of its constraint;
i.e., the underlying type of a type parameter is always an interface
(because constraints must be interfaces). This matches the theory
closely and also resolves some inconsistencies. For example, we
don't need to prohibit stand-alone type parameters on the RHS of
a type declaration (though, for the sake of keeping the tests the
same, we still do in this CL). We also get a clear understanding of
what it would mean to use a type assertion or type switch on a type
parameter (still disabled with this CL). Finally, the declaration
of a type parameter now very closely matches the definition of an
ordinary type.
The main consequence is that the rules for assignment need to be
slightly modified: even though a type parameter is an interface,
we cannot simply assign to it per the rules for interfaces: the
type parameter's type is fixed for the instantiation and we need
to reflect that accordingly when checking for assignability.
This CL does not enable the new mode, it implements it in parallel
to the existing mode; the internal flag tparamIsIface is used to
switch between the modes.
The changes to the code are numerous, but straight-forward: when-
ever we deal with an underlying type that might be a type parameter
(or newly, an interface), we need to act slightly differently. For
the time being this leads to some code duplication because the code
supports both modes.
While some of the code for the new mode seems more complicated
(e.g., when we have an interface, the code checks that it is not
the underlying type of a type parameter), in reality many of the
extra checks are redundant and only present because of an abundance
of caution: interfaces with specific type sets are not permitted as
types for ordinary variables, and so even if we were to hit those
cases w/o excluding type parameters the behavior would be the same.
Runs all tests with tparamIsIface enabled and disabled.
Current setting: disabled.
Change-Id: I7bb6453f4fe2569d92face222058fb4e17b12f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/359016
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>
For #45713, #48257
Change-Id: I7e9248f22fe7ab33b151e07cc296d64c194154e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/359534
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed all uses of underIs (global function and method) and made
sure we are ok with a nil incoming argument (indicating a type set
with no specific types).
Added a couple of checks where we didn't have them (and somehow
didn't run into a problem yet).
Change-Id: Ifde45a3a80ddf2b1a19c83f79258ad8207dfb09f
Reviewed-on: https://go-review.googlesource.com/c/go/+/363658
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When being used by the compiler, augment the types2 missing method
message with extra info, if a method is missing, but a method with the
correct name except for case (i.e. equal via string.EqualFold()) is
present. In that case, print out the wanted method and the method that
is present (that has the wrong case).
In the 1.17 compiler, we don't do this case-folding check when assigning
an interface to an interface, so I didn't add that check, but we could
add that.
Fixes#48471
Change-Id: Ic54549c1f66297c9221d979d49c1daa719aa66cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/363437
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When being used by the compiler, fix up types2 error messages to be more
like Go 1.17 compiler errors. In particular:
- add information about which method is missing when a type is not
assignable/convertible/etc. to an interface.
- add information about any existing method which has the same name,
but wrong type.
- add extra hint in the case that the source or destination type is a
pointer to an interface, rather than an interface.
- add extra hint "need type assertion" in the case that the source is
an interface that is implemented by the destination.
- the following change in the CL stack also adds information about any
existing method with a different name that only differs in case.
Include much of the new logic in a new common function
(*Checker).missingMethodReason().
types2 still adds a little more information in some cases then the Go
1.17 compiler. For example, it typically says "(value of type T)",
rather than "(type T)", where "value" could also be "constant",
"variable", etc.
I kept the types2 error messages almost all the same when types2 is not
used by the compiler. The only change (to reduce amount of compatibility
code) was to change "M method" phrasing in one case to "method M"
phrasing in one error message (which is the phrasing it uses in all
other cases). That is the reason that there are a few small changes in
types2/testdata/check/*.src.
Added new test test/fixedbugs/issue48471.go to test that the added
information is appearing correctly.
Also adjusted the pattern matching in a bunch of other
test/fixedbugs/*.go, now that types2 is producing error messages closer
to Go 1.17. Was able to remove a couple test files from the types2
exception list in run.go.
Updated #48471
Change-Id: I8af1eae6eb8a5541d8ea20b66f494e2e795e1956
Reviewed-on: https://go-review.googlesource.com/c/go/+/363436
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
By default, use workspace modules' go.sum files to check sums. Any
missing sums will still be written to go.work.sum
For #45713
Change-Id: I0f537602523dfec44d423c3c80c7ef396e1397b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/359478
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Because we do not permit a stand-alone type parameter on the RHS of
a type declaration, the underlying type of a (Named) type cannot be
a type parameter. This allows us to simplify some code.
Specifically, when parsing union elements, we don't need to delay
a check for later, which allows further simplifications when computing
type sets.
Change-Id: I4047c609f87ebb194ea8c1bad630a70d255b20cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/363438
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>
Like OFUNCINST, in case of OXDOT call expression, the arguments need
to be transformed earlier, so any needed CONVIFACE nodes are exposed.
Fixes#49538
Change-Id: I275ddf6f53a9cadc8708e805941cdf7bdffabba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/363554
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This change sets a timeout of 10 seconds on each
execution of the fuzz target, both during fuzzing
and during minimization. This is not currently
customizable by the user, but issue #48157 tracks
this work.
Deadlocks will be considered non-recoverable errors,
and as such, will not be minimizable.
Fixes#48591
Change-Id: Ic86e8e9e9a0255e7860f7cbf5654e832785d1cbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/363134
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Context.TypeHash is not being used outside of the type checker, so
unexport it.
The TypeHash method is meant to hash instances, not arbitrary types, and
will soon be modified to differentiate origin types by pointer identity
(even if they are *Signature types).
Change-Id: Ia8d4a7c6350ce7f278b70630585efb0009fef63a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363516
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>
When the link exits on error it currently calls Out.Close, which
will munmap the output buffer and close the file. This may be
called in concurrent phase where other goroutines may be writing
to the output buffer. The munmap can race with the write, causing
it to write to unmapped memory and crash. This CL changes it to
just close the file without unmapping. We're exiting on error
anyway so no need to unmap.
Fixes#47816.
Change-Id: I0e89aca991bdada3d017b7d5c8efc29e46308c03
Reviewed-on: https://go-review.googlesource.com/c/go/+/363357
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This change doesn't modify any functionality.
It also doesn't update all of the comments and
variable names of the internal code, but everything
user facing should be correct.
Updates #49185
Change-Id: Ia8b2c94b89ba45897c4085ea0c17a3d8896f7ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/362794
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Also, don't set the scope anymore when instantiating (substituting)
a signature.
Per discussion with rfindley.
Change-Id: I560d4571c7ff14b0df3e15fece634cb5f9f94a99
Reviewed-on: https://go-review.googlesource.com/c/go/+/363435
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>
Our compiler gets confused between functions that were declared
with no body, and those which have a body but it is empty.
Ensure that when stenciling, we generate a nonempty body.
The particular test that causes this problem is in
cmd/compile/internal/gc/main.go:enqueueFunc. It thinks that if
a function has no body, then we need to generate ABI wrappers for
it, but not compile it.
Fixes#49524
Change-Id: Id962666a2098f60a2421484b6a776eafdc4f4a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/363395
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The repository name and structure in the RISC-V GitHub org has been
modified, rendering the existing link invalid. This updates to point at
the new location of the RISC-V DWARF specification.
Change occured in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/208
Change-Id: I8ca4c390bee2d7ce20418cdd00e4945a426cf5f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/363355
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Than McIntosh <thanm@google.com>
When building a call expression for function instantiation closure, if
it's a variadic function, the CallExpr.IsDDD must be set for typecheck
to work properly. Otherwise, there will be a mismatch between the
arguments type and the function signature.
Fixes#49516
Change-Id: I0af90ee3fcc3e6c8bba8b20e331e044cbce17985
Reviewed-on: https://go-review.googlesource.com/c/go/+/363314
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: Keith Randall <khr@golang.org>
A chunk of code in abiutils was synthesizing the internals of a Go
string type as "struct { unsafe.Pointer, uintptr }" instead of the
more canonical representation "struct { *uint8, int }" used elsewhere
in the compiler. The abiutils type was being pulled into the code
during late call expansion, which resulted in two different entries in
the SSA named value table for the same variable piece, each with
different types; this then confused DWARF location list generation.
This patch changes the abiutils synthesized type to be consistent with
other parts of the back end, and makes a similar change for
synthesized slice types (use "struct { *uint8, int, int }").
Fixes#47354.
Change-Id: If789031cdc7abaf215bc75ee6eb863defbe530be
Reviewed-on: https://go-review.googlesource.com/c/go/+/362715
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
During the register ABI work, a change was made in CL 302071 to
"stackframe" to treat register-resident output parameter (PARAMOUT)
variables that same as locals, which meant that if they were unused,
we'd delete them from the "Dcl" slice. This has the effect of making
them invisible to DWARF generation later on in the pipeline, meaning
that we don't get DIEs for them in the debug info. This patch fixes
the problem by capturing these params prior to optimization and then
adding them back in for consideration when we're processing the
params/locals of a function during DWARF generation.
Fixes#48573.
Change-Id: I2b32882911c18f91c3e3d009486517522d262685
Reviewed-on: https://go-review.googlesource.com/c/go/+/362618
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Revamp the way that buildLocationLists() handles zero-width
operations, to fix a couple of problems that result in bad debug
locations.
The problematic scenario in this specific bug is where you have a
parameter arriving in a register X, then a spill of register X to
memory as the first non-zero-width instruction in the function.
Example:
v68 = ArgIntReg <unsafe.Pointer> {ctx+0} [1] : BX (ctx[unsafe.Pointer])
v67 = ArgIntReg <unsafe.Pointer> {ctx+8} [2] : CX (ctx+8[unsafe.Pointer])
...
v281 = StoreReg <unsafe.Pointer> v67 : ctx+8[unsafe.Pointer]
The existing buildLocationLists implementation effectively buffers or
bundles changes from zero-width instructions until it it sees a
non-zero-width instruction, but doing that in this case winds up
making it look as though the parameter is live into the function in
memory, not in a register.
The fix for this to separate out zero-width ops into two distinct
categories: those that whose lifetimes begin at block start (ex:
OpArg, Phi) and those whose effects are taking place at the nearest
non-zero-width instruction (ex: OpSelect0). In this patch we now
handle the first category of ops in an initial pre-pass for each
block, and leave the second category for the main pass through the
block. See the notes on the issue below for a more detailed
explanation of the failure mode.
Fixes#46845.
Change-Id: I27488d4c041019d5a0b897b7cf53000f63aab1cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/362244
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently it's quite hard to debug these error messages about ignored symbols
because there are only some numbers and no symbol name. Add symbol name. Before:
135029: sym#952: ignoring symbol in section 11 (type 0)
After:
135029: sym#952 (_ZN11__sanitizer9SpinMutexC5Ev): ignoring symbol in section 11 (type 0)
Change-Id: I7fec50b5798068c74827376613be529803838c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/363034
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitry Vyukov <dvyukov@google.com>
structuralString was used only in one place (for built-in copy).
Remove it in favor of custom and more efficient inlined code.
Follow-up on feedback received for CL 363075.
Change-Id: Ic5857c47255c5c712be7971aae4542fef9960fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/363154
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If we have all channel types in a constraint, there is no structural type
if they don't all have the same channel direction (and identical element
types, of course). By allowing different channel types for the purposes of
the structural type, as long as there is not a send-only _and_ a receive-
only channel in the type set, we make it possible to find a useful, if
restricted by channel direction, structural type where before there was
none.
So if we have unrestricted and send-only channels, the structural type is
the send-only channel, and vice versa.
For all operations on channels that rely on a structural type, it's always
ok to have an unrestricted channel, so this is not affecting their behavior.
But it makes those operations more flexible in the presence of type parameters
containing mixed channel types.
For constraint type inference, where we currently may not infer a channel
at all, this change allows us to infer a more restricted channel (send- or
receive-only). If the inferred channel type is a valid type argument we win;
if not we haven't lost anything.
Use structuralType for send and receive operations and adjust related
error messages (the error message that change are the ones involving
type parameters, so historic error messages are preserved).
Fixes#45920.
Change-Id: If3a64d29c37e7734d3163df330f8b02dd032bc60
Reviewed-on: https://go-review.googlesource.com/c/go/+/363075
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For generic functions, we can export untransformed OKEY nodes, and the
key identifier is written as an ONONAME. But in this case, we do not
want to call Resolve() on the identifier, since we may resolve to a
global type (as happens in this issue) or other global symbol with the
same name, if it exists. We just want to keep the key identifier as an
Ident node.
To solve this, I added an extra bool when exporting an ONONAME entry,
which indicates if this entry is for a key or for a global (external)
symbol. When the bool is true (this is for a key), we avoid calling
Resolve().
Fixes#49497
Change-Id: Ic8fa93d37bcad2110e0e0d060080b733e07e35d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/363074
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Adds a new flag to 'go mod vendor' which overrides the default
'vendor' destination directory. This can be helpful for writing the
vendor tree to a temporary location for use by other tools.
The argument can be a relative or an absolute path.
This flag has no other influence on how the command behaves.
Fixes#47327
Change-Id: I4502931127616b181dc90a2066d2fb57bfe48f96
Reviewed-on: https://go-review.googlesource.com/c/go/+/338149
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This brings the error messages in sync with the terminology that
will be used it the spec.
Change-Id: Ia05993776c649be9eb2cdf948a583b9a49f9b192
Reviewed-on: https://go-review.googlesource.com/c/go/+/362997
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
- move structuralType/structuralString into type.go
- move functions exported for the compiler into compilersupport.go
- updated/added comments
- removed AsNamed and AsInterface - not needed by compiler
No semantic changes.
Change-Id: Ia454a49edafd627c2a25b0b71db4aa93ddd7f1f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/362995
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>
And rename structureString to structuralString.
Now that we have an updated definition for structural types in
the (forthcoming) spec, name the corresponding function accordingly.
No semantic changes.
Change-Id: Iab838f01a37075bedf2d8bc4f166b0217672b85f
Reviewed-on: https://go-review.googlesource.com/c/go/+/362994
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We have V and T and Vu and Tu. When calling the various isX predicates
consistently use Vu and Tu.
(We could also use V an T because the predicates call under anyway,
but using Vu and Tu removes an unnecessary call to Named.under if
V or T are *Named.)
Also, removed some outdated comments.
Change-Id: I6fcd9ce5f6292e89ac2afd597b72fd0790e84ff1
Reviewed-on: https://go-review.googlesource.com/c/go/+/362895
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>
If we reach a generic type that is part of a cycle
and we are in a type parameter list, we have a cycle
through a type parameter list, which is invalid.
Fixes#49439.
Change-Id: Ia6cf97e1748ca0c0e61c02841202050091365b0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/361922
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Also, invert the boolean result. This matches Checker.validType;
it's also easier to understand. Preparation for the next CL which
detects cycles through type parameter lists.
Change-Id: I00a75d2359ca20827c9bf406945508716c826fc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/362336
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
[ this is a roll-forward of golang.org/cl/357169 with minor changes
to fix the cmd/go/internal/modload tests: because they don't run the
go command, some initialization isn't run on the test and modroots is
empty in cases it can't be when the full command setup is done. So
directly check for workFilePath != "" instead of calling inWorkspaceMode
which checks that Init is called first, and check that modRoots is non
empty when calling mustGetSingleMainModule.]
This change corrects a bug in the handling of module loading of
workspaces. Namely, there is an assumption by the module pruning code
that if a root module is selected then the packages of that module can
be resolved without loading the whole module graph. This is not true
in workspace mode because two workspace modules can require different
versions of a dependency. Worse, one workspace module can directly
require a depencency that is transitively required by another
workspace module, changing the version of that module loaded in the
fully expanded graph.
To correct this, a new 'workspace' pruning mode is added where the
roots are the workspace modules themselves, satisfying the assumption
made by the module pruning logic.
The rest of this change accounts for the new pruning mode where it's
used and correctly sets the requirements in this pruning mode.
Change-Id: I8bdf4b30f669c1ded0ed8a5dd202ac8d1939bbbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/362754
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, when a command scheduled by bgrun fails, bgwait returns to
the caller even in case the fatal error was detected.
In case of a syntax error in one of the standard packages, as an
example, the runInstall function will try to read the generated archive
file, only to fail since the file does not exist. Since the runInstall
function is called in a goroutine, cmd/dist will continue to report
errors until all background goroutines are done.
Update the bgwait function to wait until program termination in case of
a fatal error, since returning to the caller (with an error, as an
example) will cause cmd/dist to report an additional error during the
next build phase.
Fixes#45410
Change-Id: If89976abad70f8d6ec79b2a5a1f2306e9c034c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320311
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This enhances the existing line number test
to allow a specific -gcflags (e.g., -G=3)
and to permit ignoring duplicate line numbers
(which is arguably a bug, but not THIS bug,
and it lowers the risk of a flaky test).
Limited to Linux/Darwin and amd64/arm64,
also tests with "unified" mangling.
And, using these new powers, adds a test.
Updates #49436.
Change-Id: I09c82e6a08d53edd5a752522a827e872d3e16e0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/362714
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the tools module, keeping mod unchanged because
its lastest commit isn't ready to be vendored yet.
For #36905.
Updates #49350.
Change-Id: Ib39713d28a55fc9ec79058aab9919eba912def5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/361094
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the crypto module, as well as the TestDependencies
policy to accommodate the dependency order change done in CL 345649.
The next CL will update further modules.
For #36905.
Change-Id: If93160d8d72ca86e9995aaf5bdfc3d2c20b4695d
Reviewed-on: https://go-review.googlesource.com/c/go/+/362736
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The Go 1.18 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
This CL updates only the lower-level modules arch, sys, term for better
bisection. The next CL will update further ones.
For #36905.
Change-Id: I455428c051ec49b446b8b558a6f579cd9be4d796
Reviewed-on: https://go-review.googlesource.com/c/go/+/362734
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Since GCC version 11, the 64-bit version of GCC starting files are
now suffixed by "_64" instead of being stored without suffix under
"ppc64" multilib directory.
Change-Id: Ibe53521ed24d36e5f6282e3574849b9ae11a1e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/362594
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
When //go:embed d matches directory d, it embeds the directory
tree rooted at d, but it excludes files beginning with . and _,
as well as files having problematic names that will not be packaged
into modules (names such as .git and com1).
After long discussions on #42328 and #43854, we decided to keep
the behavior of excluding . and _ files by default, but to allow the pattern
prefix 'all:' to override this default. This CL implements that change.
Note that paths like .git and com1 are still excluded, as they must be,
since they will never be packed into a module.
Fixes#43854.
Change-Id: I4f3731e14ecffd4b691fda3a0890b460027fe209
Reviewed-on: https://go-review.googlesource.com/c/go/+/359413
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL reverts CL 361964, rolling forward the original CL 362254 with a
fix for re-entrant expansion via type hashing (compare patchsets 1 and
2).
Change-Id: I62869e50e919f42eb8d6fef5b0d7a5ec8960bd84
Reviewed-on: https://go-review.googlesource.com/c/go/+/362118
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In stencil.go, change doubleCheck to false, which will turn off some
double-checking code which isn't needed generally, now that we have lots
of tests of end-to-end runs.
Also, removed checkDictionary() which is unused and is unlikely to be
useful in the future.
Change-Id: I4e5acceab80f4904b174422bae21ca82cf04f943
Reviewed-on: https://go-review.googlesource.com/c/go/+/361923
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
https://github.com/googleapis/google-cloud-go has changed the default
branch from master to main, causing mod_get_direct failed on longtest.
Change-Id: I8fe0356b2ff532d1fdedbcb1e1832d7335babaa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/361965
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: Bryan C. Mills <bcmills@google.com>
When bulding formal arguments of newly created closure, irgen forgets to
set "..." field attribute, causing type mismatched between the closure
function and the ONAME node represents that closure function.
Fixes#49432
Change-Id: Ieddaa64980cdd3d8cea236a5a9de0204ee21ee39
Reviewed-on: https://go-review.googlesource.com/c/go/+/361961
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Robert Griesemer
Michael Matloob
Dan Scales
Cuong Manh Le
Katie Hockman
Robert Findley
Cherry Mui
Keith Randall
hasheddan
Than McIntosh
Dmitry Vyukov
Paschalis Tsilias
emahiro
Manlio Perillo
David Chase
Dmitri Shuralyov
Chaoqun Han
Clément Chigot
Russ Cox