The typechecking code for dealing with dot imports and redeclaration
errors can be removed, as these will now always be caught by types2
instead. Even when running the typecheck on internally constructed IR,
we'll never introduce new imports or redeclare identifiers.
Also, Func.Shortname (and typecheck.addmethod) was only used by the
-G=0 frontend. The new types2-based frontends directly associate
methods with their receiver type during IR construction.
Change-Id: I6578a448412141c87a0a53a6566639d9c00eeed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388537
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This code was only needed for supporting -G=0 mode, which is now gone.
Change-Id: I504887ab179e357a3cd21ef582f9edae49f6cbb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388536
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Post 1.18, we're committed to types2 as cmd/compile's type checker.
Change-Id: I30d2dd2b2ba62832fcdcaeb996fcbc8a4a05d591
Reviewed-on: https://go-review.googlesource.com/c/go/+/388535
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The next CL will remove the -G flag, effectively hard-coding it to its
current default (-G=3).
Change-Id: Ib4743b529206928f9f1cca9fdb19989728327831
Reviewed-on: https://go-review.googlesource.com/c/go/+/388534
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
No need to eagerly read the object dictionary or setup the object
reader outside of the lazy resolve function.
Change-Id: Ic4245b0c09f3beaff97860d7f2dfb5b2b5778cc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/388615
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This keeps cmd/compile/internal/importer similar to how
go/internal/gcimporter will work after unified IR support is added in
a subsequent CL.
Change-Id: Id3c000f3a13a54a725602552c6b3191d1affb184
Reviewed-on: https://go-review.googlesource.com/c/go/+/388614
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Just a cleanup to make sure that generic SSA is properly typed.
Change-Id: Ie75fa972ae4e5fdaca535968769bca36044191c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/372574
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
For certain values of GOMAXPROCS, the current code is less random than
it looks. For example with GOMAXPROCS=12, there are 4 coprimes: 1 5 7 11.
That's bad, as 12 and 4 are not relatively prime. So if pos == 2, then we
always pick 7 as the inc. We want to pick pos and inc independently
at random.
Change-Id: I5c7e4f01f9223cbc2db12a685dc0bced2cf39abf
Reviewed-on: https://go-review.googlesource.com/c/go/+/369976
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Some of the SSA pseudo-variables like the memory variable don't
have a package. Print those gracefully instead of printing a panic.
Fixes#51108
Change-Id: I5c29029356e045c5cf70909d6e63666ebc58ffaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/384614
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This logic is needed for the go/types unified IR importer, so extract
it into a separate internal package so we can reuse a single copy.
Change-Id: I5f734b76e580fdb69ee39e45ac553c22d01c5909
Reviewed-on: https://go-review.googlesource.com/c/go/+/386000
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Unified IR quirks mode existed to help bootstrap unified IR by forcing
it to produce bit-for-bit identical output to the original gc noder
and typechecker. However, I believe it's far enough along now to stand
on its own, plus we have good test coverage of generics already for
-G=3 mode.
Change-Id: I8bf412c8bb5d720eadeac3fe31f49dc73679da70
Reviewed-on: https://go-review.googlesource.com/c/go/+/385998
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This is the start of the Go 1.19 development cycle, so update the
Version value accordingly. It represents the Go 1.x version that will
soon open up for development (and eventually become released).
Updates #40705
Updates #51336
Change-Id: Ic4b3f2c04b1fa5c588cb6d62e829f2ed1864e511
Reviewed-on: https://go-review.googlesource.com/c/go/+/388376
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The work and work_edit script tests ran go work init, which put the
current Go version into the go.work files. Before this change, the tests
used cmp to compare the outputs with a file that contained a literal
"go 1.18" line. Instead, use cmpenv so we can compare with
"go $goversion". (Some of the test cases still compare against files
that contain "go 1.18" lines, but these tests explicitly set the version
to go 1.18 either in the original go.work files or using go work edit.)
Change-Id: Iea2caa7697b5fe5939070558b1664f70130095ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/388514
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Converting an untyped constant to a type parameter results
in a non-constant value; but the constant must still be
representable by all specific types of the type parameter.
Adjust the special handling for constant-to-type parameter
conversions to also include string-to-[]byte and []rune
conversions, which are handled separately for conversions
to types that are not type parameters because those are not
constant conversions in non-generic code.
Fixes#51386.
Change-Id: I15e5a0fd281efd15af387280cd3dee320a1ac5e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/388254
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We convert type args to shape types inside instantiations. If an
instantiation constructs a compound type based on that shape type and
uses that as a type arg to another generic function being called, then
we have a type arg with a shape type embedded inside of it. In that
case, we need to substitute out those embedded shape types with their
underlying type.
If we don't do this, we may create extra unneeded shape types that
have these other shape types embedded in them. This may lead to
generating extra shape instantiations, and a mismatch between the
instantiations that we used in generating dictionaries and the
instantations that are actually called.
Updates #51303
Change-Id: Ieef894a5fac176cfd1415f95926086277ad09759
Reviewed-on: https://go-review.googlesource.com/c/go/+/387674
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently, syscall.syscall-like functions are defined as
cgo_unsafe_args, which makes them ABI0, as it takes the address of
the argument area based on ABI0 layout. Those functions are
linkname'd to the syscall package. When compiling the syscall
package, the compiler doesn't know they are ABI0 therefore
generate an ABIInternal call, which will use the wrapper. As some
of the functions (e.g. syscall6) has many arguments, the wrapper
would take a good amount of stack space. And those functions must
be nosplit. This causes nosplit overflow when building with -N -l
and -race.
Avoid that by rewriting the functions to not use cgo_unsafe_args.
Instead, make a struct locally and pass the address of that
struct. This way the functions are ABIInternal and the call will
not use the wrapper.
Fixes#51247.
Change-Id: I76c1ab86b9d28664fa7d5b9c7928fbb2fd8d1417
Reviewed-on: https://go-review.googlesource.com/c/go/+/386719
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In getInstantiation, we were not computing tparams correctly for the
case where the receiver of a method was a fully-instantiated type. This
wasn't affecting later parts of the function, since method
instantiations of fully-instantiated types were already being calculated
in an earlier path. But it did give us a non-typeparam when trying to
see if a shape was associated with a type param with a structural type.
The fix is just to get the typeparams associated with the base generic
type. Then we can eliminate a conditional check later in the code.
The tparam parameter of Shapify should always be non-nil
Fixes#51367
Change-Id: I6f95fe603886148b2dad0c581416c51373c85009
Reviewed-on: https://go-review.googlesource.com/c/go/+/388116
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Normally types of constants are emitted when the type is defined (an
ODCLTYPE). However, the types of constants where the type is an
instantiated generic type made inside the constant declaration, do not
normally get emitted. But the DWARF processor in the linker wants
to see those types. So we emit them during stenciling.
Fixes#51245
Change-Id: I59f20f1d7b91501c9ac760cf839a354356331fc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388117
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This update was created using the updatecontrib command:
go install golang.org/x/build/cmd/updatecontrib@latest
cd gotip
updatecontrib
With manual changes based on publicly available information
to canonicalize letter case and formatting for a few names.
For #12042.
Change-Id: If08b7e798cff6ec4248011bdadcc524b510aaff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/388394
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
The existing test for 51219 didn't actually trigger the types2 issue - I
hadn't been able to minimize the test case yet properly. This new test
case issue51219b.go now does trigger the types2 issue (it's only
slightly different).
Updates #51219
Change-Id: Iaba8144b4702ff4fefec86c899b8acef127b10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387814
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The problem in 51355 is that escape analysis decided that the
dictionary variable was captured by reference instead of by value. We
want dictionaries to always be captured by value.
Escape analysis was confused because it saw what it thought was a
reassignment of the dictionary variable. In fact, it was the only
assignment, it just wasn't marked as the defining assignment. Fix
that.
Add an assert to make sure this stays true.
Fixes#51355
Change-Id: Ifd9342455fa107b113f5ff521a94cdbf1b8a7733
Reviewed-on: https://go-review.googlesource.com/c/go/+/388115
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In case of a selector expression x.sel where x is a built-in
we didn't report an error because the type of built-ins is
invalid and we surpress errors on operands of invalid types,
assuming that an error has been reported before.
Add a corresponding check for this case.
Review all places where we call Checker.exprOrType to ensure
(invalid) built-ins are reported.
Adjusted position for index error in types2.
Fixes#51360.
Change-Id: I24693819c729994ab79d31de8fa7bd370b3e8469
Reviewed-on: https://go-review.googlesource.com/c/go/+/388054
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In the dev.typeparams branch, the documentation for Type.Underlying was
updated with commentary about forwarding chains. This aspect of
Underlying should not be exposed to the user. Revert to the
documentation of Go 1.16.
Fixes#51036
Change-Id: I4b73d3908a88606314aab56540cca91c014dc426
Reviewed-on: https://go-review.googlesource.com/c/go/+/388036
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
64-bit atomic functions on ARM have the following structure:
- check if the address is 64-bit aligned, if not, prepare a frame
and call panicUnaligned
- tail call armXXX or goXXX depending on GOARM
The alignment check calls panicUnaligned after preparing a frame,
so the stack can be unwound. The call never returns, so the SP is
not set back. However, the assembler assigns SP delta following
the instruction stream order, not the control flow. So it leaves
a nonzero SP delta after the check, to the tail call instructions,
which is wrong because when they are executed the SP is not
decremented. This CL fixes this by adding the SP back (the
instruction never executes, just tells the assembler to set the
SP delta back).
Should fix#51353.
Change-Id: I976cb1cfb0e9008b13538765cbc7eea0c19c7130
Reviewed-on: https://go-review.googlesource.com/c/go/+/388014
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Delay validation of receiver type as it may cause premature expansion
of types the receiver type is dependent on. This was actually a TODO.
While the diff looks large-ish, the actual change is small: all the
receiver validation code has been moved inside the delayed function
body, and a couple of comments have been adjusted.
Fixes#51232.
Fixes#51233.
Change-Id: I44edf0ba615996266791724b832d81b9ccb8b435
Reviewed-on: https://go-review.googlesource.com/c/go/+/387918
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For #45964
Change-Id: Ic66502c50ca328e944c91e710dca6c8dbc168e4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/387855
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Check receiver type parameter count when type checking the method
signature and report a suitable error (don't rely on delayed
instantiation and possibly constraint type inference).
While at it, simplify blank name recoding and type bound rewriting.
Stop-gap measure to avoid crashes in the compiler.
Fixes#51339.
For #51343.
Change-Id: Idbe2d32d69b66573ca973339f8924b349d2bc9cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/387836
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TypeParam.is also provides ~ (tilde) information which is needed
to fix#51229. Delete all code related to singleType as it's not
used anymore.
Also, remove TypeParam.hasTerms as it was not used.
For #51229.
Change-Id: Ie49b19d157230beecb17a444d1f17cf24aa4f6ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/387774
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Previous versions of the 'go' command would reject a pseudo-version
passed to 'go get' if that pseudo-version had a mismatched major
version and lacked a "+incompatible" suffix. However, they would
erroneously accept a version *with* a "+incompatible" suffix even if
the repo contained a vN/go.mod file for the same major version, and
would generate a "+incompatible" pseudo-version or version if the user
requested a tag, branch, or commit hash.
This change uniformly rejects "vN.…" without "+incompatible", and also
avoids resolving to "vN.…+incompatible", when vN/go.mod exists.
To maintain compatibility with existing go.mod files, it still accepts
"vN.…+incompatible" if the version is requested explicitly as such
and the repo root lacks a go.mod file.
Fixes#51324
Updates #36438
Change-Id: I2b16150c73fc2abe4d0a1cd34cb1600635db7139
Reviewed-on: https://go-review.googlesource.com/c/go/+/387675
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
We changed to delaying all transforms of generic functions, since there
are so many complicated situations where type params can be used. We
missed changing so that all Call expressions(not just some) are delayed
if in a generic function. This changes to delaying all transforms on
calls in generic functions. Had to convert Call() to g.callExpr() (so we
can access g.delayTransform()). By always delaying transforms on calls
in generic functions, we actually simplify the code a bit both in
g.CallExpr() and stencil.go.
Fixes#51236
Change-Id: I0342c7995254082c4baf709b0b92a06ec14425e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/386220
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Use a cleanup method and simple registration mechanism
for types that need some final processing before the end
of type checking.
Use cleanup mechanism instead of expandDefTypes mechanism
for *Named types. There is no change in functionality here.
Use cleanup mechanism also for TypeParam and Interface types
to ensure that their check fields are nilled out at the end.
Introduce a simple constructor method for Interface types
to ensure that the cleanup method is always registered.
In go/types, add tracing code to Checker.checkFiles to match
types2.
Minor comment adjustments.
Fixes#51316.
Fixes#51326.
Change-Id: I7b2bd79cc419717982f3c918645af623c0e80d5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/387417
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
A type implements a comparable interface only if the type
is statically known to be comparable. Specifically, a type
cannot contain (component) interfaces that are not statically
known to be comparable.
This CL adds a flag "dynamic" to the comparable predicate to
control whether interfaces are always (dynamically) comparable.
Set the flag to true when testing for (traditional) Go comparability;
set the flag to false when testing whether a type implements the
comparable interface.
Fixes#51257.
Change-Id: If22bc047ee59337deb2e7844b8f488d67e5c5530
Reviewed-on: https://go-review.googlesource.com/c/go/+/387055
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 374294 made our check for incorrect type parameters constraints
eager, but failed to remove the construction of the bounds slice, which
was no longer used.
Change-Id: Ib8778fba947ef8a8414803e95d72c49b8f75c204
Reviewed-on: https://go-review.googlesource.com/c/go/+/386717
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There is code in the wild that copies the Buffers slice,
but not the contents.
Let's document explicitly that it is not safe to do so.
Updates #45163
Change-Id: Id45e27b93037d4e9f2bfde2558e7869983b60bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/387434
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
The tag was "go-mod-vendor", which doesn't match the content.
Also move that section later, so "go mod" sections stay together.
For #47694.
Change-Id: Id4fa7ee0768682a9aadfeb1b2f1d723e7521896b
Reviewed-on: https://go-review.googlesource.com/c/go/+/387354
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As documented in #51209, we have been seeing a low-rate failure
on macOS builders caused by spurious x509 “certificate is expired” errors.
The root cause is that CFDateCreate takes a float64, but it is being
passed a uintptr instead. That is, we're not even putting CFDateCreate's
argument in the right register during the call. Luckily, having just
computed the argument by calling time.Duration.Seconds, which
returns a float64, most of the time the argument we want is still
in the right floating point register, somewhat accidentally.
The only time the lucky accident doesn't happen is when the goroutine
is rescheduled between calling time.Duration.Seconds and calling
into CFDateCreate *and* the rescheduling smashes the floating point
register, which can happen during various block memory moves,
since the floating point registers are also the SIMD registers.
Passing the float64 through explicitly eliminates the problem.
It is difficult to write a test for this that is suitable for inclusion
in the standard library. We will have to rely on the builders to
start flaking again if somehow this problem is reintroduced.
For future reference, there is a standalone test that used to fail
every few seconds at https://go.dev/play/p/OWfDpxgnW9g.
Fixes#51209.
Change-Id: I8b334a51e41f406b13f37270e9175c64fe6f55ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/387255
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Updates #47694
Change-Id: I6c1c3698fdd55fe83c756f28776d1d26dba0a9df
Reviewed-on: https://go-review.googlesource.com/c/go/+/386974
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When encoding a xml attribute is zero value (IsValid == false), we need
a `continue` to jump over the attribute. If not, followed marshalAttr
function will panic.
Fixes: #50164
Change-Id: I42e064558e7becfbf47728b14cbf5c7afa1e8798
Reviewed-on: https://go-review.googlesource.com/c/go/+/385514
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
