R=go1.11
This is a follow up for #11377 which reported that an error like
/tmp/xx.go:9:6: expected '(', found 'IDENT' F1
shouldn't print 'IDENT', as it's just an internal detail.
The relevant change wasn't made in the original fix, so here it is.
For #11377.
Change-Id: Ib76957d86b88e3e63646fbe4abf03a3b9d045139
Reviewed-on: https://go-review.googlesource.com/87900
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
R=go1.11
No semantic change.
For #23434.
Change-Id: Iafdb062b0ebe6cd6e51f9a98b62b1d10f1bacc5c
Reviewed-on: https://go-review.googlesource.com/87899
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
R=go1.11
This CL also introduces a new TODO in parser.go. To be
addressed in a separate CL to make this easier to review.
Also: Make parser's test harness easier to use by ignoring
auto-inserted (invisible) semicolons when computing error
positions. Adjusted testdata/commas.src accordingly.
Fixes#23434.
Change-Id: I050592d11d5f984f71185548394c000eea509205
Reviewed-on: https://go-review.googlesource.com/87898
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For consistent formatting across platforms we strip \r's from
comments. This happens in the go/scanner which already does
this for raw string literals where it is mandated by the spec.
But if a (sequence of) \r appears in a regular (/*-style) comment
between a * and a /, removing that (sequence of) \r shortens that
text segment to */ which terminates the comment prematurely.
Don't do it.
As an aside, a better approach would be to not touch comments,
(and raw string literals for that matter) in the scanner and
leave the extra processing to clients. That is the approach
taken by the cmd/compile/internal/syntax package. However, we
probably can't change the semantics here too much, so just do
the minimal change that doesn't produce invalid comments. It's
an esoteric case after all.
Fixes#11151.
Change-Id: Ib4dcb52094f13c235e840c9672e439ea65fef961
Reviewed-on: https://go-review.googlesource.com/87498
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
R=go1.11
To fix this, this CL borrows code from the new syntax
package which has a better tuned parser at this point.
Fixes#11377.
Change-Id: Ib9212c945903d6f62abcc59ef5a5767d4ef36981
Reviewed-on: https://go-review.googlesource.com/87495
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ioutil.ReadAll didn't exist when we wrote that parser code
originally (in 2009). Now it does, so use it. This may also
make that code path slightly more efficient.
Also, now that we are guaranteed to have a fast path for reading
from an io.Reader (and thus an io.ReadCloser), simplify setup
code for parser.ParseFile calls in srcimporter.Importer.ParseFiles.
Remove the associated TODO since we cannot reproduce any significant
performance differences when running go test -run ImportStdLib for
the case where we used to read directly from a file (even before the
change to the parser).
Fixes#19281.
Change-Id: I816459d092bb9e27fdc85089b8f21d57ec3fd79a
Reviewed-on: https://go-review.googlesource.com/85395
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
Once approved, this change must be ported to golang.org/x/tools/go/gcimporter15.
Fixes#13829.
Change-Id: I26a0094d2bfd38b97f2b64bae84b9f428fc9cdf1
Reviewed-on: https://go-review.googlesource.com/85318
Reviewed-by: Alan Donovan <adonovan@google.com>
CL 137410043 deleted support for split stacks, which means morestack
no longer needed to save its caller's frame or argument size or its
caller's argument pointer. However, this commit failed to update the
comment or delete the line that computed the caller's argument
pointer. Clean these up now.
Change-Id: I65725d3d42c86e8adb6645d5aa80c305d473363d
Reviewed-on: https://go-review.googlesource.com/92437
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This replaces frame size -4/-8 with the NOFRAME flag in mips and
mips64 assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-[84]/\1|NOFRAME,\2$0/' $(find -name '*_mips*.s')
Plus a manual fix to mkduff.go.
The go binary is identical on both architectures before and after this
change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227efb
Reviewed-on: https://go-review.googlesource.com/92044
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This replaces frame size -8 with the NOFRAME flag in arm64 assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-8/\1|NOFRAME,\2$0/' $(find -name '*_arm64.s')
Plus a manual fix to mkduff.go.
The go binary is identical before and after this change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227efa
Reviewed-on: https://go-review.googlesource.com/92043
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This replaces frame size -4 with the NOFRAME flag in arm assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-4/\1|NOFRAME,\2$0/' $(find -name '*_arm.s')
Plus three manual comment changes found by:
grep '\$-4' $(find -name '*_arm.s')
The go binary is identical before and after this change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227ef9
Reviewed-on: https://go-review.googlesource.com/92042
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This passes toolstash -cmp with one exception: assembly functions that
were declared with a frame size of -4 (or -8) used to record
locals=0xfffffffffffffffc in the object file and now record
locals=0x0. This doesn't affect anything.
Change-Id: I0d15e81770e54222ae329ce4496da06016736771
Reviewed-on: https://go-review.googlesource.com/92041
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In addition, this makes the arm64 prologue code generation much closer
to the pattern used on other platforms.
This passes toolstash -cmp with one exception: assembly functions that
were declared with a frame size of -8 used to record
locals=0xfffffffffffffff8 in the object file and now record
locals=0x0. This doesn't affect anything.
Change-Id: I0d15e81770e54222ae329ce4496da06016736770
Reviewed-on: https://go-review.googlesource.com/92040
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This adds support on arm for the NOFRAME symbol attribute used by
ppc64 and s390x in preference to using a frame size of -4. This is
modeled on ppc64's implementation of NOFRAME.
This passes toolstash -cmp.
Change-Id: I0d15e81770e54222ae329ce4496da0601673677f
Reviewed-on: https://go-review.googlesource.com/92039
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"-8" is not a sensible frame size on arm and we're about to start
rejecting it. Replace it with -4.
Likewise, "-4" is not a sensible frame size on arm64 and we're about
to start rejecting it. Replace it with -8.
Finally, clean up some places we're weirdly inconsistent about using 0
versus -8.
Change-Id: If85e229993d5f7f1f0cfa9852b4e294d053bd784
Reviewed-on: https://go-review.googlesource.com/92038
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For leaf functions with zero-sized frames, there's no point in doing a
stack check, so omit it.
This aligns arm64 with other architectures.
Change-Id: I1fb483d62f1736af10c5110815d3f5a875a46d7f
Reviewed-on: https://go-review.googlesource.com/92037
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The NoFramePointer function flag is no longer used, so this CL
eliminates it. This cleans up some confusion between the compiler's
NoFramePointer flag and obj's NOFRAME flag. NoFramePointer was
intended to eliminate the saved base pointer on x86, but it was
translated into obj's NOFRAME flag. On x86, NOFRAME does mean to omit
the saved base pointer, but on ppc64 and s390x it has a more general
meaning of omitting *everything* from the frame, including the saved
LR and ppc64's "fixed frame". Hence, on ppc64 and s390x there are far
fewer situations where it is safe to set this flag.
Change-Id: If68991310b4d00638128c296bdd57f4ed731b46d
Reviewed-on: https://go-review.googlesource.com/92036
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, tail calls on x86 don't adjust the SP on return, so it's
important that the compiler produce a zero-sized frame and disable the
frame pointer. However, these constraints aren't necessary. For
example, on other architectures it's generally necessary to restore
the saved LR before a tail call, so obj simply makes this work.
Likewise, on x86, there's no reason we can't simply make this work.
Hence, this CL adjusts the compiler to use the same tail call
convention for x86 that we use on LR machines by producing a RET with
a target, rather than a JMP with a target. In fact, obj already
understands this convention for x86 except that it's buggy with
non-zero frame sizes. So we also fix this bug obj. As a result of
these fixes, the compiler no longer needs to mark wrappers as
NoFramePointer since it's now perfectly fine to save the frame
pointer.
In fact, this eliminates the only use of NoFramePointer in the
compiler, which will enable further cleanups.
This also fixes what is very nearly, but not quite, a code generation
bug. NoFramePointer becomes obj.NOFRAME in the object file, which on
ppc64 and s390x means to omit the saved LR. Hence, on these
architectures, NoFramePointer (and NOFRAME) is only safe to set on
leaf functions. However, on *most* architectures, wrappers aren't
necessarily leaf functions because they may call DUFFZERO. We're saved
on ppc64 and s390x only because the compiler doesn't have the rules to
produce DUFFZERO calls on these architectures. Hence, this only works
because the set of LR architectures that implement NOFRAME is disjoint
from the set where the compiler produces DUFFZERO operations. (I
discovered this whole mess when I attempted to add NOFRAME support to
arm.)
Change-Id: Icc589aeb86beacb850d0a6a80bd3024974a33947
Reviewed-on: https://go-review.googlesource.com/92035
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL converts the last call to scope.LookupParent with no position
information to a check.lookup call that respects position information
provided by Eval (there's one more LookupParent call that cannot be
converted, see the respective comment in the code).
In this case, the lookup is needed to determine the variable on the
LHS of an assignment, for adjustment of its `used` information.
Outside a types.Eval call, i.e., during normal type-checking, there
is no difference between this new code and the old code.
While in a types.Eval call, it's important to use the correct position
to look up the relevant variable. If token.NoPos were used, one might
find another variable with the same name, declared later in the scope.
Caveat: Types.Eval only accepts expressions, and it's currently not
possible to evaluate assignments (except via function literals, but
then the scope is different). That is, this change is a fix for a
potential future bug, and for now a no-op.
Change-Id: I28db1fe1202c07e3f7b3fadfd185728afb9b2ae7
Reviewed-on: https://go-review.googlesource.com/85199
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
The terminating statement check for functions that declare result
parameters was using the wrong scope to look up calls to `panic`
which in esoteric cases lead to a false positive.
Instead of looking up a panic call again at a time when correct
scope information would have to be recomputed, collect calls to
predeclared panic in a set when type-checking that call.
Fixes#23218.
Change-Id: I35eaf010e5cb8e43696efba7d77cefffb6f3deb2
Reviewed-on: https://go-review.googlesource.com/85198
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
types.Eval historically never evaluated any delayed tests, which
included verification of validity of map keys, but also function
literal bodies.
Now, embedded interfaces are also type-checked in a delayed fashion,
so it becomes imperative to do all delayed checks for eval (otherwise
obviously incorrect type expressions are silently accepted).
Enabling the delayed tests also removes the restriction that function
literals were not type-checked.
Also fixed a bug where eval wouldn't return a type-checking error
because check.handleBailout was using the wrong err variable.
Added tests that verify that method set computation is using the
right types when evaluating interfaces with embedded types.
For #18395.
For #22992.
Change-Id: I574fa84568b5158bca4b4ccd4ef5abb616fbf896
Reviewed-on: https://go-review.googlesource.com/84898
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
The existing code associated methods with receiver base type
names before knowing if a type name denoted a locally defined
type. Sometimes, methods would be incorrectly associated with
alias type names and consequently were lost down the road.
This change first collects all methods with non-blank names
and in a follow-up pass resolves receiver base type names to
valid non-alias type names with which the methods are then
associated.
Fixes#23042.
Change-Id: I7699e577b70aadef6a2997e882beb0644da89fa3
Reviewed-on: https://go-review.googlesource.com/83996
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
Functions (at the package level) were collected and their bodies
type-checked after all other package-level objects were checked.
But function literals where type-checked right away when they were
encountered so that they could see the correct, partially populated
surrounding scope, and also to mark variables of the surrounding
function as used.
This approach, while simple, breaks down in esoteric cases where
a function literal appears inside the declaration of an object
that its body depends on: If the body is type-checked before the
object is completely set up, the literal may use incomplete data
structures, possibly leading to spurious errors.
This change postpones type-checking of function literals to later;
after the current expression or statement, but before any changes
to the enclosing scope (so that the delayed type-checking sees the
correct scope contents).
The new mechanism is general and now is also used for other
(non-function) delayed checks.
Fixes#22992.
Change-Id: Ic95f709560858b4bdf8c645be70abe4449f6184d
Reviewed-on: https://go-review.googlesource.com/83397
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11
Also: Moved Checker.pos field into context where it belongs.
This is a cleanup/code factoring.
For #22992.
Change-Id: If9d4f0af537cb181f73735e709ebc8258b2a1378
Reviewed-on: https://go-review.googlesource.com/83017
Reviewed-by: Alan Donovan <adonovan@google.com>
R=go1.11.
The existing algorithm for type-checking interfaces breaks down in
complex cases of recursive types, e.g.:
package issue21804
type (
_ interface{ m(B) }
A interface{ a(D) }
B interface{ A }
C interface{ B }
D interface{ C }
)
var _ A = C(nil)
The underlying problem is that the method set of C is computed by
following a chain of embedded interfaces at a point when the method
set for one of those interfaces is not yet complete. A more general
problem is largely avoided by topological sorting of interfaces
depending on their dependencies on embedded interfaces (but not
method parameters).
This change fixes this problem by fundamentally changing how
interface method sets are computed: Instead of determining them
based on recursively type-checking embedded interfaces, the new
approach computes the method sets of interfaces separately,
based on syntactic structure and name resolution; and using type-
checked types only when readily available (e.g., for local types
which can at best refer to themselves, and imported interfaces).
This approach avoids cyclic dependencies arising in the method
sets by separating the collection of embedded methods (which
fundamentally cannot have cycles in correct programs) and type-
checking of the method's signatures (which may have arbitrary
cycles).
As a consequence, type-checking interfaces can rely on the
pre-computed method sets which makes the code simpler: Type-
checking of embedded interface types doesn't have to happen
anymore during interface construction since we already have
all methods and now is delayed to the end of type-checking.
Also, the topological sort of global interfaces is not needed
anymore.
Fixes#18395.
Change-Id: I0f849ac9568e87a32c9c27bbf8fab0e2bac9ebb1
Reviewed-on: https://go-review.googlesource.com/79575
Reviewed-by: Alan Donovan <adonovan@google.com>
* 74b56022a1 doc: note that x509 cert parsing rejects some more certs now
* c52e27e68d CONTRIBUTING: remove Pull Request bit
* 829b64c1ea cmd/fix: fix cast check
* ee59f6dff2 doc: minor wording improvement to the diagnostics guide
* c6e7330ebd all: remove PULL_REQUEST_TEMPLATE from .github
* d814c2be9b doc: remove Pull Request note in README.md
* 104445e314 doc: document Go 1.9.4 and Go 1.8.7
Change-Id: I58bfc6800964504258690d774a9b0aeaba509086
Also remove the "Also, please do not post patches on the issue
tracker" part, since that didn't seem to reduce the number of patches
inlined into bug reports. And now that we accept PRs, people will
probably try that first. We'll see.
Fixes#23779
Updates #18517
Change-Id: I449e0afd7292718e57d9d428494799c78296a0d2
Reviewed-on: https://go-review.googlesource.com/93335
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Need 2-result cast so we can check the result correctly.
Fixes#23762
Change-Id: Icac3a5415156fe918988f369d6022a9a29c14089
Reviewed-on: https://go-review.googlesource.com/93078
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since we now accept Pull Requests via GerritBot, this comment is obsolete.
Change-Id: I0de8ecff7d1f146320a52f143e65068f8adbeaa6
GitHub-Last-Rev: 01818bdf7a
GitHub-Pull-Request: golang/go#23752
Reviewed-on: https://go-review.googlesource.com/92995
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds the go get security fix.
* 1dcb5836 cmd/go: accept only limited compiler and linker flags in #cgo directives
Change-Id: Ib2caf2039d2cefabe3afa0bb4dcc4c0dc8d664ff
Both gcc and clang accept an option -fplugin=code.so to load
a plugin from the ELF shared object file code.so.
Obviously that plugin can then do anything it wants
during the build. This is contrary to the goal of "go get"
never running untrusted code during the build.
(What happens if you choose to run the result of
the build is your responsibility.)
Disallow this behavior by only allowing a small set of
known command-line flags in #cgo CFLAGS directives
(and #cgo LDFLAGS, etc).
The new restrictions can be adjusted by the environment
variables CGO_CFLAGS_ALLOW, CGO_CFLAGS_DISALLOW,
and so on. See the documentation.
In addition to excluding cgo-defined flags, we also have to
make sure that when we pass file names on the command
line, they don't look like flags. So we now refuse to build
packages containing suspicious file names like -x.go.
A wrinkle in all this is that GNU binutils uniformly accept
@foo on the command line to mean "if the file foo exists,
then substitute its contents for @foo in the command line".
So we must also reject @x.go, flags and flag arguments
beginning with @, and so on.
Fixes#23672, CVE-2018-6574.
Change-Id: I59e7c1355155c335a5c5ae0d2cf8fa7aa313940a
Reviewed-on: https://team-review.git.corp.google.com/209949
Reviewed-by: Ian Lance Taylor <iant@google.com>
* b2d3d6e6 cmd/link/internal/loadelf: fix logic for computing ELF flags on ARM
* c07095cd cmd/cgo: revert CL 49490 "fix for function taking pointer typedef"
* 23e8e197 cmd/compile: use unsigned loads for multi-element comparisons
* 85bdd05c cmd/go: rebuild as needed for tests of packages that add methods
* fd7331a8 text/template: revert CL 66410 "add break, continue actions in ranges"
* f54f780d cmd/vet: unexported interface{} fields on %s are ok
* a0222ec5 cmd/internal/obj/arm64: fix assemble add/adds/sub/subs/cmp/cmn(extended register) bug
* 59523176 cmd/go: only run -race test if -race works
* 4558321e doc/editors: remove feature matrix for various editors/IDEs
* e6756ec1 cmd/go: ignore coverpkg match on sync/atomic in atomic coverage mode
* 10d096fe cmd/go: fix import config debugging flag
* f598ad58 go/internal/gccgoimporter: remove old and exp gccgo packages in test
* 2a8229d9 misc/cgo/test: get uintptr, not pointer, from dlopen
* 851e98f0 spec: remove need for separate Function production (cleanup)
* cbe1a61e net: fix the kernel state name for TCP listen queue on FreeBSD
* 6f37fee3 cmd/go: fix TestNoCache on Plan 9
* e5186895 runtime: restore RSB for sigpanic call on mips64x
* 3ff41cdf runtime: suppress "unexpected return pc" any time we're in cgo
* d929e40e syscall: use SYS_GETDENTS64 on linux/mips64{,le}
* 43288467 test: add test for gccgo bug 23545
* 19150303 cmd/go: if unable to initialize cache, just disable it
* ebe38b86 runtime: fail silently if we unwind over sigpanic into C code
* 5c2be42a runtime: don't unwind past asmcgocall
* 03e10bd9 os/signal: skip TestTerminalSignal if posix_openpt fails with EACCES
* d30591c1 cmd/vendor/github.com/google/pprof: cherry-pick fix to cope with $HOME not being writable
* bcc86d5f doc: add GOMIPS to source installation docs
* 926f2787 cmd/fix: cleanup directories created during typecheck
* 32a08d09 bootstrap.bash: only fetch git revision if we need it
* 14f8027a cmd/vet: extra args if any formats are indexed are ok
* 4072608b cmd/vet: %s is valid for an array of stringer
* 1f85917f cmd/vet: **T is not Stringer if *T has a String method
* 8c1f21d9 cmd/vet: disable complaint about 0 flag in print
* d529aa93 doc: fix the closing tag in contribute.html
* f8610bbd doc: fix two small mistakes in 1.10 release notes
* 5af1e7d7 cmd/go: skip external tests on plan9/arm
* 00587e89 doc: fix spelling mistake
* 3ee8c3cc os: document inheritance of thread state over exec
* b5b35be2 cmd/compile: don't inline functions that call recover
* 651ddbdb database/sql: buffers provided to Rows.Next should not be modified by drivers
* 7350297e doc: remove Sarah Adams from conduct working group contacts
Change-Id: I3c04d83706cd4322252ddf732688afe5d938c1f5
The linker contains complicated logic for figuring out which float ABI to
indicate it is using on (32 bit) ARM systems: it parses a special section in
host object files to look for a flag indicating use of the hard float ABI. When
loadelf got split into its own package a bug was introduced: if the last host
object file does not contain a float ABI related tag, the ELF header's flag was
set to 0, rather than using the value from the last object file which contained
an ABI tag. Fix the code to only change the value used for the ELF header if a
tag was found.
This fixes an extremely confusing build failure on Ubuntu's armhf builders.
Change-Id: I0845d68d082d1383e4cae84ea85164cdc6bcdddb
Reviewed-on: https://go-review.googlesource.com/92515
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 49490 fixed a warning when compiling the C code generated by cgo,
but it introduced typedef conflicts in Go code that cgo is supposed to
avoid.
Original CL description:
cmd/cgo: fix for function taking pointer typedef
Fixes#19832
Updates #19832Fixes#23720
Change-Id: I22a732db31be0b4f7248c105277ab8ee44ef6cfb
Reviewed-on: https://go-review.googlesource.com/92455
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When loading multiple elements of an array into a single register,
make sure we treat them as unsigned. When treated as signed, the
upper bits might all be set, causing the shift-or combo to clobber
the values higher in the register.
Fixes#23719.
Change-Id: Ic87da03e9bd0fe2c60bb214b99f846e4e9446052
Reviewed-on: https://go-review.googlesource.com/92335
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
If A's external test package imports B, which imports A,
and A's (internal) test code also adds something to A that
invalidates anything in the export data from a build of A
without its test code, then strictly speaking we need to
rebuild B against the test-augmented version of A before
using it to build A's external test package.
We've been skating by without doing this for a very long time,
but I knew we'd need to handle it better eventually,
I planned for it in the new build cache simplifications,
and the code was ready. Now that we have a real-world
test case that needs it, turn on the "proper rebuilding" code.
It doesn't really matter how much things slow down, since
a real-world test cases that caused an internal compiler error
before is now handled correctly, but it appears to be small:
I wasn't able to measure an effect on "go test -a -c fmt".
And of course most builds won't use -a and will be cached well.
Fixes#6204.
Fixes#23701.
Change-Id: I2cd60cf400d1928428979ab05831f48ff7cee6ca
Reviewed-on: https://go-review.googlesource.com/92215
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new break and continue actions do not work in html/template, and
fixing them requires thinking about security issues that seem too
tricky at this stage of the release. We will try again for 1.11.
Original CL description:
text/template: add break, continue actions in ranges
Adds the two range control actions "break" and "continue". They act the
same as the Go keywords break and continue, but are simplified in that
only the innermost range statement can be broken out of or continued.
Fixes#20531
Updates #20531
Updates #23683
Change-Id: Ia7fd3c409163e3bcb5dc42947ae90b15bdf89853
Reviewed-on: https://go-review.googlesource.com/92155
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For example, the following program is valid:
type T struct {
f interface{}
}
func main() {
fmt.Printf("%s", T{"foo"}) // prints {foo}
}
Since the field is of type interface{}, we might have any value in it.
For example, if we had T{3}, fmt would complain. However, not knowing
what the type under the interface is, we must be conservative.
However, as shown in #17798, we should issue an error if the field's
type is statically known to implement the error or fmt.Stringer
interfaces. In those cases, the user likely wanted the %s format to call
those methods. Keep the vet error in those cases.
While at it, add more field type test cases, such as custom error types,
and interfaces that extend the error interface.
Fixes#23563.
Change-Id: I063885955555917c59da000391b603f0d6dce432
Reviewed-on: https://go-review.googlesource.com/90516
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current code encodes the wrong option value in the binary.
The fix reconstructs the function opxrrr() that does not encode the option
value into the binary value when arguments is sign or zero-extended register.
Add the relevant test cases and negative tests.
Fixes#23501
Change-Id: Ie5850ead2ad08d9a235a5664869aac5051762f1f
Reviewed-on: https://go-review.googlesource.com/88876
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The speed of feature development for these products outpaces the
standard Go 6-month release cycle tied to this page. The cost of
maintaining this list is becoming a burden as we make every
attempt at being impartial. As of this writing, we believe feature
lists belong on the pages of the editors/IDEs themselves.
Change-Id: Ie2dfe0e0d47d203c913373e58cbb65cb0fb14d0c
Reviewed-on: https://go-review.googlesource.com/91976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
