In CL 424734, I implemented pointer shaping for unified IR. Evidently
though, we didn't have any test cases that check that uses of
pointer-shaped expressions were handled correctly.
In the reported test case, the struct field "children items[*node[T]]"
gets shaped to "children items[go.shape.*uint8]" (underlying type
"[]go.shape.*uint8"); and so the expression "n.children[i]" has type
"go.shape.*uint8" and the ".items" field selection expression fails.
The fix implemented in this CL is that any expression of derived type
now gets an explicit "reshape" operation applied to it, to ensure it
has the appropriate type for its context. E.g., the "n.children[i]"
OINDEX expression above gets "reshaped" from "go.shape.*uint8" to
"*node[go.shape.int]", allowing the field selection to succeed.
This CL also adds a "-d=reshape" compiler debugging flag, because I
anticipate debugging reshaping operations will be something to come up
again in the future.
Fixes#54535.
Change-Id: Id847bd8f51300d2491d679505ee4d2e974ca972a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424936
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
During walk, we sometimes desugar OEQ nodes into multiple "untyped
bool" expressions, and then use typecheck.Conv to convert back to the
original OEQ node's type.
However, typecheck.Conv had a short-circuit path that if the type is
already identical to the target type according to types.Identical,
then we skipped the conversion. This short-circuit is normally fine;
but with generic code and shape types, it considers "untyped bool" and
"go.shape.bool" to be identical types. And we could end up leaving an
expression of "untyped bool", which then fails an internal consistency
check later.
The simple fix is to change Conv to use types.IdenticalStrict, so that
we ensure "untyped bool" gets converted to "go.shape.bool". And for
good measure, make the same change to ConvNop.
This issue was discovered and reported against unified IR, but the
issue was latent within the non-unified frontend too.
Fixes#54537.
Change-Id: I7559a346b063349b35749e8a2da704be18e51654
Reviewed-on: https://go-review.googlesource.com/c/go/+/424937
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
To disambiguate local types, we append a "·N" suffix to their name and
then trim it off again when producing their runtime type descriptors.
However, if a local type is generic, then we were further appending
the type arguments after this suffix, and the code in types/fmt.go
responsible for trimming didn't know to handle this.
We could extend the types/fmt.go code to look for the "·N" suffix
elsewhere in the type name, but this is risky because it could
legitimately (albeit unlikely) appear in struct field tags.
Instead, the most robust solution is to just change the mangling logic
to keep the "·N" suffix at the end, where types/fmt.go can easily and
reliably trim it.
Note: the "·N" suffix is still visible within the type arguments
list (e.g., the "·3" suffixes in nested.out), because we currently use
the link strings in the type arguments list.
Fixes#54456.
Change-Id: Ie9beaf7e5330982f539bff57b8d48868a3674a37
Reviewed-on: https://go-review.googlesource.com/c/go/+/424901
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When handling a type declaration like:
```
type B A
```
unified IR has been writing out that B's underlying type is A, rather
than the underlying type of A.
This is a bit awkward to implement and adds complexity to importers,
who need to handle resolving the underlying type themselves. But it
was necessary to handle when A was declared like:
```
//go:notinheap
type A int
```
Because we expected A's not-in-heap'ness to be conferred to B, which
required knowing that A was on the path from B to its actual
underlying type int.
However, since #46731 was accepted, we no longer need to support this
case. Instead we can write out B's actual underlying type.
One stumbling point though is the existing code for exporting
interfaces doesn't work for the underlying type of `comparable`, which
is now needed to implement `type C comparable`. As a bit of a hack, we
we instead export its underlying type as `interface{ comparable }`.
Fixes#54512.
Change-Id: I0fb892068d656f1e87bb8ef97da27756051126d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/424854
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The hours, minutes, and seconds fields for time zones
should not have any plus or minus signs.
Use getnum instead of atoi since the latter implicitly
handles leading signs, while the former does not.
Fixes#54570
Change-Id: If9600170af3af999739c27d81958e3649946913a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425038
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Rob Pike <r@golang.org>
The error return value of the seconds field is overwritten
and not checked in the presence of a fractional second.
Perform an explicit check for errors.
Fixes#54569
Change-Id: I1204c8bdcd5a5a09b773d9e44748141ed1e5cb20
Reviewed-on: https://go-review.googlesource.com/c/go/+/425036
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Rob Pike <r@golang.org>
This modifies the code to match the comment such that
the behavior truly is identical to stdSecond case.
Also, it modifies the behavior to match the documented
behavior where:
Fractional seconds are truncated to nanosecond precision.
Fixes#54567
Updates #48685
Change-Id: Ie64549e4372ab51624c105ad8ab4cc99b9b5a0b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/425037
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This lock is acquired under trace.lock, which as of CL 418956
(6c2e327e35) must be acquired on the system stack, so this lock must
be, too.
Fixes#54553.
Change-Id: I4fb0c0c2dfc3cb94b76673e842ad416305a31238
Reviewed-on: https://go-review.googlesource.com/c/go/+/425097
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Previously we convert $0 to the ZR register for some reasons, which causes
two problems:
1. Confusion, the special case of the ZR register needs to be considered
when dealing with constants. For encoding, some places we encode ZR, and
some places we encode $0, although we have converted $0 to ZR.
2. Unexpected instruction format. All instructions that support ZR register
operands can be replaced by $0.
This patch removes this conversion. Note that this patch may cause previously
unintendedly supported instruction formats to no longer be supported.
Change-Id: I3d8d2c06711b7614a38191397da7776417f1861c
Reviewed-on: https://go-review.googlesource.com/c/go/+/404316
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I50e5609ff9c5f2b216b93cec7fb5214d196cae90
Reviewed-on: https://go-review.googlesource.com/c/go/+/412537
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This is both simpler and more performant.
Change-Id: I398de29230e578fb7caf1765df7b8fe84d4e8876
Reviewed-on: https://go-review.googlesource.com/c/go/+/412336
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We don't need compression enabled here, because we only set one question in the dns message. So there is nothing to compress. Also it reduces 8 allocs per LookupHost.
Change-Id: I0968f837011daf6d7a7b22d9af4a8cc5b2878f4c
GitHub-Last-Rev: 7eb3362bca
GitHub-Pull-Request: golang/go#54576
Reviewed-on: https://go-review.googlesource.com/c/go/+/425043
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
On ARM64 we use two separate instructions to compute the hi and lo
results of a 64x64->128 multiplication. Lower to two separate ops
so if only one result is needed we can deadcode the other.
Fixes#54607.
Change-Id: Ib023e77eb2b2b0bcf467b45471cb8a294bce6f90
Reviewed-on: https://go-review.googlesource.com/c/go/+/425101
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
There is already a skip in case of a later failure in the same test on
these platforms. Skip the failure if it occurs earlier too.
For #43120.
Change-Id: Id530370caa6a7df8cae593f6fdcb66871b86b125
Reviewed-on: https://go-review.googlesource.com/c/go/+/425096
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Use OpVarDef only when the variable being defined has pointers in it.
VarDef markers are only used for liveness analysis, and that only
runs on pointer-ful variables.
Fixes#53810
Change-Id: I09b0ef7ed31e72528916fe79325f80bbe69ff9b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/419320
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Neither are currently used. These concepts only need to exist
in the ssa backend (as ssa.OpVarDef and ssa.OpVarLive).
Change-Id: I8d6bd14aa7967b2156e5e9a103b95146e5552f36
Reviewed-on: https://go-review.googlesource.com/c/go/+/419319
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
os/exec.Cmd.Wait closes the read end of os/exec.Cmd.StdoutPipe, meaning
that io.ReadAll can return fs.ErrClosed if the child exits too early,
allowing Wait to complete. The StdoutPipe docs already note this sharp
edge.
Move cmd.Wait until after we finish waiting on stdout. If the child
crashes for some reason, the write end of the pipe will implicitly close
causing io.ReadAll to return as well, so we won't get stuck.
Fixes#52725.
Change-Id: Ifae5745d86206879af2f1523a664236972e07252
Reviewed-on: https://go-review.googlesource.com/c/go/+/420597
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The existing decode() method offers the ability to keep just one
frame of the GIF image, however it will read and decompress all
subsequent frames regardless.
Fixes#41142
Change-Id: I0c3c11f9c11cd487b6c365e9a8b98e617d555db0
GitHub-Last-Rev: 03ebc8ee7b
GitHub-Pull-Request: golang/go#46813
Reviewed-on: https://go-review.googlesource.com/c/go/+/329329
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Paul Tyng <paul@paultyng.net>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Nigel Tao (INACTIVE; USE @golang.org INSTEAD) <nigeltao@google.com>
Check for malformed data when reading the number of aux
symbols associated with a symbol table entry.
Fixes#54584.
Change-Id: Ic2a8d4d6a1d481d585a065b8182de86294c3d3d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/425049
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
I was profiling the cpu usage of go/printer's only benchmark,
and found that token.File.Unpack was one of the top offenders.
It was mainly the deferred unlock that took a big chunk of time,
and to my surprise, reoving the use of defer helped significantly:
name old time/op new time/op delta
Print-16 5.61ms ± 2% 5.38ms ± 1% -4.04% (p=0.000 n=10+8)
name old speed new speed delta
Print-16 9.27MB/s ± 2% 9.64MB/s ± 1% +4.03% (p=0.000 n=9+8)
name old alloc/op new alloc/op delta
Print-16 332kB ± 0% 332kB ± 0% ~ (p=0.363 n=10+10)
name old allocs/op new allocs/op delta
Print-16 3.45k ± 0% 3.45k ± 0% ~ (all equal)
It seems like #38471 is to blame, as the defer prevents Unlock from
being inlined. Add a TODO as a reminder to come back here once the
compiler issue is fixed.
Change-Id: I5a1c6d36a8e8357435a305a1bc0970ee0358b08a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424920
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ReadData follows the error semantics of io.ReadFull for small sizes,
it should do so as well for large sizes.
Change-Id: I6a11b00d903ac5332e1dda074473790dcf21f32a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424919
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
We don't have a good musl detection mechanism, so we detect Alpine (the
most common user of musl) instead.
For #39857.
For #19938.
Change-Id: I2fa39248682aed75884476374fe2212be4427347
Reviewed-on: https://go-review.googlesource.com/c/go/+/425001
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
To avoid false positives from the reflectvaluecompare checker #43993
Use v.IsValid() instead of
var zero reflect.Value
v != zero
Also avoid comparing directly with the singleton reflect.Value
representing a missing value. Detect the missing value by type instead.
Change-Id: I3a00d63cf61c077e7c7ae816474aa1f032be325b
Reviewed-on: https://go-review.googlesource.com/c/go/+/308769
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This makes it possible to use `disasm` with ASLR windows binaries.
For #46639
Change-Id: I08aff38dc0b33fdfb07e0206766db066e33207d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/416976
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Occasionally the signal will be sent to a Go thread, which will cause
the program to exit with SIGQUIT rather than SIGSEGV.
Add TestSignalForwardingGo to test the case where the signal is
expected to be delivered to a Go thread.
This is a roll forward of CL 419014 which was rolled back in CL 424954.
This CL differs from 419014 in that it skips TestSignalForwardingGo
on darwin-amd64.
Fixes#53907
Change-Id: I5df3fd610c068df3bd48d9b3d7a9379248b97999
Reviewed-on: https://go-review.googlesource.com/c/go/+/425002
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Change-Id: Idc1f8b3fb6b4b2fdcc6dade048cc14c53715319f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424197
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Avoid allocating large amounts of memory for corrupt input.
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
Fixes#53787
Change-Id: I1b75a4c000b8d1112110309ec44b0ba9b4638d71
Reviewed-on: https://go-review.googlesource.com/c/go/+/416861
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Avoid allocating large amounts of memory for corrupt input.
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
Fixes#52521
Change-Id: I6a046f2e28e1255cf773ce135c5bb2b967ef43e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/414234
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This follows on CL 407176 which added this function (in both
packages). This CL makes it consistent with the Cut function,
which uses “before” and “after” in return variable names.
Change-Id: Id4345d2fe0f50bf301a880803e87bf356986b518
Reviewed-on: https://go-review.googlesource.com/c/go/+/424922
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Depending on the implementation of the getrusage syscall/function, the
value of rusage.Maxrss may be undefined in case of an error. Thus, only
report MaxRSS in case of no error.
Change-Id: I7572ccc53c49eb460e53bded3eb41736eed8d2ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/424815
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Use "method has no receiver" and "method has multiple receivers"
in error messages for invalid receiver counts, matching the
corresponding types2 errors.
For #54511.
Change-Id: I96fc99440d6206c74e9416069db052234baa8248
Reviewed-on: https://go-review.googlesource.com/c/go/+/424934
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Use "middle" and "final" rather than "2nd" and "3rd" in error messages
for invalid slice expressions. This is the original compiler error
message and many tests check for this specific message.
For #54511.
Change-Id: I86eb739aa7218b7f393fab1ab402732cb9e9a1f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/424906
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Use "invalid" rather than "incomparable" in error message for map key
types that are not comparable. This is the original compiler error
message and many tests check for this specific message. The type
checker does provide an additional explanation if the reason for
the error is not obvious (e.g. for type parameters).
For #54511.
Change-Id: Idb76c48b4dfbfd66a7deac728a552e07f14e06d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/424905
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Use same approach to parsing const and var declarations
as the syntax package. Specifically, don't complain if
the first const specification in a const declaration
doesn't have a type and initialization expression. This
removes some duplicate errors when combined with the
type checker.
Adjust corresponding type checker tests accordingly.
For #54511.
Change-Id: I96702eba51dda6b581dad44577a7f93e4c02c857
Reviewed-on: https://go-review.googlesource.com/c/go/+/424904
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Change-Id: Ia00acf248f3498d75e2451548f82d3c57cfed06f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424995
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Make spelling consistent with uses in other error messages.
Change-Id: I584cd22413842fb8bae1632ed34c8b0e7ef163cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/424902
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
All code may be generic. Remove machinery to select parsing
mode (generic vs non-generic) since the parser doesn't support
this anymore. Adjust tests to more closely match corresponding
types2 code.
Change-Id: Id2398afe64d58714974ec96656fdf67c02ff5d04
Reviewed-on: https://go-review.googlesource.com/c/go/+/424900
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Generics are part of the language now; there's no need anymore
to switch back to a syntax without generics. Remove the associated
machinery and adjust short tests accordingly.
Change-Id: I6b16c5c75fd9354ee87e3b9bee110f49f514565a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424857
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The validity of an import path string is checked by the type checker
(and possibly other tools); it doesn't need to be done by the parser.
Remove the respective code and tests.
Also, adjust a corresponding go/types test which resolves a TODO.
For #54511.
Change-Id: Id1fc80df4e3e83be3ef123da3946ccb8f759779f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424855
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Since the examples tests are now identical between the two type checkers,
remove the local copy of the examples tests and (for now) use the tests
in go/types/testdata/examples instead. Eventually we may decide to move
all tests out of the type checker directories and place them in a
shared space (e.g. internal/types/testdata).
For #54511.
Change-Id: Ibd8599d09e781b2219a23114b4b2049757971181
Reviewed-on: https://go-review.googlesource.com/c/go/+/424695
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
