Part 1: CL 199499 (GOOS nacl)
Part 2: CL 200077 (amd64p32 files, toolchain)
Part 3: stuff that arguably should've been part of Part 2, but I forgot
one of my grep patterns when splitting the original CL up into
two parts.
This one might also have interesting stuff to resurrect for any future
x32 ABI support.
Updates #30439
Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/200318
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The package references recorded in the object file, which are
obtained from the compiler, are escaped. We should also use the
escaped package paths in the linker for resolving package
references.
Change-Id: I42eb12df6ff24330e6dc7bed1dc8224bb3b8a106
Reviewed-on: https://go-review.googlesource.com/c/go/+/200158
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This is the behavior of the old code. Do the same.
Change-Id: I3d393d754dcbdb7e76a577252a94214d2e316651
Reviewed-on: https://go-review.googlesource.com/c/go/+/200159
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When the compiler's -S flag is specified, it dumps the
disassembly. Add this when writing the new style object file.
Change-Id: I4cf85e57d22d0ceea1fda6d3b59fe363573659e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/200100
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Switch the deadcode pass to use indices instead of Symbol
structures when using new object file format. Delay loading
symbol relocations and contents fully after the deadcode pass.
The next step is not to create Symbol structures until deadcode
is done.
Method tracking logic hasn't been implemented. Currently, all
methods of a reachable type are live.
Change-Id: Iffcd06ff84e6e52bd9eb24d1220d94234d18ab6b
Reviewed-on: https://go-review.googlesource.com/c/go/+/198199
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
First change of several to update the loader API to reflect the final
consensus version of the loader API as described in Cherry's doc.
This piece:
- define new loader.Sym type to encapsulate a global symbol
index (as opposed to just using 'int')
Change-Id: I6f6483e269f80abfc7d373b2856b2c0d61b9ac24
Reviewed-on: https://go-review.googlesource.com/c/go/+/200417
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Also, in cmd/doc, avoid calling 'go list -m all' when in module mode
outside a module since it's now an error.
Fixes#32027
Change-Id: I7224c7fdf7e950bce6c058ab2a5837c27ba3b899
Reviewed-on: https://go-review.googlesource.com/c/go/+/200297
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When unmarshaling to a map, the map's key type must either be a string,
an integer, or implement encoding.TextUnmarshaler. But for a user
defined type, reflect.Kind will not distinguish between the static type
and the underlying type. In:
var x MyString = "x"
t := reflect.TypeOf(x)
println(t.Kind() == reflect.String)
the Kind of x is still reflect.String, even though the static type of x
is MyString.
Moreover, checking for the map's key type is a string occurs first, so
even if the map key type MyString implements encoding.TextUnmarshaler,
it will be ignored.
To fix the bug, check for encoding.TextUnmarshaler first.
Fixes#34437
Change-Id: I780e0b084575e1dddfbb433fe03857adf71d05fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/200237
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Compact has been inconsistently escaping only some problematic characters
(U+2028 and U+2029), but not others (<, > and &). This change addresses
this inconsistency by removing the escaping of U+2028 and U+2029.
Callers who need to escape the output of Compact should use HTMLEscape
which escapes <, >, &, U+2028 and U+2029.
Fixes#34070Fixes#30357
Updates #5836
Change-Id: Icfce7691d2b8b1d9b05ba7b64d2d1e4f3b67871b
GitHub-Last-Rev: 38859fe3e2
GitHub-Pull-Request: golang/go#34804
Reviewed-on: https://go-review.googlesource.com/c/go/+/200217
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When in module mode outside of any module, 'go build' and most other
commands will now report an error instead of resolving a package path
to a module.
Previously, most commands would attempt to find the latest version of
a module providing the package. This could be very slow if many
packages needed to be resolved this way. Since there is no go.mod file
where module requirements can be saved, it's a repeatedly slow and
confusing experience.
After this change, 'go build' and other commands may still be used
outside of a module on packages in std and source files (.go
arguments) that only import packages in std. Listing any other package
on the command line or importing a package outside std will cause an
error.
'go get' is exempted from the new behavior, since it's expected that
'go get' resolves paths to modules at new versions.
Updates #32027
Change-Id: Ia9d3a3b4ad738ca5423472e17818d62b96a2c959
Reviewed-on: https://go-review.googlesource.com/c/go/+/198778
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
go/build.Import locates package dirctories using 'go list' when in
module mode (finding, downloading, and extracting modules is
complicated, so go/build does not handle it).
Previously, Import used 'go list' if GO111MODULE was not explicitly
off and a go.mod file was present (plus some other conditions). With
this change, if GO111MODULE is "on", a go.mod file does not need to be
present.
Fixes#34669
Change-Id: I9e56871054d4b07c3fc04b6f14a5c8c8e9f3c333
Reviewed-on: https://go-review.googlesource.com/c/go/+/199818
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This is part two if the nacl removal. Part 1 was CL 199499.
This CL removes amd64p32 support, which might be useful in the future
if we implement the x32 ABI. It also removes the nacl bits in the
toolchain, and some remaining nacl bits.
Updates #30439
Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200077
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some code tags in the HTML were not properly closed. Close them so that
the text is rendered correctly.
Change-Id: I5c2170ffced313417f65004d53518128c34f7979
Reviewed-on: https://go-review.googlesource.com/c/go/+/200117
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change some decodetype functions to operate on bytes nstead of
Symbol. This is in preparation of implementing live method
tracking in index-based deadcode pass, and reducing/eliminating
sym.Symbol in general.
Change-Id: Ia9809ad7b182884225e1bda577e8dbec0cd216c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/199077
Reviewed-by: Austin Clements <austin@google.com>
The dev.link branch was not sync'd with the new DWARF compilation
unit logic change on the master branch, and the new object file
format didn't support this.
This CL adds the new DWARF CU and file table support to the new
object file format. In the old object file, the DWARF file table
is a separate section. For now, we do the same with the new
object file, keeping it as a separate block.
While here, also refactor the loader code so it is easier for the
loader to carry per-object informations.
Change-Id: I4c317941fc0a5831acbc11ce8c2a8b7421471372
Reviewed-on: https://go-review.googlesource.com/c/go/+/198198
Reviewed-by: Austin Clements <austin@google.com>
With the old object file format, we use mmap (if supported) to
read object files and back symbol data with mapped read-only
memory.
Do the same with the new object file format. This also
significantly reduces number of syscalls made to read object
files.
Currently we still do mmap in object file level, not archive
level. This is probably ok, as there shouldn't be many archives
that contain more than one object. If this is a problem we can
change that later.
Change-Id: Icae3ef14d8ed6adbee1b5b48d420e2af22fd9604
Reviewed-on: https://go-review.googlesource.com/c/go/+/197797
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This change introduces a new interface, load.ImportPathError. An error
may satisfy this by providing an ImportPath method and including the
import path in its error text. modload.ImportMissingError satisfies
this interface. load.ImportErrorf also provides a convenient way to
create an error satisfying this interface with an arbitrary message.
When load.PackageError formats its error text, it may omit the last
path on the import stack if the wrapped error satisfies
ImportPathError and has a matching path.
To make this work, PackageError.Err is now an error instead of a
string. PackageError.MarshalJSON will write Err as a string for
'go list -json' output.
When go/build.Import invokes 'go list' in module mode, it now runs
with '-e' and includes '.Error' in the output format instead of
expecting the error to be in the raw stderr text. If a package error
is printed and a directory was not found, the error will be returned
without extra decoration.
Fixes#34752
Change-Id: I2d81dab7dec19e0ae9f51f6412bc9f30433a8596
Reviewed-on: https://go-review.googlesource.com/c/go/+/199840
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This reverts CL 184457.
Reason for revert: introduced failures in the regression test for #18153.
Fixes#34791
Updates #29062
Change-Id: I4040965163f809083c023be055e69b1149d6214e
Reviewed-on: https://go-review.googlesource.com/c/go/+/200106
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When rewriting a go.mod file, we currently sort all of the require
lines in a block. The way the parser works is that it considers
preceding blank lines to be empty comment lines, and preceding empty
comment lines are "owned" by their adjoining line. So when we go to sort
them, the empty lines follow around each sorted entry, which doesn't
make a whole lot of sense, since usually vertical space is inserted to
show sections, and if things get moved around by sorting, those sections
are no longer meaningful. This all results in one especially troublesome
edge case: blank lines between a block opening ("require (") and the
first block line ("golang.org/x/sys ...") are not treated the same way
and are rewritten out of existence.
Here's an example of the behavior this fixes.
Starting input file:
require (
golang.zx2c4.com/wireguard master
golang.org/x/crypto latest
golang.org/x/net latest
golang.org/x/sys latest
golang.org/x/text latest
github.com/lxn/walk latest
github.com/lxn/win latest
)
Now we run this through `GOPROXY=direct go get -d`:
require (
github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a
github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48
golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586
golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7
golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a
golang.org/x/text v0.3.2
golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49
)
Notice how the blank lines before lxn/walk and x/crypto were preserved.
Finally, we have this be rewritten yet again with a call to `go build`:
require (
github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a
github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48
golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586
golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7
golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a
golang.org/x/text v0.3.2
golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49
)
In this final resting point, the first blank line has been removed.
The discrepancy between those two last stages are especially bothersome,
because it makes for lots of dirty git commits and file contents
bouncing back and forth.
This commit fixes the problem as mentioned above, getting rid of those
preceding blank lines. The output in all cases looks as it should, like
this:
require (
github.com/lxn/walk v0.0.0-20190619151032-86d8802c197a
github.com/lxn/win v0.0.0-20190716185335-d1d36f0e4f48
golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586
golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7
golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a
golang.org/x/text v0.3.2
golang.zx2c4.com/wireguard v0.0.20190806-0.20190822065259-3cedc22d7b49
)
Fixes#33779
Change-Id: I11c894440bd35f343ee62db3e06a50fa871f2599
Reviewed-on: https://go-review.googlesource.com/c/go/+/199917
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This functionality already exists but was undocumented. Related to
comments in CL 198797.
Change-Id: Icce40bd7c362423e6ed9c20673ce3de1311e5fd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/200040
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Test case with code that caused a gccgo error while emitting export
data for an inlinable function.
Updates #34577.
Change-Id: I28b598c4c893c77f4a76bb4f2d27e5b42f702992
Reviewed-on: https://go-review.googlesource.com/c/go/+/198057
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If the new object file format is used, now we load full symbol
contents after the deadcode pass, for reachable symbols only.
We still load some informations early, like relocations and the
contents of type symbols, which are used in the deadcode pass.
If we rewrite deadcode to use index directly, we could delay more
of the loading (to sym.Symbol), and perhaps delay the creation of
sym.Symbol.
TODO: internal linking with host objects doesn't work yet.
Change-Id: I7d4880e8f150e8709ffac277e62191623440e4cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/197258
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
For example, if a test calls os.Exit(0), that could trick a 'go test'
run into not running some of the other tests, and thinking that they all
succeeded. This can easily go unnoticed and cause developers headaches.
Add a simple sanity check as part of 'go test': if the test binary
succeeds and doesn't print anything, we should error, as something
clearly went very wrong.
This is done by inspecting each of the stdout writes from the spawned
process, since we don't want to read the entirety of the output into a
buffer. We need to introduce a "buffered" bool var, as there's now an
io.Writer layer between cmd.Stdout and &buf.
A few TestMain funcs in the standard library needed fixing, as they
returned without printing anything as a means to skip testing the entire
package. For that purpose add testenv.MainMust, which prints a warning
and prints SKIP, similar to when -run matches no tests.
Finally, add tests for both os.Exit(0) and os.Exit(1), both as part of
TestMain and as part of a single test, and test that the various stdout
modes still do the right thing.
Fixes#29062.
Change-Id: Ic6f8ef3387dfc64e4cd3e8f903d7ca5f5f38d397
Reviewed-on: https://go-review.googlesource.com/c/go/+/184457
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The branch-on-count instructions on s390x decrement the input
register and then compare its value to 0. If not equal the branch
is taken.
These instructions are useful for implementing loops with a set
number of iterations (which might be in a register).
For example, this for loop:
for i := 0; i < n; i++ {
... // i is not used or modified in the loop
}
Could be implemented using this assembly:
MOVD Rn, Ri
loop:
...
BRCTG Ri, loop
Note that i will count down from n in the assembly whereas in the
original for loop it counted up to n which is why we can't use i
in the loop.
These instructions will only be used in hand-written codegen and
assembly for now since SSA blocks cannot currently modify values.
We could look into this in the future though.
Change-Id: Iaab93b8aa2699513b825439b8ea20d8fe2ea1ee6
Reviewed-on: https://go-review.googlesource.com/c/go/+/199977
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The element size for VSUMQF and VSUMQG was off by one. Fix this
and add tests for VSUM* instruction encodings.
Change-Id: I6de2dabb383e5bc6f85eef1e0f106ba949c9030b
Reviewed-on: https://go-review.googlesource.com/c/go/+/199978
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In CL 197059, I suppressed errors if the target package was already found.
However, that does not cover the case of passing a '/v2' module path to
'go get' when the module does not contain a package at its root.
This CL is a minimal fix for that case, intended to be backportable to 1.13.
(Longer term, I intend to rework the version-validation check to treat
all mismatched paths as ErrNotExist.)
Fixes#34746
Updates #34383
Change-Id: Ia963c2ea00fae424812b8f46a4d6c2c668252147
Reviewed-on: https://go-review.googlesource.com/c/go/+/199839
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
You were a useful port and you've served your purpose.
Thanks for all the play.
A subsequent CL will remove amd64p32 (including assembly files and
toolchain bits) and remaining bits. The amd64p32 removal will be
separated into its own CL in case we want to support the Linux x32 ABI
in the future and want our old amd64p32 support as a starting point.
Updates #30439
Change-Id: Ia3a0c7d49804adc87bf52a4dea7e3d3007f2b1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/199499
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
n.Noescape() was overloaded for two uses: (1) to indicate a function
was annotated with //go:noescape, and (2) to indicate that certain
temporary allocations don't outlive the current statement.
The first use case is redundant with n.Func.Pragma&Noescape!=0, which
is the convention we use for checking other function-level pragmas.
The second use case is better served by renaming "Noescape" to
"Transient".
Passes toolstash-check.
Change-Id: I0f09d2d5767513894b7bf49da9cdabd04aa4a05e
Reviewed-on: https://go-review.googlesource.com/c/go/+/199822
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The newly introduced "late-stage" cycle detection for types
(https://golang.org/cl/196338/) "skips" named types on the
RHS of a type declaration when reporting a cycle. For instance,
for:
type (
A B
B [10]C
C A
)
the reported cycle is:
illegal cycle in declaration of C
C refers to
C
because the underlying type of C resolves to [10]C (note that
cmd/compile does the same but simply says invalid recursive
type C).
This CL introduces the Named.orig field which always refers
to the RHS type in a type definition (and is never changed).
By using Named.orig rather than Named.underlying for the type
validity check, the cycle as written in the source code is
reported:
illegal cycle in declaration of A
A refers to
B refers to
C refers to
A
Fixes#34771.
Change-Id: I41e260ceb3f9a15da87ffae6a3921bd8280e2ac4
Reviewed-on: https://go-review.googlesource.com/c/go/+/199937
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently we add all text symbols to ctxt.Textp at load time,
then the deadcode pass filters out unreachable ones. This CL
delays adding symbols to ctxt.Textp to the end of the deadcode
pass, where we only add reachable ones.
Change-Id: Ie83b2958f915c5aaa004b8c5ed1f1bc275f4d1db
Reviewed-on: https://go-review.googlesource.com/c/go/+/197257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Follow-up of Than's comment on CL 196032. For runtime.gcbits
symbols, the compiler already sets the "local" attribute
(cmd/compile/internal/gc/reflect.go:dgcptrmask). No need of the
special handling in the linker.
Change-Id: I7c53a818ed0375083f04655f3565c1c9c45f2401
Reviewed-on: https://go-review.googlesource.com/c/go/+/199642
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Avoid confusion between (now gone) objSet and objset types.
Also: rename visited -> seen in initorder.go.
No functional changes.
Change-Id: Ib0aa25e006eee55a79a739194d0d26190354a9f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/198044
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- remove Checker.cycle in favor of using a "seen" map
- rename Checker.typeCycle -> Checker.cycle
- remove TODO in api.go since the API is frozen
Change-Id: I182a8215978dad54e9c6e79c21c5ec88ec802349
Reviewed-on: https://go-review.googlesource.com/c/go/+/198042
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For Go 1.13, we rewrote the go/types cycle detection scheme. Unfortunately,
it was a bit too clever and introduced a bug (#34333). Here's an example:
type A struct {
f1 *B
f2 B
}
type B A
When type-checking this code, the first cycle A->*B->B->A (via field f1)
is ok because there's a pointer indirection. Though in the process B is
considered "type-checked" (and painted/marked from "grey" to black").
When type-checking f2, since B is already completely set up, go/types
doesn't complain about the invalid cycle A->B->A (via field f2) anymore.
On the other hand, with the fields f1, f2 swapped:
type A struct {
f2 B
f1 *B
}
go/types reports an error because the cycle A->B->A is type-checked first.
In general, we cannot know the "right" order in which types need to be
type-checked.
This CL fixes the issue as follows:
1) The global object path cycle detection does not take (pointer, function,
reference type) indirections into account anymore for cycle detection.
That mechanism was incorrect to start with and the primary cause for this
issue. As a consequence we don't need Checker.indirectType and indir anymore.
2) After processing type declarations, Checker.validType is called to
verify that a type doesn't expand indefinitively. This corresponds
essentially to cmd/compile's dowidth computation (without size computation).
3) Cycles involving only defined types (e.g.: type (A B; B C; C A))
require separate attention as those must now be detected when resolving
"forward chains" of type declarations. Checker.underlying was changed
to detect these cycles.
All three cycle detection mechanism use an object path ([]Object) to
report cycles. The cycle error reporting mechanism is now factored out
into Checker.cycleError and used by all three mechanisms. It also makes
an attempt to report the cycle starting with the "first" (earliest in the
source) object.
Fixes#34333.
Change-Id: I2c6446445e47344cc2cd034d3c74b1c345b8c1e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/196338
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL adds system register error checking test cases. There're two kinds of
error test cases:
1. illegal combination.
MRS should be used in this way: MRS <system register>, <general register>.
MSR should be used in this way: MSR <general register>, <system register>.
Error usage examples:
MRS R8, VTCR_EL2 // ERROR "illegal combination"
MSR VTCR_EL2, R8 // ERROR "illegal combination"
2. illegal read or write access.
Error usage examples:
MSR R7, MIDR_EL1 // ERROR "expected writable system register or pstate"
MRS OSLAR_EL1, R3 // ERROR "expected readable system register"
This CL reads system registers readable and writeable property to check whether
they're used with legal read or write access. This property is named AccessFlags
in sysRegEnc.go, and it is automatically generated by modifing the system register
generator.
Change-Id: Ic83d5f372de38d1ecd0df1ca56b354ee157f16b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/194917
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
