This is a port of CL 338469 to go/types.
Change-Id: I3ee655fa2dc7e789f210c8dec171b3358c4ff132
Reviewed-on: https://go-review.googlesource.com/c/go/+/339677
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 is a clean port of CL 338309 to go/types.
Change-Id: Ie2c9e2ea51d6321af8bf149e43cd71b7ac282d13
Reviewed-on: https://go-review.googlesource.com/c/go/+/339676
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 is a straightforward port of CL 338196 to go/types, minus the
deprecated TypeParam.Bound() method (since it is not needed), plus an
adjustment for methodset.go.
Change-Id: Ie372bfeec245094102a2c3257a43499d75981447
Reviewed-on: https://go-review.googlesource.com/c/go/+/339675
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 is a straightforward port of CL 338092 to go/types.
Change-Id: I414ec0ad95648c201e85fd2b4f494b1206c658e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/339674
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 static == false, missingMethod incorrectly continues with a nil
Func.
Also remove some unnecessary type names from typeterm_test.go, which was
done in the go/types port.
Change-Id: I21fa637ac82b115563d3601314a470a5a43f9ae0
Reviewed-on: https://go-review.googlesource.com/c/go/+/339672
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 338049 to go/types. It identical to that CL, except
for eliding unnecessary typenames from the testTerms declaration.
Change-Id: Ieb04d7bbc20063044eb63ea985f75d529f030cd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/339653
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 is a port of CL 337354 to go/types, adjusted for the error
reporting API and to reposition a couple error messages in
issue47411.go2 (the go/types position is probably better).
A panic is also fixed in lookup.go when method lookup fails and static
== false. I'll send a fix for types2 in a separate CL.
For #47411
Change-Id: Icc48f03c3958695f581f10e8675c1f32434c424b
Reviewed-on: https://go-review.googlesource.com/c/go/+/339652
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 is a port of CL 337353 to go/types, adjusted for the error API and
to comment out a test for MethodSet.
Some nearby error messages that were using errorf rather than error were
also adjusted.
Fixes#43621
Change-Id: I28c9747e044ec7a2863f6890db69475fb8c29231
Reviewed-on: https://go-review.googlesource.com/c/go/+/339651
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 is a clean port of CL 336989 to go/types.
Change-Id: Ib8dbe03f420d28ada6d5fc7003ab0c82c7e06c41
Reviewed-on: https://go-review.googlesource.com/c/go/+/339650
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 is a port of CL 335413 to go/types, adjusted for the parsing API of
go/parser.
Change-Id: Ie6836add7d027aaf5d6d3dae65222b1d15bd7558
Reviewed-on: https://go-review.googlesource.com/c/go/+/339649
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>
Currently, freedefer manually zeros all the fields in the _defer
because simply assigning _defer{} used to cause a nosplit stack
overflow. freedefer is no longer nosplit, so go back to the simpler,
more robust code.
Change-Id: I881f557bab3b1ee7ab29b68e7fb56d0fe6d35d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/339669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.
This unusual flow control leads to a large number of special cases and
complications all over the tool chain.
This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.
This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.
This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.
This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.
This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.
The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.
This is a retry of CL 337652 because we had to back out its parent.
There are no changes in this version.
Change-Id: I3f54b7fec1d7ccac71cc6cf6835c6a46b7e5fb6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/339397
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Prior to regabi, the compiler passed defer arguments to the runtime as
untyped values on the stack. This meant a lot of defer-related runtime
functions had to be very careful not to grow the stack or allow
preemption since the stack could not be safely scanned or moved.
However, with regabi, every defer is now simply a func() from the
runtime's perspective, which means we no longer have untyped values on
the stack when we enter defer-related runtime code.
Hence, this CL removes a lot of the now-unnecessary carefulness in the
defer implementation. Specifically, deferreturn no longer needs to be
nosplit because it doesn't copy untyped defer arguments to its
caller's frame (we also update some stale comments in deferreturn).
freedefer no longer needs to be nosplit because it's none of its
callers are deeply nosplit. And newdefer and freedefer no longer need
to switch to the systemstack on their slow paths to avoid stack
growth.
deferprocStack is the only function that still needs to be nosplit,
but that's because the compiler calls it with uninitialized live
pointer slots on the stack (maybe we should change that, but that's a
very different fix).
This is a retry of CL 337651, which was rolled back. This version
disables preemption in newdefer and freedefer while they hold the
current P.
Change-Id: Ibf469addc0b69dc3ba9a3d1a5e0c2804b7b4b244
Reviewed-on: https://go-review.googlesource.com/c/go/+/339396
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently, unified IR takes a simple approach of generating method
wrappers for every anonymous type that it sees. This is correct, but
spends a lot of time in code generation and bloats the object files
with duplicate method wrappers that the linker discards.
This CL changes it to distinguish anonymous types that were found in
imported packages vs the local package. The simple win here is that
now we stop emitting wrappers for imported types; but by keeping track
of them and marking them as "have" instead of "need", we can avoid
emitting wrappers for types that appear in both the local package and
imported packages.
This can be improved further, but this is a simple first step that
prevents large protobuf projects from blowing up build cache limits.
Change-Id: Ia65e8981cb1f067eca2bd072b9bbb77c27b95207
Reviewed-on: https://go-review.googlesource.com/c/go/+/339411
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The code for generating method value wrappers is weird that it sets
sym.Def to the generated ir.Func, whereas normally sym.Def points to
ir.Name.
While here, change methodValueWrapper to return the ir.Name too, since
that's what the caller wants.
Change-Id: I3da5320ca0bf4d32d7b420345454f19075d19a26
Reviewed-on: https://go-review.googlesource.com/c/go/+/339410
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Previously, softfloat mode does not work with register ABI, mainly
because the compiler doesn't know how to pass floating point
arguments and results. According to the ABI it should be passed in
FP registers, but there isn't any in softfloat mode.
This CL makes it work. When softfloat is used, we define the ABI
as having 0 floating point registers (because there aren't any).
The integer registers are unchanged. So floating point arguments
and results are passed in memory.
Another option is to pass (the bit representation of) floating
point values in integer registers. But this complicates things
because it'd need to reorder integer argument registers.
Change-Id: Ibecbeccb658c10a868fa7f2dcf75138f719cc809
Reviewed-on: https://go-review.googlesource.com/c/go/+/327274
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In unified IR, fail right away if we find a types2.Invalid while
writing out the package. This provides a clearer error message for
https://github.com/golang/go/issues/25838#issuecomment-448746670.
Updates #25838.
Change-Id: I6902fdd891fc31bbb832b6fdba00eca301282409
Reviewed-on: https://go-review.googlesource.com/c/go/+/338973
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
- Changed some early returns to asserts (instantiateMethods and Shapify
should never take a shape arg)
- Added suggested change (by Ingo) to use copy() in getInstantiation()
- Clarified that shape types never have methods in Shapify(), removed
some TODO comments.
Change-Id: Ia2164ffe670a777f7797bbb45c7ef5e6e9e15357
Reviewed-on: https://go-review.googlesource.com/c/go/+/338971
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
This just moves the code around the instance type into named.go
where it belongs. While at it, also removed some left-over references
to instance types (which are gone). Removed instance.go.
Change-Id: I302a86ca50675b0be54f6138fa47f48f00f9c98f
Reviewed-on: https://go-review.googlesource.com/c/go/+/338469
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Implement HasShape() similar to how HasTParam() is implemented.
Fixes#47456
Change-Id: Icbd538574237faad2c4cd8c8e187725a1df47637
Reviewed-on: https://go-review.googlesource.com/c/go/+/339029
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Fixes#47485
Change-Id: I64ac00905a403b7594c706141679051a93058a31
Reviewed-on: https://go-review.googlesource.com/c/go/+/338889
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Currently, most softfloat functions take uint32/64 arguments (for
bit representation of float32/64) and operate on uint32/64. But
there are exeptions where the function take float arguments and
operate on float. So they are only actually softfloat if the
helper functions themselves are translated (by the compiler's
softfloat mode). These are mostly fine (besides being a bit
convoluted). But with register ABIs this inconsistency adds
complexity to the compiler to generate such calls, because it
needs to be called with the right ABI.
Rewrite the functions to operate on uint32/64 directly, using
other helper functions. So they all take uint32/64 arguments and
return uint32/64.
Change-Id: Id9383b74bcbafee44160cc5b58ab245bffbbdfd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/327273
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Except unsafe.Pointer. It has a different Kind, which makes it trickier.
Change-Id: I12582afb6e591bea35da9e43ac8d141ed19532a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/338749
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>
go mod editwork behaves similarly to go mod edit:
it has flags to change the go version, and add and remove
directory and replace directives.
For #45713
Change-Id: I1c795c122bfe461d6e87dd731692e0bf1bbe2bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/334938
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>
modload.Replacement and modload.resolveReplacement now also return
the modroot of the module providing a replacement so that we can
correctly construct the path of a replaced module (because the
path in the module.Version is relative to the modroot).
For #45713
Change-Id: I8c69ccbcc1f40201071e35fcf93d6b5d0ed4cdf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/334941
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>
If the user is in a workspace, they might not be in the main module
they need to run go get from to add a module that provides a missing
dependency. Figure out what that module is from the import stack (there
might be multiple but we pick according to the stack computed by
the loader for errors) and tell the user to cd to that directory
first in the message.
Change-Id: I7c919eb61ea3dd122334ff1acd2d7e817cad4b25
Reviewed-on: https://go-review.googlesource.com/c/go/+/334940
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>
Change-Id: Iedbe47d087d17984a9d839c13c4b7e6c1fa0deaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/338594
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>
This reverts CL 227652.
I'm reverting CL 337651 and this builds on top of it.
Change-Id: I03ce363be44c2a3defff2e43e7b1aad83386820d
Reviewed-on: https://go-review.googlesource.com/c/go/+/338709
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
First baby step to sharing the underlying implementation among several types.
Change-Id: I6a156176d2b7f0131a87285a03b881ce380c26ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/338610
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>
Currently, deferreturn runs deferred functions by backing up its
return PC to the deferreturn call, and then effectively tail-calling
the deferred function (via jmpdefer). The effect of this is that the
deferred function appears to be called directly from the deferee, and
when it returns, the deferee calls deferreturn again so it can run the
next deferred function if necessary.
This unusual flow control leads to a large number of special cases and
complications all over the tool chain.
This used to be necessary because deferreturn copied the deferred
function's argument frame directly into its caller's frame and then
had to invoke that call as if it had been called from its caller's
frame so it could access it arguments. But now that we've simplified
defer processing so the runtime only deals with argument-less
closures, this approach is no longer necessary.
This CL simplifies all of this by making deferreturn simply call
deferred functions in a loop.
This eliminates the need for jmpdefer, so we can delete a bunch of
per-architecture assembly code.
This eliminates several special cases on Wasm, since it couldn't
support these calling shenanigans directly and thus had to simulate
the loop a different way. Now Wasm can largely work the way the other
platforms do.
This eliminates the per-architecture Ginsnopdefer operation. On PPC64,
this was necessary to reload the TOC pointer after the tail call
(since TOC pointers in general make tail calls impossible). The tail
call is gone, and in the case where we do force a jump to the
deferreturn call when recovering from an open-coded defer, we go
through gogo (via runtime.recovery), which handles the TOC. On other
platforms, we needed a NOP so traceback didn't get confused by seeing
the return to the CALL instruction, rather than the usual return to
the instruction following the CALL instruction. Now we don't inject a
return to the CALL instruction at all, so this NOP is also
unnecessary.
The one potential effect of this is that deferreturn could now appear
in stack traces from deferred functions. However, this could already
happen from open-coded defers, so we've long since marked deferreturn
as a "wrapper" so it gets elided not only from printed stack traces,
but from runtime.Callers*.
Change-Id: Ie9f700cd3fb774f498c9edce363772a868407bf7
Reviewed-on: https://go-review.googlesource.com/c/go/+/337652
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Prior to regabi, the compiler passed defer arguments to the runtime as
untyped values on the stack. This meant a lot of defer-related runtime
functions had to be very careful not to grow the stack or allow
preemption since the stack could not be safely scanned or moved.
However, with regabi, every defer is now simply a func() from the
runtime's perspective, which means we no longer have untyped values on
the stack when we enter defer-related runtime code.
Hence, this CL removes a lot of the now-unnecessary carefulness in the
defer implementation. Specifically, deferreturn no longer needs to be
nosplit because it doesn't copy untyped defer arguments to its
caller's frame (we also update some stale comments in deferreturn).
freedefer no longer needs to be nosplit because it's none of its
callers are deeply nosplit. And newdefer and freedefer no longer need
to switch to the systemstack on their slow paths to avoid stack
growth.
deferprocStack is the only function that still needs to be nosplit,
but that's because the compiler calls it with uninitialized live
pointer slots on the stack (maybe we should change that, but that's a
very different fix).
Change-Id: I1156ec90bff2613fe4b48b84b375943349ce637d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337651
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Prior to regabi, a deferred function could have any signature, so the
runtime always manipulated them as funcvals. Now, a deferred function
is always func(). Hence, this CL makes the runtime's manipulation of
deferred functions more type-safe by using func() directly instead of
*funcval.
Change-Id: Ib55f38ed49107f74149725c65044e4690761971d
Reviewed-on: https://go-review.googlesource.com/c/go/+/337650
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The CC and CXX environment variables now support spaces and quotes
(both double and single). This fixes two issues: first, if CC is a
single path that contains spaces (like 'c:\Program
Files\gcc\bin\gcc.exe'), that should now work if the space is quoted
or escaped (#41400). Second, if CC or CXX has multiple arguments (like
'gcc -O2'), they are now split correctly, and the arguments are passed
before other arguments when invoking the C compiler. Previously,
strings.Fields was used to split arguments, and the arguments were
placed later in the command line. (#43078).
Fixesgolang/go#41400Fixesgolang/go#43078
Change-Id: I2d5d89ddb19c94adef65982a8137b01f037d5c11
Reviewed-on: https://go-review.googlesource.com/c/go/+/334732
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
JoinAndQuoteFields does the inverse of SplitQuotedFields: it joins a
list of arguments with spaces into one string, quoting arguments that
contain spaces or quotes.
QuotedStringListFlag uses SplitQuotedFields and JoinAndQuoteFields
together to define new flags that accept lists of arguments.
For golang/go#41400
Change-Id: I4986b753cb5e6fabb5b489bf26aedab889f853f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/334731
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This will let cmd/cgo and cmd/link use this package for argument parsing.
For golang/go#41400
Change-Id: I12ee21151bf3f00f3e8d427faaaab2453c823117
Reviewed-on: https://go-review.googlesource.com/c/go/+/334730
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reading from an incoming request body after the request handler aborts
with a panic can cause a panic, becuse http.Server does not (contrary
to its documentation) close the request body in this case.
Always close the incoming request body in ReverseProxy.ServeHTTP to
ensure that any in-flight outgoing requests using the body do not
read from it.
Updates #46866
Fixes CVE-2021-36221
Change-Id: I310df269200ad8732c5d9f1a2b00de68725831df
Reviewed-on: https://go-review.googlesource.com/c/go/+/333191
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
When CL 336252 was created (itself a port of CL 335929), types2
tests revealed that lazy expansion of instances was not behaving
correctly with respect to lazy loading of Named types.
This CL ports the fixes from CL 336252 back to go/types.
Change-Id: Iffc6c84a708449633153b800dfb98ff57402893c
Reviewed-on: https://go-review.googlesource.com/c/go/+/338369
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Comparable type no longer has a special method '=='.
Change-Id: I152f324d83343a66300050479181a6607fb7ca26
Reviewed-on: https://go-review.googlesource.com/c/go/+/338409
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Presumably the "It is safe to call on a nil receiver" comment was
mistakenly copied from TypeParams.Len, which is actually safe to call
on a nil receiver.
Change-Id: Iec5ae32c98dc91ce84a6207b47f2b1e530bdbfe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/338430
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: Id68d41f09e78343953167cb1e38fb1ebc41a34d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/338429
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The other uses of Unshapify were really only there to allow for the
dictionary checking code at the beginning of generic functions/methods.
But that will go away as soon as we start combining real shapes. If we
get rid of that code, we can get rid of the unshapify calls elsewhere.
The only tricky part is that getInstantiation now gets targs that may each
either be a shape or concrete type, and it must translate any concrete
types to shapes, while leaving the already existing shapes.
Change-Id: Ib2b9072b921f8e064958548a1078d82f1d040c9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/338289
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>
Rewrite a method expression such as 'T.String' (where T is type param
and String is part of its type bound Stringer) as:
func(rcvr T, other params...) {
return Stringer(rcvr).String(other params...)
}
New function buildClosure2 to create the needed closure. The conversion
Stringer(rcvr) uses the dictionary in the outer function.
For a method expression like 'Test[T].finish' (where finish is a method
of Test[T]), we can already deal with this in buildClosure(). We just
need fix transformDot() to allow the method lookup to fail, since shapes
have no methods on them. That's fine, since for any instantiated
receiver type, we always use the methods on the generic base type.
Also removed the OMETHEXPR case in the main switch of node(), which
isn't needed any (and removes one more potential unshapify).
Also, fixed two small bugs with handling closures that have generic
params or generic captured variables. Need to set the instInfo for the
closure in the subst struct when descending into a closure during
genericSubst() and was missing initializing the startItabConv and gfInfo
fields in the closure info.
Change-Id: I6dadedd1378477936a27c9c544c014cd2083cfb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/338129
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>
This matches the accessor named Constraint, and any documentation we have so far.
Use iface instead of Bound internally to types2; keep Bound because of two external
uses but mark it as deprecated. Adjust clients.
Change-Id: Id1a2c2f28259a16082e875eee0534d46cf157336
Reviewed-on: https://go-review.googlesource.com/c/go/+/338196
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>
This is a clean port of CL 336251.
Change-Id: I08415c3e9b6cef33594e7d56c4115ddde8030381
Reviewed-on: https://go-review.googlesource.com/c/go/+/338193
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 336249 with adjustments due to slightly
different handling of type parameter declaration in types2.
The CL also contains adjustments to the compiler front-end.
With this change it is not necessary to export type parameter
indices. Filed issue #47451 so we don't forget.
Change-Id: I2834f7be313fcb4763dff2a9058f1983ee6a81b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/338192
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>
This field is not needed anymore.
Follow-up on CL 335978 and CL 338097.
Change-Id: I8032e5153ba65c6a4aaf6575ac6d5a15a61f1b81
Reviewed-on: https://go-review.googlesource.com/c/go/+/338098
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
