There are two manually managed G dequeues. Abstract these both into a
shared gQueue type. This also introduces a gList type, which we'll use
to replace several manually-managed G lists in follow-up CLs.
This makes the code more readable and maintainable. gcFlushBgCredit in
particular becomes much easier to follow. It also makes it easier to
introduce more G queues in the future. Finally, the gList type clearly
distinguishes between lists of Gs and individual Gs; currently both
are represented by a *g, which can easily lead to confusion and bugs.
Change-Id: Ic7798841b405d311fc8b6aa5a958ffa4c7993c6c
Reviewed-on: https://go-review.googlesource.com/129396
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
TMLL, LGDR and LDGR have all been added to the Go assembler
previously, so we don't need to encode them using WORD and BYTE
directives anymore. This is purely a cosmetic change, it does not
change the contents of any object files.
Change-Id: I93f815b91be310858297d8a0dc9e6d8e3f09dd65
Reviewed-on: https://go-review.googlesource.com/129895
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously Scanner would allow float literals like "1.5e" and "1e+"
that weren't actually valid Go float literals, and also not valid
when passed to ParseFloat. This commit fixes that behaviour to match
the documentation ("recognizes all literals as defined by the Go
language specification"), and Scanner emits an error in these cases.
Fixes#26374
Change-Id: I6855402ea43febb448c6dff105b9578e31803c01
Reviewed-on: https://go-review.googlesource.com/129095
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add a CacheLinePad struct type to internal/cpu that has a size of CacheLineSize.
This can be used for padding structs in order to avoid false sharing.
Updates #25203
Change-Id: Icb95ae68d3c711f5f8217140811cad1a1d5be79a
Reviewed-on: https://go-review.googlesource.com/116276
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Only the first constant in the function and facility
constant declaration blocks were typed constants.
Make all other constants used for function codes and
named facilities also typed.
Change-Id: I1814121de3733094da699c78b7311f99ba4772e1
Reviewed-on: https://go-review.googlesource.com/126776
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Avoid using package specific variables when there is a one to one
correspondance to cpu feature support exported by internal/cpu.
This makes it clearer which cpu feature is referenced.
Another advantage is that internal/cpu variables are padded to avoid
false sharing and memory and cache usage is shared by multiple packages.
Change-Id: If18fb448a95207cfa6a3376f3b2ddc4b230dd138
Reviewed-on: https://go-review.googlesource.com/126596
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 52430 added logic to skip the testZoneAbbr test in locales where
the timezone does not have a three-letter name, because the following
line
Parse(RFC1123, t1.Format(RFC1123))
failed for timezones with only numeric names (like -07).
Since Go 1.11, Parse supports the parsing of timezones with numeric
names (this was implemented in CL 98157), so we can now run the test
unconditionally.
Change-Id: I8ed40e1ba325c0c0dc79c4184a9e71209e2e9a02
Reviewed-on: https://go-review.googlesource.com/127757
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The parentheses are not required for the definitions and it brings
the declaration style in line with other architectures feature bits
defined in internal/cpu.
Change-Id: I86cc3812c1488216779e0d1f0e7481687502e592
Reviewed-on: https://go-review.googlesource.com/126775
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Those new instructions have acquire/release semantics, besides
normal atomic SWPD/SWPW/SWPH/SWPB.
Change-Id: I24821a4d21aebc342897ae52903aef612c8d8a4a
Reviewed-on: https://go-review.googlesource.com/128476
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
FLD1 pushes +1.0 to the 387 register stack, and FLDZ pushes +0.0
to the 387 regiser stack.
They can be used to simplify MOVSSconst/MOVSDconst when the
constant is +0.0, -0.0, +1.0, -1.0.
The size of the go executable reduces about 62KB and the total size
of pkg/linux_386 reduces about 7KB with this optimization.
Change-Id: Icc8213b58262e0024a277cf1103812a17dd4b05e
Reviewed-on: https://go-review.googlesource.com/119635
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Two funcs and a field were unused. Remove them.
A few statements could be made simpler.
importsym's pos parameter was unused, so remove it.
Finally, don't use printf-like funcs with constant strings that have no
formatting directives.
Change-Id: I415452249bf2168aa353ac4f3643dfc03017ee53
Reviewed-on: https://go-review.googlesource.com/117699
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Issues #10043, #15405, and #22660 appear to have been fixed, and
whatever tests I could run locally do succeed, so remove the skips.
Issue #7237 was closed in favor of #17906, so update its skip line.
Issue #7634 was closed as it had not appeared for over three years.
Re-enable it for now. An issue should be open if the test starts being
skipped again.
Change-Id: I67daade906744ed49223291035baddaad9f56dca
Reviewed-on: https://go-review.googlesource.com/121735
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To report the capacity of the underlying buffer. The method mirrors
bytes.Buffer.Cap.
The method can be useful to know whether or not calling write or grow
methods will result in an allocation, or to know how much memory has
been allocated so far.
Fixes#26269.
Change-Id: I391db45ae825011566b594836991e28135369a78
Reviewed-on: https://go-review.googlesource.com/122835
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This lets us simplify the code considerably. For example, unquoting the
tag is no longer necessary, and we can get the field name with a single
method call.
While at it, fix a typechecking error in testdata/structtag.go, which
hadn't been caught since vet still skips past go/types errors in most
cases.
Using go/types will also let us expand the structtag check more easily
if we want to, for example to allow it to check for duplicates in
embedded fields.
Finally, update one of the test cases to check for regressions when we
output invalid tag strings. We also checked that these two changes to
testdata/structtag.go didn't fail with the old structtag check.
For #25593.
Change-Id: Iea4906d0f30a67f36b28c21d8aa96251aae653f5
Reviewed-on: https://go-review.googlesource.com/115676
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Port CL 120295 from golang.org/x/sys/unix to the syscall package.
The ustat syscall has been deprecated on Linux for a long time and the
upcoming glibc 2.28 will remove ustat.h and it can no longer be used to
to generate the Ustat_t wrapper type. Since Linux still provides the
syscall, let's not break this functionality and add a private copy of
struct ustat so Ustat_t can still be generated.
Fixesgolang/go#25990
Change-Id: I0dab2ba1cc76fbd21553b499f9256fd9d59ca409
Reviewed-on: https://go-review.googlesource.com/120563
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Combined appends lead to fewer machine code and faster performance.
Some may even say that it makes code more readable.
Running revAddrTests over reverseaddr gives measurable improvements:
name old time/op new time/op delta
ReverseAddress-8 4.10µs ± 3% 3.94µs ± 1% -3.81% (p=0.000 n=10+9)
Change-Id: I9bda7a20f802bcdffc6e948789765d04c6da04e7
Reviewed-on: https://go-review.googlesource.com/117615
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These are all errors given by module-aware cmd/go, so they must end with
a newline. It looks like they were omitted by mistake.
Fixes#27081.
Change-Id: I19b5803bb48a6d5dd52e857f483278fe20fe246b
Reviewed-on: https://go-review.googlesource.com/129780
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Need to actually use the flag for it to take effect.
Fixes#27049.
Change-Id: I57227b45f46f9dd67ecbf87c11bb2d08124bcfa0
Reviewed-on: https://go-review.googlesource.com/129801
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was a bug to find that commit in the Masterminds/semver repo.
It's not part of the main repo but only part of an unmerged pull request.
The code was updated to try not to look at unmerged pull requests,
but the test was not. Worse, whether the code succeeds at not looking
at unmerged pull requests apparently depends on the git version.
Sigh.
Fixes#26754.
Fixes#27043.
Change-Id: Ib9e07f565906de4f1169244911a258396688f14d
Reviewed-on: https://go-review.googlesource.com/129800
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In GOPATH mode the rule has always been that 'go run x.go' can
import whatever the package in x.go's directory would be able to
import. Apply the same rule here.
The bad import path was triggering other mysterious errors
during 'go run' in other circumstances. Setting it correctly fixes
those too.
Fixes#26046.
Fixes#27022.
Change-Id: I0a9b0a154a20f48add5a199da85572e7ffe0cde4
Reviewed-on: https://go-review.googlesource.com/129798
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is an important security problem so we shouldn't disable the test.
The second half was failing on case-sensitive file systems but the
first half is still good.
Fixes#22983.
Change-Id: I437bb4c9f78eb3177aa8b619e2357b2539566ca9
Reviewed-on: https://go-review.googlesource.com/129797
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If you run
go get -u github.com/rsc/foo/bar...
then the go get command has always worked hard to make sure
that it applies the wildcard after downloading rsc/foo.
(If it applied the wildcard only before downloading rsc/foo,
it would match nothing if you had an empty GOPATH before,
and you'd still have an empty afterward, which is clearly useless.)
The goal has always been that if you run the same go get
command twice, the second command doesn't find anything
new to do.
CL 19892 worked around an "internal error" failure but broke
the rule about the first command doing everything the second
command would. Suppose you had github.com/rsc/foo already,
with just github.com/rsc/foo/bar, and you run
go get -u github.com/rsc/...
The wildcard first matches github.com/rsc/foo/bar, but suppose
updating the repo pulls down github.com/rsc/foo/baz, which
in turn depends on the non-existent package github.com/rsc/quux.
We need to reevaluate the wildcard after the download.
The new pattern match refactoring makes this easier and happened
to have corrected the behavior, but we missed a long test that
expected the old behavior.
Fix that long test.
Change-Id: I088473e7a90925e5c0f9697da9554a11456ddd08
Reviewed-on: https://go-review.googlesource.com/129796
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we're looking for a module for a/b/c/d/e,
we check for a module named a/b/c/d/e,
then a/b/c/d, then a/b/c, then a/b, then a.
If we know the source repo for a/b/c and that
fails, we should report that error instead of
continuing the loop: a/b and a are useless,
and the error from a/b/c contains important
information.
The errors are now a bit more verbose than
I'd like but they will suffice for Go 1.11.
$ go get github.com/bradfitz/private/sonos
go get github.com/bradfitz/private/sonos: git ls-remote -q origin in /Users/rsc/pkg/mod/cache/vcs/61e3c76780847e514802ec6af8f940f641c6017f711444f05c59cb17ac46d456: exit status 128:
remote: Repository not found.
fatal: repository 'https://github.com/bradfitz/private/' not found
$ go list launchpad.net/gocheck
can't load package: package launchpad.net/gocheck: unknown import path "launchpad.net/gocheck": bzr branch --use-existing-dir https://launchpad.net/~niemeyer/gocheck/trunk . in /Users/rsc/pkg/mod/cache/vcs/f46ce2ae80d31f9b0a29099baa203e3b6d269dace4e5357a2cf74bd109e13339: exec: "bzr": executable file not found in $PATH
$
Fixes#26885.
Fixes#26982.
Change-Id: I2f9cf1853d2d68af18adad668c80513b6ba220d6
Reviewed-on: https://go-review.googlesource.com/129683
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
"go mod fix" does work already done by nearly every other go command.
It was also confusing why we had both "go mod fix" and "go mod tidy".
Delete "go mod fix".
The main reason we kept "go mod fix" this long was for the discussion
of automatic go.mod updates in its documentation, which is now moved
into a new "go help go.mod".
Fixes#26831.
Change-Id: Ic95ca8918449ab79791d27998e02eb3377ac7972
Reviewed-on: https://go-review.googlesource.com/129682
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The proxy protocol was simplified to only send
(and only receive) the Path and Version fields
in the JSON blob, not Name and Short.
(Those make sense when querying a VCS repo directly,
but not when talking about extracted modules.)
So don't expect them in the test.
Fixes#27042.
Change-Id: I3daacd668126e2227dcc8e6b89ee0cf0e3c8497c
Reviewed-on: https://go-review.googlesource.com/129684
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 129063 added a test in TestScript/mod_enabled,
which was failing on Plan 9.
The test was failing because the Init function
of the cmd/go/internal/modload package was
expecting ModRoot to be part of os.TempDir.
However, ModRoot was set to TMPDIR, while
os.TempDir is returning /tmp on Plan 9.
This change fixes the implementation of
os.TempDir on Plan 9 to handle the TMPDIR
environment variable, similarly to Unix.
Fixes#27065.
Change-Id: Id6ff926c5c379f63cab2dfc378fa6c15293fd453
Reviewed-on: https://go-review.googlesource.com/129775
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If you're in a directory corresponding to x/y
and you run go list ./z, we do at some point
want to turn that into x/y/z. But if ./z does
not exist that will make the go command
check the network to see if it can find x/y/z.
That's clearly wrong: ./z means that directory,
nothing else. And it turns a typo into a long delay,
which is even worse.
Fixes#26874.
Change-Id: Iec15fa7b359af11b6a4fc6cb082e593658fb6e41
Reviewed-on: https://go-review.googlesource.com/129061
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
It's important for some uses of go/packages, as well as for some
of go/packages's internal use, to be able to tell which results from
go list output correspond to which patterns, keeping in mind that
a single package might have been matched by multiple patterns.
Also adds test for #26925.
Change-Id: I708ac162f65d9946fe6afb244b08dc7b04d2b530
Reviewed-on: https://go-review.googlesource.com/129060
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
A flag setting like -gcflags=-e applies only to the packages
named on the command line, not to their dependencies.
The way we used to implement this was to remember the
command line arguments, reinterpret them as pattern matches
instead of package argument generators (globs), and apply them
during package load. The reason for this complexity was to
address a command-line like:
go build -gcflags=-e fmt runtime
The load of fmt will load dependencies, including runtime,
and the load of runtime will reuse the result of the earlier load.
Because we were computing the effective -gcflags for each
package during the load, we had to have a way to tell, when
encountering runtime during the load of fmt, that runtime had
been named on the command line, even though we hadn't
gotten that far. That would be easy if the only possible
arguments were import paths, but we also need to handle
go build -gcflags=-e fmt runt...
go build -gcflags=-e fmt $GOROOT/src/runtime
go build -gcflags=-e fmt $GOROOT/src/runt...
and so on.
The match predicates usually did their job well, but not
always. In particular, thanks to symlinks and case-insensitive
file systems and unusual ways to spell file paths, it's always
been possible in various corner cases to give an argument
that evalutes to the runtime package during loading but
failed to match it when reused to determine "was this package
named on the command line?"
CL 109235 fixed one instance of this problem by making
a directory pattern match case-insensitive on Windows, but that
is incorrect in some other cases and doesn't address the root problem,
namely that there will probably always be odd corner cases
where pattern matching and pattern globbing are not exactly aligned.
This CL eliminates the assumption that pattern matching
and pattern globbing are always completely in agreement,
by simply marking the packages named on the command line
after the package load returns them. This means delaying
the computation of tool flags until after the load too,
for a few different ways packages are loaded.
The different load entry points add some complexity,
which is why the original approach seemed more attractive,
but the original approach had complexity that we simply
didn't recognize at the time.
This CL then rolls back the CL 109235 pattern-matching change,
but it keeps the test introduced in that CL. That test still passes.
In addition to fixing ambiguity due to case-sensitive file systems,
this new approach also very likely fixes various ambiguities that
might arise from abuse of symbolic links.
Fixes#24232.
Fixes#24456.
Fixes#24750.
Fixes#25046.
Fixes#25878.
Change-Id: I0b09825785dfb5112fb11494cff8527ebf57966f
Reviewed-on: https://go-review.googlesource.com/129059
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
To date the go command has always just treated the command line
package patterns as a []string, expanded by pattern matching into
another []string. As a result, the code is not always clear about
whether a particular []string contains patterns or results.
A few different important bugs are caused by not keeping
this distinction clear enough. This CL sets us up well for fixing those,
by introducing an explicit search.Match struct holding the
results of matching a single pattern.
The added clarity here also makes it clear how to avoid duplicate
warnings about unmatched packages.
Fixes#26925. (Test in followup CL.)
Change-Id: Ic2f0606f7ab8b3734a40e22d3cb1e6f58d031061
Reviewed-on: https://go-review.googlesource.com/129058
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Also, rename an HTML element ID to avoid duplicate.
Fixesgolang/go#27038
Change-Id: Icc064a1cc86ddc794fc085d98b4cde3effff8ad0
Reviewed-on: https://go-review.googlesource.com/129635
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Only the expected headings are affected.
Diffing the output of "go run headscan.go" before and after:
$ diff head1 head2
26a27,28
> Edit go.mod from tools or scripts
> Make go.mod semantically consistent
168c170
< 141 headings found
---
> 143 headings found
$
Fixes#26938.
Change-Id: I204fd982a60773aa26880cd19eed890c373b8ab6
Reviewed-on: https://go-review.googlesource.com/129677
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It's already half gone and later will be all gone.
It's not worth explaining in an introduction doc.
Fixes#24506
Updates #4719
Change-Id: Ie48128b3aa090d84e0e734aa45f14a4480292913
Reviewed-on: https://go-review.googlesource.com/129679
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is possible to write a function that seems to wrap a print/printf
call, but then doesn't. For example, if the string parameter we thought
was the format is used as another argument.
One option would be to make vet's print analysis smarter, to detect when
format strings are indeed used like we initially suspected.
However, I've opted for a simpler solution - check if the print/printf
call is already using more than one variadic argument, in which case
using an ellipsis in the last one would break the program:
// too many arguments in call to fmt.Printf
fmt.Printf(format, arg0, args...)
Fixes#26979.
Change-Id: I39371f1cec8483cfd2770a91670c1e80cbb9efdf
Reviewed-on: https://go-review.googlesource.com/129575
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Ranging through a map is non-deterministic and there can be duplicate
entries in the set (with the same name) which don't have identical
definitions in some cases.
Fixes#27013
Change-Id: I378c48bc359c10b25b9238e0c663b498455b19fd
Reviewed-on: https://go-review.googlesource.com/129515
Reviewed-by: Russ Cox <rsc@golang.org>
Added this locally but then broke the first rule of Gerrit
and clicked Submit instead of running "git submit".
Change-Id: I83c28d9151c566e9b2092e2613d67731a5d64beb
Reviewed-on: https://go-review.googlesource.com/129678
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
