CL 196781 added map[int64]uint32 to the set of things printed with %v.
Fixes#34907
Change-Id: If4a13e86cfb4b691988f5fb70449ae23760f5789
Reviewed-on: https://go-review.googlesource.com/c/go/+/201079
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was possible to get 'go env' to break itself:
$ go env -w GO111MODULE=bad
$ go env
go: unknown environment setting GO111MODULE=bad
We already check if the variable name is known. In some cases like
GO111MODULE, we also know what the variable's valid values are. Enforce
it when writing the variable, not just when fetching it.
Fixes#34880.
Change-Id: I10d682087c69f3445f314fd4473644f694e255f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/200867
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Before this CL, inequality was recorded in a bit matrix using
SSA IDs. This allowed to record inequality for SSA values that
we didn't know any relation in the partial order of. Unfortunately,
this also means that inequality is harder to use within the poset
itself as there is not fast way to map from internal poset indices
and SSA values.
Since we will need to check for inequality in following CLs within
code that lost track of SSA values, switch to use a bit matrix
of poset indices instead. This requires always allocate a poset
node (as a new root) for values that are first seen in a SetNonEqual
call, but it doesn't sound like a big problem. The other solution
(creating and maintaining a reverse map from poset indices to SSA
values) seem more complicated and memory hungry.
Change-Id: Ic917485abbe70aef7ad6fa98408e5430328b6cd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/196782
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, constants in posets, in addition to being stored in
a DAG, are also stored as SSA values in a slice. This allows to
quickly go through all stored constants, but it's not easy to search
for a specific constant.
Following CLs will benefit from being able to quickly find
a constants by value in the poset, so change the constants
structure to a map. Since we're at it, don't store it as
*ssa.Value: poset always uses dense uint32 indices when
referring a node, so just switch to it.
Using a map also forces us to have a single node per
constant value: this is a good thing in the first place,
so this CL also make sure we never create two nodes for
the same constant value.
Change-Id: I099814578af35f935ebf14bc4767d607021f5f8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/196781
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The comment in both functions referred to the wrong header and I made
the checks easier to read.
Change-Id: Ifb46729cee631a3305f557863818e3487b8eed71
Reviewed-on: https://go-review.googlesource.com/c/go/+/71753
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add an internal mode to simplify debugging of posets
by checking the integrity after every mutation. Turn
it on within SSA checked builds.
Change-Id: Idaa8277f58e5bce3753702e212cea4d698de30ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/196780
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Fixes the docs to correctly match the implementation
and also adds a test locking-in the behavior to prevent
any accidental future regressions on the docs.
Fixes#33545
Change-Id: I6fdac6048cce8ac99beaa2db0dfc81d0dccc10f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200798
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The IsClosureVar, IsOutputParamHeapAddr, Assigned, Addrtaken,
InlFormal, and InlLocal flags are only interesting for ONAME nodes, so
it's better to set these flags on Name.flags instead of Node.flags.
Two caveats though:
1. Previously, we would set Assigned and Addrtaken on the entire
expression tree involved in an assignment or addressing operation.
However, the rest of the compiler only actually cares about knowing
whether the underlying ONAME (if any) was assigned/addressed.
2. This actually requires bumping Name.flags from bitset8 to bitset16,
whereas it doesn't allow shrinking Node.flags any. However, Name has
some trailing padding bytes, so expanding Name.flags doesn't cost any
memory.
Passes toolstash-check.
Change-Id: I7775d713566a38d5b9723360b1659b79391744c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/200898
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For Go 1.13 we introduced Header.Clone and it returns
nil if a nil Header is cloned. Unfortunately, though,
this exported Header.Clone nil behavior differed from
the old Go 1.12 and earlier internal header clone
behavior which always returned non-nil Headers.
This CL fixes the places where that distinction mattered.
Fixes#34878
Change-Id: Id19dea2272948c8dd10883b18ea7f7b8b33ea8eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/200977
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add to the testcase originally created for issue 34577 so
as to also trigger the error condition for issue 34852 (the
two bugs are closely related).
Updates #34577.
Updates #34852.
Change-Id: I2347369652ce500184347606b2bb3e76d802b204
Reviewed-on: https://go-review.googlesource.com/c/go/+/201017
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For GOROOT packages, we were adding -unsafeptr=false to prevent unsafe.Pointer
checks. But the flag also got passed to invocations of go vet with a custom
vet tool. To prevent this from happening, we add this flag only when no
tools are passed.
Fixes#34053
Change-Id: I8bcd637fd8ec423d597fcdab2a0ceedd20786019
Reviewed-on: https://go-review.googlesource.com/c/go/+/200957
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
These are unused since the darwin port switched to libc calls in
CL 148457.
Change-Id: I309bb5b0a52c9069484e7a649d4a652efcb8e160
Reviewed-on: https://go-review.googlesource.com/c/go/+/200866
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This flag is supposed to indicate whether the expression is
"addressable"; but in practice, we infer this from other
attributes about the expression (e.g., n.Op and n.Class()).
Passes toolstash-check.
Change-Id: I19352ca07ab5646e232d98e8a7c1c9aec822ddd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/200897
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This pseudo-Class was previously used by the importer code to optimize
processing duplicate inline bodies, since we didn't actually care
about the declarations in those contexts.
This functionality is no longer needed with indexed exports, since we
now only process function bodies as needed (and never more than once).
Passes toolstash-check.
Change-Id: I7eab0cb16925ab777079c2a20731dbcfd63cf195
Reviewed-on: https://go-review.googlesource.com/c/go/+/200899
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make it a bit more relaxed on the expected fairness, as fastrand()
isn't a truly perfect random number generator.
Fixes#34808
Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b
Reviewed-on: https://go-review.googlesource.com/c/go/+/200857
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Some nameservers alter the case of records as they return, e.g
.google.COM or .Google.com.
However according to RFC4343, DNS name should be treated in case insensitive fashion.
This CL will fix case sensitive testcases.
Fixes#34781
Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/200277
Reviewed-by: Andrei Tudor Călin <mail@acln.ro>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When assessing whether A <= B, the poset's OrderedOrEqual has a passing
condition which permits A <= B, but is not sufficient to infer that A <= B.
This CL removes that incorrect passing condition.
Having identified that A and B are in the poset, the method will report that
A <= B if any of these three conditions are true:
(1) A and B are the same node in the poset.
- This means we know that A == B.
(2) There is a directed path, strict or not, from A -> B
- This means we know that, at least, A <= B, but A < B is possible.
(3) There is a directed path from B -> A, AND that path has no strict edges.
- This means we know that B <= A, but do not know that B < A.
In condition (3), we do not have enough information to say that A <= B, rather
we only know that B == A (which satisfies A <= B) is possible. The way I
understand it, a strict edge shows a known, strictly-ordered relation (<) but
the lack of a strict edge does not show the lack of a strictly-ordered relation.
The difference is highlighted by the example in #34802, where a bounds check is
incorrectly removed by prove, such that negative indexes into a slice
succeed:
n := make([]int, 1)
for i := -1; i <= 0; i++ {
fmt.Printf("i is %d\n", i)
n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!!
}
When prove is checking the negative/failed branch from the bounds check at n[i],
in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn
the OR condition, we check whether we know that i is non-negative so we can
learn something, namely that i >= len(n). Prove uses the poset to check whether
we know that i is non-negative. At this point the poset holds the following
relations as a directed graph:
-1 <= i <= 0
-1 < 0
In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3)
above is true because there is a non-strict path from i -> 0, and that path
does NOT have any strict edges. Because this condition is true, the poset
reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0,
prove learns from the failed bounds check that i >= len(n) in the signed domain.
When the slice, n, was created, prove learned that len(n) == 1. Because i is
also the induction variable for the loop, upon entering the loop, prove previously
learned that i is in [-1,0]. So when prove attempts to learn from the failed
bounds check, it finds the new fact, i > len(n), unsatisfiable given that it
previously learned that i <= 0 and len(n) = 1.
Fixes#34802
Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/200759
Run-TryBot: Zach Jones <zachj1@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Keith Randall <khr@golang.org>
nanotime() currently uses the REALTIME clock to get the elapsed
time in Solaris. This commit changes it to use the MONOTONIC clock
instead, similar to how it's done in Linux and other OSs. Also changed
nanotime() and walltime() to call clock_gettime() library function
directly from Go code rather than from assembly.
Fixes#33674
Change-Id: Ie4a687b17d2140998ecd97af6ce048c86cf5fc02
Reviewed-on: https://go-review.googlesource.com/c/go/+/199502
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
This timeout will never be reached if the test passes, so it doesn't
much matter how long it is. The test is t.Parallel so on a slow system
1 second may occasionally not be enough, although on my laptop the
test takes about 0.02 seconds.
Fixes#34431
Change-Id: Ia2184e6be3747933bfe83aa6c8e1f77e6b1e0bba
Reviewed-on: https://go-review.googlesource.com/c/go/+/200764
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If the runtime disables the SIGPROF handler, because this is Go code
that is linked into a non-Go program, then don't go back to the
default handling of SIGPROF; just start ignoring SIGPROF.
Otherwise the program can get killed by a stray SIGPROF that is
delivered, presumably to a different thread, after profiling is disabled.
Fixes#19320
Change-Id: Ifebae477d726699c8c82c867604b73110c1cf262
Reviewed-on: https://go-review.googlesource.com/c/go/+/200740
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The slice capacity is known for all these cases. Therefore,
we can initialize them with the desired capacity.
Change-Id: I1835b49108d157203d62e4aa119c2d7ab5e5e46f
Reviewed-on: https://go-review.googlesource.com/c/go/+/200119
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change integrates changes made to x/mod packages into our internal
copies of those packages.
This is the first step of a bidirectional synchronization. A follow-up
change will copy changes made to the internal packages after x/mod was
forked. After that, we can vendor x/mod, update imports, and delete
the internal copies.
The following packages are affected:
* internal/module
* internal/semver (no change)
* internal/sumweb (renamed to internal/sumdb)
* internal/dirhash
* internal/note
* internal/tlog
Several integrated changes affect other packages:
* cmd/go/internal/module.MatchPathMajor now wraps a new function,
CheckPathMajor, which returns error. MatchPathMajor returns
bool. This will avoid an incompatible change in the next step.
* module.EncodePath renamed to EscapePath, EncodeVersion to
EscapeVersion, DecodePath to UnescapePath, DecodeVersion to
UnescapeVersion.
* cmd/go/internal/sumweb moved to cmd/go/internal/sumdb and package
renamed to sumdb.
* sumdb.Client renamed to ClientOps, Conn to Client, Server to
ServerOps, Paths to ServerPaths.
* sumdb/encode.go and encode_test.go are not present in x/mod since
they are redundant with functionality in module. Both files are
deleted.
* sumdb.TestServer doesn't implement sumdb.ServerOps after changes
were were made to golang.org/x/mod/sumdb.ServerOps during the fork.
Local changes made so tests will pass. These will be copied to x/mod
in the next step.
Updates #34801
Change-Id: I7e820f10ae0cdbec238e59d039e978fd1cdc7201
Reviewed-on: https://go-review.googlesource.com/c/go/+/200138
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
An extra goroutine is necessary to handle asynchronous events on wasm.
However, we do not want this goroutine to exist all the time.
This change makes it short-lived, so it ends after the asynchronous
event was handled.
Fixes#34768
Change-Id: I24626ff0af9d803a01ebe33fbb584d04d2059a44
Reviewed-on: https://go-review.googlesource.com/c/go/+/200497
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We couldn't do this before because sighandler was compiled for nacl.
Updates #30439
Change-Id: Ieec9938b6a1796c48d251cd8b1db1a42c25f3943
Reviewed-on: https://go-review.googlesource.com/c/go/+/200739
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
NextPart has automatic handling of quoted-printable encoding,
which is sometimes undesirable. NextRawPart adds a method
for reading a part while bypassing such automatic handling.
Fixes#29090
Change-Id: I6a042a4077c64091efa3f5dbecce0d9a34ac7065
Reviewed-on: https://go-review.googlesource.com/c/go/+/152877
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
RFC 5322 date format allows CFWS after the timezone.
If CFWS is valid, it is discarded and parsing is done as before
using time.Parse().
Existing test is extended with limit cases and invalid strings.
Fixes#22661
Change-Id: I54b96d7bc384b751962a76690e7e4786217a7941
Reviewed-on: https://go-review.googlesource.com/c/go/+/117596
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes Decoder.offset public while renaming it to
Decoder.InputOffset to match encoding/xml Decoder API
Code changes made by Adam Stankiewicz [sheerun@sher.pl]
Fixes#29688
Change-Id: I86dbfd2b2da80160846e92bfa580c53d8d45e2db
Reviewed-on: https://go-review.googlesource.com/c/go/+/200677
Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Avoid an out-of-range error when calling LongString on a generic
block.
Change-Id: I33ca88940d899bc71e3155bc63d2aa925cf83230
Reviewed-on: https://go-review.googlesource.com/c/go/+/200737
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Increases the exec timeout from 5sec to 1min, but
also print out the error value on any test failure.
Fixes#34836
Change-Id: Ida2b8bd460243491ef0f90dfe0f978dfe02a0703
Reviewed-on: https://go-review.googlesource.com/c/go/+/200519
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We should keep a consistent way of formatting errors
in this file.
Fixes#34848
Change-Id: Ibb75908504f381fccab0281a42e788ef8c716b6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/200679
Run-TryBot: Johan Brandhorst <johan.brandhorst@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
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>
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>
