Error messages currently print floats with %.6g, which means that if
you tried to convert something close to, but not quite, an integer, to
an integer, the error you get looks like "cannot convert 1 to type
int", when really you want "cannot convert 0.9999999 to type int".
Add more digits to floats when printing them, to make it clear that they
aren't quite integers. This helps for errors which are the result of not
being an integer. For other errors, it won't hurt much.
Fixes#56220
Change-Id: I7f5873af5993114a61460ef399d15316925a15a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/442935
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Using importcfg instead of depending on the existence of .a files for
standard library packages will enable us to remove the .a files in a
future cl.
Change-Id: I6108384224508bc37d82fd990fc4a8649222502c
Reviewed-on: https://go-review.googlesource.com/c/go/+/440222
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
fakePC uses hash.Sum32, which returns an uint32. However, libfuzzer
trace/hook functions declare fakePC argument as int, causing overflow on
386 archs.
Fixing this by changing fakePC argument to uint to prevent the overflow.
Fixes#56141
Change-Id: I3994c461319983ab70065f90bf61539a363e0a2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/441996
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For #56109
Change-Id: I999763e463fac57732a92f5e396f8fa8c35bd2e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/440297
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
CL 403995 fixed static init of literal contains dynamic exprs, by
ensuring their init are ordered properly. However, we still need to walk
the generated init codes before appending to parent init. Otherwise,
codes that requires desugaring will be unhandled, causing the compiler
backend crashing.
Fixes#56105
Change-Id: Ic25fd4017473f5412c8e960a91467797a234edfd
Reviewed-on: https://go-review.googlesource.com/c/go/+/440455
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
The linker needs FuncInfo metadata for all inlined functions. This is
typically handled by gc.enqueueFunc calling ir.InitLSym for all function
declarations in typecheck.Target.Decls (ir.UseClosure adds all closures
to Decls).
However, non-trivial closures in Decls are ignored, and are insteaded
enqueued when walk of the calling function discovers them.
This presents a problem for direct calls to closures. Inlining will
replace the entire closure definition with its body, which hides the
closure from walk and thus suppresses symbol creation.
Explicitly create a symbol early in this edge case to ensure we keep
this metadata.
InitLSym needs to move out of ssagen to avoid a circular dependency (it
doesn't have anything to do with ssa anyway). There isn't a great place
for it, so I placed it in ir, which seemed least objectionable.
The added test triggers one of these inlined direct non-trivial closure
calls, though the test needs CL 429637 to fail, which adds a FuncInfo
assertion to the linker. Note that the test must use "run" instead of
"compile" since the assertion is in the linker, and "compiler" doesn't
run the linker.
Fixes#54959.
Change-Id: I0bd1db4f3539a78da260934cd968372b7aa92546
Reviewed-on: https://go-review.googlesource.com/c/go/+/436240
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
If a cycle has length 1, don't enumerate the single cycle entry;
instead just mention "refers to itself". For instance, for an
invalid recursive type T we now report:
invalid recursive type: T refers to itself
instead of:
invalid recursive type T
T refers to
T
Adjust tests to check for the different error messages.
Change-Id: I5bd46f62fac0cf167f0d0c9a55f952981d294ff4
Reviewed-on: https://go-review.googlesource.com/c/go/+/436295
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
This matches what go/types and types2 report and it also matches
the compiler errors reported for some related shift problems.
For #55326.
Change-Id: Iee40e8d988d5a7f9ff2c49f019884d02485c9fdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/436177
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is close to what the compiler used to say, except now we say
"as T value" rather than "as type T" which is closer to the truth
(we cannot use a value as a type, after all). Also, place the primary
error and the explanation (cause) on a single line.
Make respective (single line) adjustment to the matching "cannot
convert" error.
Adjust various tests.
For #55326.
Change-Id: Ib646cf906b11f4129b7ed0c38cf16471f9266b88
Reviewed-on: https://go-review.googlesource.com/c/go/+/436176
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Compromise between old compiler error "T.m redeclared in this block"
(where the "in this block" is not particularly helpful) and the old
type-checker error "method m already declared for type T ...".
In the case where we have position information for the original
declaration, the error message is "method T.m already declared at
<position>". The new message is both shorter and more precise.
For #55326.
Change-Id: Id4a7f326fe631b11db9e8030eccb417c72d6c7db
Reviewed-on: https://go-review.googlesource.com/c/go/+/435016
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a compromise of the error reported by the compiler (quotes
around field name removed) and the error reported by the type checkers
(added mention of struct type).
For #55326.
Change-Id: Iac4fb5c717f17c6713e90d327d39e68d3be40074
Reviewed-on: https://go-review.googlesource.com/c/go/+/434815
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This matches longstanding compiler behavior.
Also, for unused packages, report:
`"pkg" imported and not used`
`"pkg" imported as X and not used`
This matches the other `X declared and not used` errors.
For #55326.
Change-Id: Ie71cf662fb5f4648449c64fc51bede298a1bdcbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/432557
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
For #55326
Change-Id: I3d0ff7f820f7b2009d1b226abf701b2337fe8cbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/432635
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: xie cui <523516579@qq.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The type of the source and destination of a memmove call isn't
always accurate. It will always be a pointer (or an unsafe.Pointer), but
the base type might not be accurate. This comes about because multiple
copies of a pointer with different base types are coalesced into a single value.
In the failing example, the IData selector of the input argument is a
*[32]byte in one branch of the type switch, and a *[]byte in the other branch.
During the expand_calls pass both IDatas become just copies of the input
register. Those copies are deduped and an arbitrary one wins (in this case,
*[]byte is the unfortunate winner).
Generally an op v can rely on v.Type during rewrite rules. But relying
on v.Args[i].Type is discouraged.
Fixes#55122
Change-Id: I348fd9accf2058a87cd191eec01d39cda612f120
Reviewed-on: https://go-review.googlesource.com/c/go/+/431496
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Now we have 8-byte alignment types on 32-bit system, so in some rare
case, e.g, generated wrapper for embedded interface, the function
argument may need more than 4 byte alignment. We could pad somehow, but
this is a rare case which makes it hard to ensure that we've got it right.
So relaxing the check for argument and return value region of the stack.
Fixes#54991
Change-Id: I34986e17a920254392a39439ad3dcb323da2ea8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/431098
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The unified frontend ICEs when inlining a function that contains a
function literal, which captures both a type switch case variable and
another variable.
Updates #54912.
Change-Id: I0e16d371ed5df48a70823beb0bf12110a5a17266
Reviewed-on: https://go-review.googlesource.com/c/go/+/428917
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
It was fixed by CL 422196, and have been already worked in unified IR.
Fixes#54911
Change-Id: Ie69044a64b296f6961e667e7661d8c4d1a24d84e
Reviewed-on: https://go-review.googlesource.com/c/go/+/428758
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For defer/go calls, the function/method value are evaluated immediately.
So after devirtualizing, it may trigger a panic when implicitly deref
a nil pointer receiver, causing the program behaves unexpectedly.
It's safer to not devirtualizing defer/go calls at all.
Fixes#52072
Change-Id: I562c2860e3e577b36387dc0a12ae5077bc0766bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/428495
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently, gentraceback tracks the closure context of the outermost
frame. This used to be important for "unstarted" calls to reflect
function stubs, where "unstarted" calls are either deferred functions
or the entry-point of a goroutine that hasn't run. Because reflect
function stubs have a dynamic argument map, we have to reach into
their closure context to fetch to map, and how to do this differs
depending on whether the function has started. This was discovered in
issue #25897.
However, as part of the register ABI, "go" and "defer" were made much
simpler, and any "go" or "defer" of a function that takes arguments or
returns results gets wrapped in a closure that provides those
arguments (and/or discards the results). Hence, we'll see that closure
instead of a direct call to a reflect stub, and can get its static
argument map without any trouble.
The one case where we may still see an unstarted reflect stub is if
the function takes no arguments and has no results, in which case the
compiler can optimize away the wrapper closure. But in this case we
know the argument map is empty: the compiler can apply this
optimization precisely because the target function has no argument
frame.
As a result, we no longer need to track the closure context during
traceback, so this CL drops all of that mechanism.
We still have to be careful about the unstarted case because we can't
reach into the function's locals frame to pull out its context
(because it has no locals frame). We double-check that in this case
we're at the function entry.
I would prefer to do this with some in-code PCDATA annotations of
where to find the dynamic argument map, but that's a lot of mechanism
to introduce for just this. It might make sense to consider this along
with #53609.
Finally, we beef up the test for this so it more reliably forces the
runtime down this path. It's fundamentally probabilistic, but this
tweak makes it better. Scheduler testing hooks (#54475) would make it
possible to write a reliable test for this.
For #54466, but it's a nice clean-up all on its own.
Change-Id: I16e4f2364ba2ea4b1fec1e27f971b06756e7b09f
Reviewed-on: https://go-review.googlesource.com/c/go/+/424254
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
So they can be added to ignored list, since the tests now require
cgo.Incomplete, which is not recognized by go/types and types2.
Updates #46731
Change-Id: I9f24e3c8605424d1f5f42ae4409437198f4c1326
Reviewed-on: https://go-review.googlesource.com/c/go/+/427142
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
On AIX when external linking, for some symbols we need to add
dummy references to prevent the external linker from discarding
them. Currently we add the reference unconditionally. But if the
symbol doesn't exist, the linking fails in a later stage for
generating external relocation of a nonexistent symbol. The
symbols are special symbols that almost always exist, except that
go:buildid may not exist if the linker is invoked without the
-buildid flag. The go command invokes the linker with the flag, so
this can only happen with manual linker invocation. Specifically,
test/run.go does this in some cases.
Fix this by checking the symbol existence before adding the
reference. Re-enable tests on AIX.
Perhaps the linker should always emit a dummy buildid even if the
flag is not set...
Fixes#54814.
Change-Id: I43d81587151595309e189e38960cbda9a1c5ca32
Reviewed-on: https://go-review.googlesource.com/c/go/+/427620
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
So it won't be visible outside of runtime package. There are changes to
make tests happy:
- For test/directive*.go files, using "go:noinline" for testing misplaced
directives instead.
- Restrict test/fixedbugs/bug515.go for gccgo only.
- For test/notinheap{2,3}.go, using runtime/cgo.Incomplete for marking
the type as not-in-heap. Though it's somewhat clumsy, it's the easiest
way to keep the test errors for not-in-heap types until we can cleanup
further.
- test/typeparam/mdempsky/11.go is about defined type in user code marked
as go:notinheap, which can't happen after this CL, though.
Fixes#46731
Change-Id: I869f5b2230c8a2a363feeec042e7723bbc416e8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/421882
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The syntax for go and defer specifies an arbitrary expression, not
a call; the call requirement is spelled out in prose. Don't to the
call check in the parser; instead move it to the type checker. This
is simpler and also allows the type checker to check expressions that
are not calls, and avoid "not used" errors due to such expressions.
We would like to make the same change in go/parser and go/types
but the change requires Go/DeferStmt nodes to hold an ast.Expr
rather than an *ast.CallExpr. We cannot change that for backward-
compatibility reasons. Since we don't test this behavior for the
type checkers alone (only for the compiler), we get away with it
for now.
Follow-up on CL 425675 which introduced the extra errors in the
first place.
Change-Id: I90890b3079d249bdeeb76d5673246ba44bec1a7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/425794
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
- Use "expected X" rather then "expecting X".
- Report a better error when a type argument list is expected.
- Adjust various tests.
For #54511.
Change-Id: I0c5ca66ecbbdcae1a8f67377682aae6b0b6ab89a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425734
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
If the go/defer syntax is bad, using a fake CallExpr may produce
a follow-on error in the type checker. Instead store a BadExpr
in the syntax tree (since an error has already been reported).
Adjust various tests.
For #54511.
Change-Id: Ib2d25f8eab7d5745275188d83d11620cad6ef47c
Reviewed-on: https://go-review.googlesource.com/c/go/+/425675
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Since when go/types,types2 do not know about build constraints, and
runtime/cgo.Incomplete is only available on platforms that support cgo.
These tests are also failing on aix with failure from linker, so disable
them on aix to make builder green. The fix for aix is tracked in #54814
Updates #46731
Updates #54814
Change-Id: I5d6f6e29a8196efc6c457ea64525350fc6b20309
Reviewed-on: https://go-review.googlesource.com/c/go/+/427394
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Same as CL 421880, but for test directory.
Updates #46731
Change-Id: If8d18df013a6833adcbd40acc1a721bbc23ca6b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/421881
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Shape-based stenciling in unified IR is done by converting type argument
to its underlying type. So it agressively check that type argument is
not a TFORW. However, for recursive instantiated type argument, it may
still be a TFORW when shapifying happens. Thus the assertion failed,
causing the compiler crashing.
To fix it, just allow fully instantiated type when shapifying.
Fixes#54512Fixes#54722
Change-Id: I527e3fd696388c8a37454e738f0324f0c2ec16cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/426335
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In typebits.Set we check that the offset is a multiple of the
alignment, which makes perfect sense. But for values like
atomic.Int64, which has 8-byte alignment even on 32-bit platforms
(i.e. the alignment is larger than PtrSize), if it is on stack it
may be under-aligned, as the stack frame is only PtrSize aligned.
Normally we would prevent such values on stack, as the escape
analysis force values with higher alignment to heap. But for a
composite literal assignment like x = AlignedType{...}, the
compiler creates an autotmp for the RHS then copies it to the LHS.
The autotmp is on stack and may be under-aligned. Currently this
may cause an ICE in the typebits.Set check.
This CL makes it align the _offset_ of the autotmp to 8 bytes,
which satisfies the check. Note that this is actually lying: the
actual address at run time may not necessarily be 8-byte
aligned as we only align SP to 4 bytes.
The under-alignment is probably okay. The only purpose for the
autotmp is to copy the value to the LHS, and the copying code we
generate (at least currently) doesn't care the alignment beyond
stack alignment.
Fixes#54638.
Change-Id: I13c16afde2eea017479ff11dfc24092bcb8aba6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425256
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL changes the inliner to process transitive inlining iteratively
after the AST has actually been edited, rather than recursively and
immediately. This is important for handling indirect function calls
correctly, because ir.reassigned walks the function body looking for
reassignments; whereas previously the inlined reassignments might not
have been actually added to the AST yet.
Fixes#54632.
Change-Id: I0dd69813c8a70b965174e0072335bc00afedf286
Reviewed-on: https://go-review.googlesource.com/c/go/+/425257
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Normally, when moving Go values of type T from one location to another,
we don't need to worry about partial overlaps. The two Ts must either be
in disjoint (nonoverlapping) memory or in exactly the same location.
There are 2 cases where this isn't true:
1) Using unsafe you can arrange partial overlaps.
2) Since Go 1.17, you can use a cast from a slice to a ptr-to-array.
https://go.dev/ref/spec#Conversions_from_slice_to_array_pointer
This feature can be used to construct partial overlaps of array types.
var a [3]int
p := (*[2]int)(a[:])
q := (*[2]int)(a[1:])
*p = *q
We don't care about solving 1. Or at least, we haven't historically
and no one has complained.
For 2, we need to ensure that if there might be partial overlap,
then we can't use OpMove; we must use memmove instead.
(memmove handles partial overlap by copying in the correct
direction. OpMove does not.)
Note that we have to be careful here not to introduce a call when
we're marshaling arguments to a call or unmarshaling results from a call.
Fixes#54467
Change-Id: I1ca6aba8041576849c1d85f1fa33ae61b80a373d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425076
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
For #23870
Change-Id: I3bbe0f751254d1354a59a88b45e6f944c7a2fb4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/417874
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 414836 limited the check for implicit dot for method call enabled by
a type bound. However, the checking condition for ODOTMETH only is not
right. For example, for promoted method, we have a OXDOT node instead,
and we still have to check for implicit dot in this case.
However, if the base type and embedded types have the same method name,
e.g in issue #53419, typecheck.AddImplicitDots will be confused and
result in an ambigus selector.
To fix this, we ensure methods for the base type are computed, then only
do the implicit dot check if we can find a matched method.
Fixes#54348
Change-Id: Iefe84ff330830afe35c5daffd499824db108da23
Reviewed-on: https://go-review.googlesource.com/c/go/+/422274
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The issue is expected to be fixed when Unified IR is enabled by default,
so adding a test to make sure thing works correctly.
Updates #53702
Change-Id: Id9d7d7ca4506103df0d10785ed5ee170d69988ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/423434
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
I structured the test for issue54343.go after issue46725.go, where I
was careful to use `[4]int`, which is a type large enough to avoid the
tiny object allocator (which interferes with finalizer semantics). But
in that test, I didn't note the importance of that type, so I
mistakenly used just `int` in issue54343.go.
This CL switches issue54343.go to use `[4]int` too, and then adds
comments to both pointing out the significance of this type.
Updates #54343.
Change-Id: I699b3e64b844ff6d8438bbcb4d1935615a6d8cc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/423115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
With GOEXPERIMENT=unified, the order variables are printed in "live at
entry to f.func1" is sensitive to whether regabi is enabled for some
reason. The order shouldn't matter to correctness, but it is odd.
For now, this CL just relaxes the test expectation order to unblock
enabling GOEXPERIMENT=unified by default. I've filed #54402 to
investigate further to confirm this a concern.
Updates #54402.
Change-Id: Iddfbb12c6cf7cc17b2aec8102b33761abd5f93ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/422975
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For selector expression "x.M" where "M" is a promoted method, irgen is using
the type of receiver "x" for determining the typeparams for instantiation.
However, because M is a promoted method, so its associated receiver is
not "x", but "x.T" where "T" is the embedded field of "x". That casues a
mismatch when converting non-shape types arguments.
Fixing it by using the actual receiver which has the method, instead of
using the base receiver.
Fixes#53982
Change-Id: I1836fc422d734df14e9e6664d4bd014503960bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/419294
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The Go 1.18 frontend handles package-scope generic method values by
spilling the receiver value to a global temporary variable, which pins
it into memory. This issue isn't present in unified IR, which uses
OMETHVALUE when the receiver type is statically known.
Updates #54343.
Change-Id: I2c4ffeb125a3cf338f949a93b0baac75fff6cd31
Reviewed-on: https://go-review.googlesource.com/c/go/+/422198
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
As it can't appear in user package paths.
There is a hack for handling "go:buildid" and "type:*" on windows/386.
Previously, windows/386 requires underscore prefix on external symbols,
but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols.
"go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed
with underscore.
In external linking mode, the external linker can't resolve them as
external symbols. But we are lucky that they have "." in their name,
so the external linker see them as Forwarder RVA exports. See:
- https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table
- https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972)
This CL changes "." to ":" in symbols name, so theses symbols can not be
found by external linker anymore. So a hacky way is adding the
underscore prefix for these 2 symbols. I don't have enough knowledge to
verify whether adding the underscore for all STEXT/STYPE symbols are
fine, even if it could be, that would be done in future CL.
Fixes#37762
Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/317917
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There's no need for a and b to match types. The typechecker already
ensured that a and b are both slices with the same base type, or
a and b are (possibly named) []byte and string.
The optimization to treat append(b, make([], ...)) as a zeroing
slice extension doesn't fire when there's a OCONVNOP wrapping the make.
Fixes#53888
Change-Id: Ied871ed0bbb8e4a4b35d280c71acbab8103691bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/418475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Same as CL 417555, but for cmd/compile.
Fixes#54220
Change-Id: I4cc6deaf0a87c952f636888b4ab73f81a44bfebd
Reviewed-on: https://go-review.googlesource.com/c/go/+/420975
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Merge List:
+ 2022-07-27 462b78fe70 misc/cgo/test: use fewer threads in TestSetgidStress in long mode
+ 2022-07-27 055113ef36 math/big: check buffer lengths in GobDecode
+ 2022-07-27 4248146154 net: document UDPConn.ReadFromUDPAddrPort's AddrPort result more
+ 2022-07-26 faf4e97200 net: fix WriteMsgUDPAddrPort addr handling
+ 2022-07-26 caa225dd29 doc/go1.19: note that updated race syso files require GNU ld 2.26
+ 2022-07-26 ceefd3a37b bytes: document that Reader.Reset affects the result of Size
+ 2022-07-26 3e97294663 runtime/cgo: use frame address to set g0 stack bound
+ 2022-07-25 24dc27a3c0 cmd/compile: fix blank label code
+ 2022-07-25 9fcc8b2c1e runtime: fix runtime.Breakpoint() on windows/arm64
+ 2022-07-25 795a88d0c3 cmd/go: add space after comma in 'go help test'
+ 2022-07-25 9eb3992ddd doc/go1.19: minor fixes
+ 2022-07-25 dcea1ee6e3 time: clarify documentation for allowed formats and add tests to prove them
+ 2022-07-25 37c8112b82 internal/fuzz: fix typo in function comments
+ 2022-07-25 850d547d2d doc/go1.19: expand crypto release notes
+ 2022-07-24 64f2829c9c runtime: fix typo in function comments
+ 2022-07-24 2ff563a00e cmd/compile/internal/noder: correct spelling errors for instantiation
+ 2022-07-22 c5da4fb7ac cmd/compile: make jump table symbol local
+ 2022-07-22 774fa58d1d A+C: delete AUTHORS and CONTRIBUTORS
+ 2022-07-21 2d655fb15a unsafe: document when Sizeof/Offsetof/Alignof are not constant
+ 2022-07-21 076c3d7f07 net/http: remove accidental heading in Head documentation
+ 2022-07-21 c4a6d3048b cmd/dist: enable race detector test on S390X
+ 2022-07-20 244c8b0500 cmd/cgo: allow cgo to pass strings or []bytes bigger than 1<<30
+ 2022-07-20 df38614bd7 test: use go tool from tree, not path
+ 2022-07-20 bb1749ba3b cmd/compile: improve GOAMD64=v1 violation test
+ 2022-07-19 176b63e711 crypto/internal/nistec,debug/gosym: fix typos
Change-Id: I96e5d60039381691dffd841e58927f0afff8c544
When checkEnabled is forced true, the 52278 test fails. Be a bit
more careful about processing blank labels.
Update #52278
Change-Id: I48aa89e2c9e3715d8efe599bc4363b5b5879d8a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/419318
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
In this test, traditionally the comparison `*l == r[0]` was left as a
comparison between `*l` (type `any`) and `r[0]` (type `*int`), and the
rest of the compiler needed to handle mixed-typed comparisons.
However, this means more complexity for wiring up explicit rtypes.
To simplify rtype handling, the next CL will change unified IR to
instead handle the expression as `*l == any(r[0])`. However, a
consequence of this currently is that walk will now sequence the
`any(r[0])` expression first, because it involves a
concrete-to-interface conversion. And in turn, this means the `r[0]`
panic ("index out of bounds") will take priority over the `*l`
panic ("nil pointer dereference").
This is a change in user-visible semantics in some cases, but the Go
spec leaves this unspecified, so it shouldn't be an issue. Note also:
gccgo has the same behavior (i.e., panicking on index out of bounds,
not nil pointer dereference), and cmd/compile also already has the
same behavior when the interface conversion is explicit (as in the
added "nil pointer dereference #3" test case).
Updates #23735.
Updates #32187.
Change-Id: I49e5dcca85b4680f9c8780ef0013e64254d38fe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/418097
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
