Reportedly on some new Fedora systems the linker is producing extra
load segments, basically making the dynamic section non-executable.
We were assuming that the first load segment could be used to
determine the program's load offset, but that is no longer true.
Use the first executable load segment instead.
Fixes#26369
Change-Id: I5ee31ddeef2e8caeed3112edc5149065a6448456
Reviewed-on: https://go-review.googlesource.com/127895
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gcWriteBarrier and wbBufFlush assume that not writing to an argument
variable is sufficient to not clobber the corresponding argument slot.
This assumption lets us simplify the write barrier assembly code,
speed up the flush path, and reduce the stack usage of the write
barrier.
But it is an assumption, so this CL documents it to make this clear.
Alternatively, we could separate the register spill slots from the
argument slots in the write barrier, but that loses the advantages
above. On the other hand, it's extremely unlikely that we'll change
the behavior of the compiler to start clobbering argument slots (if
anything, we'd probably change it to *not* clobber argument slots even
if you wrote to the arguments).
Fixes#25512.
Change-Id: Ib2cf29c0d90956ca02b997ef6e7fa56fc8044efe
Reviewed-on: https://go-review.googlesource.com/127815
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"BFI $0, R1, $7, R2" is expected to copy bit 0~6 from R1 to R2, and
left R2's other bits unchanged.
But the assembler rejects it with error "illegal bit number", and
BFIW/SBFIZ/SBFIZW/UBFIZ/UBFIZW have the same problem.
This CL fixes that issue and adds corresponding test cases.
fixes#26736
Change-Id: Ie0090a0faa38a49dd9b096a0f435987849800b76
Reviewed-on: https://go-review.googlesource.com/127159
Run-TryBot: Ben Shi <powerman1st@163.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We were passing untrimmed paths to ModPackageModuleInfo, which was then failing
the build because it was asked to resolve an invalid path.
Fixes#26722
Change-Id: I043cc9c26f2188c5e005c0353620d9c55b339df9
Reviewed-on: https://go-review.googlesource.com/127795
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes tests on systems where ccache is the default compiler.
Also simplify a prior workaround for this fault.
Fixed#26789
Change-Id: I031ff0b65ace7fc5e284393298e004aa2ad3b6f5
Reviewed-on: https://go-review.googlesource.com/127775
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Test large but not infinite arguments.
This CL adds a test which breaks s390x. Don't submit until
a fix for that is figured out.
Update #26477
Change-Id: Ic86739fe3554e87d7f8e15482875c198fcf1d59c
Reviewed-on: https://go-review.googlesource.com/125641
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing implementation produces correct results with a wide range of inputs,
but invalid results asymptotically. With this change we ensure correct asymptotic results
on s390x
Fixes#26477
Change-Id: I760c1f8177f7cab2d7622ab9a926dfb1f8113b49
Reviewed-on: https://go-review.googlesource.com/127119
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Evaluating the symlinks was slowing down test cache checks.
Fixes#26562Fixes#26726
ijt:~/gopath/src/issue26562$ cat foo_test.go
package foo_test
import (
"fmt"
"os"
"path/filepath"
"testing"
)
// package and imports snipped
func TestCache(t *testing.T) {
tmp := os.TempDir()
for i := 0; i < 1000000; i++ {
os.Stat(filepath.Join(tmp, fmt.Sprintf("%d", i)))
}
}
ijt:~/gopath/src/issue26562$ time ~/github/go/bin/go test -count=1
PASS
ok issue26562 9.444s
real 0m10.021s
user 0m2.344s
sys 0m7.835s
ijt:~/gopath/src/issue26562$ time ~/github/go/bin/go test .
ok issue26562 (cached)
real 0m0.802s
user 0m0.551s
sys 0m0.306s
Change-Id: I3ce7f7b68bb5b9e802069f277e79e1ed3c162622
Reviewed-on: https://go-review.googlesource.com/127635
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This file is clearly a script test, not a module definition, but it's in the
wrong directory to be run as one.
Fortunately, it passes with only minor modifications (changing “..” to “.”).
Change-Id: I66a544dfde82b8348108d2596c74e174157ae297
Reviewed-on: https://go-review.googlesource.com/127615
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before CL 97795, when go/scanner saw a //line comment, it would clean
the path and, if the path was relative, prepend the directory from the
file name. This was not the best API because it meant that the
behavior changed based on whether the code was running on Windows or
not, and it meant that information from the //line directive was lost.
So in CL 97795, among other changes, go/scanner was changed to simply
return the filename given in the //line comment.
Unfortunately existing tools such as unparam and unconvert expected
the old behavior. In order to avoid breaking those tools, revert that
part of the change.
Fixes#26671
Change-Id: Ifa06542bd19cda9d682ac33766ab9080444ba050
Reviewed-on: https://go-review.googlesource.com/127658
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The interface between the wasm binary and wasm_exec.js is experimental
and likely to change in the future. Still, there are some early adopters
who experiment with non-web wasm runtimes. They can't use wasm_exec.js
and have to provide their own equivalent. Adding the Go version as a
custom wasm sections allows for them to support a stable Go version and
the latest devel at the same time.
Change-Id: I6d377bb0a0c33cb80e86dd15a34ddc9a70680227
Reviewed-on: https://go-review.googlesource.com/127597
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
They didn't even have public types, which made them pretty mysterious.
Give them types and reference the Decoder, which uses them.
Also, refer them qualified by their package name in the examples, as
we usually do in example*.go files, which usually use package foo_test
specifically so we can show the package names along with the symbols.
Change-Id: I50ebbbf43778c1627bfa526f8824f52c7953454f
Reviewed-on: https://go-review.googlesource.com/127663
Reviewed-by: Bryan C. Mills <bcmills@google.com>
os used to panic (access out of bounds) if executablePath was left empty
Fixes#22529
Change-Id: Iead5e60a3b000dbde421a8e8612c3690340879ce
Reviewed-on: https://go-review.googlesource.com/127546
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some combined store optimization was already implemented
in go-1.11, but there is no corresponding test cases.
Change-Id: Iebdad186e92047942e53a74f2c20b390922e1e9c
Reviewed-on: https://go-review.googlesource.com/122915
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When using the compiled .wasm with misc/wasm/wasm_exec.js, we get an error message if the site prohibits eval() via the Content-Security-Policy header. This can be resolved by moving the callback helper code from src/syscall/js/callback.go to misc/wasm/wasm_exec.js.
Fixes#26748
Change-Id: I28f271b8a00631f4c66a1ac31305e85f20f9d420
GitHub-Last-Rev: a6a0268f38
GitHub-Pull-Request: golang/go#26750
Reviewed-on: https://go-review.googlesource.com/127296
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The cgo tool predefines some C types such as C.uint. Don't give an
error if the type that cgo defines does not match the type in a header file.
Fixes#26743
Change-Id: I9ed3b4c482b558d8ffa8bf61eb3209415b7a9e3c
Reviewed-on: https://go-review.googlesource.com/127356
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The ! can show up when using ${SRCDIR} with uppercase letters in module names.
Fixes#26716
Change-Id: Ia474ed8ec40a88076e8aac21103f6c7bb3848bdb
Reviewed-on: https://go-review.googlesource.com/127297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The linux syscall functions used in runtime are designed around the calling
convention of returning errors as negative numbers. On some other systems
(like mips and ppc) the actual syscalls signal errors in other ways. This
means that the assembly implementations of the syscall functions on these
platforms need to transform the return values in the error cases to match
the expected negative errno values. This was addressed for certain syscalls
in https://golang.org/cl/19455 and https://golang.org/cl/89235. This patch
handles the rest of the syscall functions in sys_linux_*.s that return any
value for mips/mips64/ppc64.
Fixes#23446
Change-Id: I302100261231f76d5850ab2c2ea080170d7dba72
GitHub-Last-Rev: e358e2b08c
GitHub-Pull-Request: golang/go#26606
Reviewed-on: https://go-review.googlesource.com/125895
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Expanding __builtin types (__builtin_va_list, particularly) leads
to problems because they are expanded by the compiler itself - the
expansions are not generated by anything in a .h file. The types
a __builtin type expand to are thus very confusing to cgo.
See CL 126275.
Change-Id: I66eb6a4f27f652f1b934ba702f580f6daa62a566
Reviewed-on: https://go-review.googlesource.com/127156
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix the wording in "strconv" and "fmt" to make explicit
that the "g" and "G" formats remove trailing zeroes.
Fixes#25082
Change-Id: I2e2ad0a98d2ea27a3a8a006a0563b366f7a3b71b
Reviewed-on: https://go-review.googlesource.com/127135
Reviewed-by: Rob Pike <r@golang.org>
Previously, cmd/doc treated GOROOT/src and GOPATH/src
as the roots of the directory trees holding packages, assuming
that the import path would be the path elements after the src directory.
With modules, each module serves as its own root of a file tree,
and the import path prefix starts with the module path before
adding the path elements after the module root.
There are ways we could make this more efficient,
but for now this is a fairly small adjustment to get 'go doc'
working OK for modules for Go 1.11.
Fixes#26635.
Change-Id: Ifdee4194601312846c7b1fc67f2fe7a4a44269cc
Reviewed-on: https://go-review.googlesource.com/126799
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Using $GOPATH/src/mod confuses too many tools.
$GOPATH/pkg/mod seems better for now.
It's also next to dep's cache, $GOPATH/pkg/dep.
If we do eliminate GOPATH/pkg for holding .a files (#4719)
then we could still keep it around for pkg/mod.
(Or we could move the module cache again then.)
Fixes#26401.
Fixes#26635.
Change-Id: I18f7da216ed9f490eded3c00d837fb086ae5b6a4
Reviewed-on: https://go-review.googlesource.com/126755
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rob Pike <r@golang.org>
This is needed by golang.org/x/tools/go/packages
and also gives a way to do a quicker scan for
packages with a given final path element:
go list -find .../template
Change-Id: I092f4ac5ba7af7d727eb8204379fa436667061b9
Reviewed-on: https://go-review.googlesource.com/126716
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Relative directory paths have always worked.
This CL makes absolute directory paths be handled the same way.
(It was an oversight that they were excluded.)
It also fixes the case of naming the directory holding source code
for a package in a module dependency.
Fixes#14177.
Fixes#26550.
Change-Id: I29a0ca2795d35eca773121ee91a97628b56947ce
Reviewed-on: https://go-review.googlesource.com/126715
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The old -getmode flag had two settings:
-getmode=local meant don't download from the network.
-getmode=vendor meant only use the vendor directory.
The new -mod flag has two settings:
-mod=readonly means refuse to automatically update go.mod (mainly for CI testing).
-mod=vendor means only use the vendor directory.
The old GOPROXY variable had two settings:
a proxy URL or else the empty string (direct connect).
The new GOPROXY variable has three settings:
a proxy URL, the string "off" (no network use allowed),
or else the empty string or the explicit string "direct" (direct connection).
We anticipate allow a comma-separated sequence in a future release,
so commas are disallowed entirely right now.
Fixes#24666.
Fixes#26586.
Fixes#26370.
Fixes#26361.
Change-Id: If2601a16b09f04800f666938c071fc053b4c3f9c
Reviewed-on: https://go-review.googlesource.com/126696
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
People sometimes want to turn on a particular go command flag by default.
In Go 1.11 we have at least two different cases where users may need this.
1. Linking can be noticeably slower on underpowered systems
due to DWARF, and users may want to set -ldflags=-w by default.
2. For modules, some users or CI systems will want vendoring always,
so they want -getmode=vendor (soon to be -mod=vendor) by default.
This CL generalizes the problem to “set default flags for the go command.”
$GOFLAGS can be a space-separated list of flag settings, but each
space-separated entry in the list must be a standalone flag.
That is, you must do 'GOFLAGS=-ldflags=-w' not 'GOFLAGS=-ldflags -w'.
The latter would mean to pass -w to go commands that understand it
(if any do; if not, it's an error to mention it).
For #26074.
For #26318.
Fixes#26585.
Change-Id: I428f79c1fbfb9e41e54d199c68746405aed2319c
Reviewed-on: https://go-review.googlesource.com/126656
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
CL 108156 added -cgo during the Go 1.11 cycle.
To avoid adding a new field to Package, it redefined the
meaning of the CgoFiles list to be the cgo output instead
of the cgo input.
This was awkward in the go command itself, since the meaning
of the list changed midway through the build.
But, worse, it is awkward to users of go list.
When gathering information about a tree of packages,
we may want the names of both the cgo inputs and the cgo outputs
(golang.org/x/tools/go/packages does, it turns out),
or when combined with -deps (CL 107776),
we may only care about one list or the other depending
on whether the package was requested explicitly or is
being returned as a dependency.
Also, it's not general enough. SWIGFiles turn into cgo files
and then end up in the list too. And maybe there will be others
in the future. What clients really want is the list of files that
are presented to the go compiler, so that they can parse
and type-check them as if they were the compiler instead.
Eliminate all this awkwardness by dropping -cgo and adding
a new -compiled that populates a new CompiledGoFiles list.
Change-Id: I5f152da17cfb2692eedde61721d01ec13067c57d
Reviewed-on: https://go-review.googlesource.com/126695
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The current "go mod" command does too many things.
The design is unclear.
It looks like "everything you might want to do with modules"
which causes people to think all module operations go through
"go mod", which is the opposite of the seamless integration we're
going for. In particular too many people think "go mod -require"
and "go get" are the same.
It does make sense to put the module-specific functionality
under "go mod", but not as flags. Instead, split "go mod" into
multiple subcommands:
go mod edit # old go mod -require ...
go mod fix # old go mod -fix
go mod graph # old go mod -graph
go mod init # old go mod -init
go mod tidy # old go mod -sync
go mod vendor # old go mod -vendor
go mod verify # old go mod -verify
Splitting out the individual commands makes both the docs
and the implementations dramatically easier to read.
It simplifies the command lines
(go mod -init -module m is now 'go mod init m')
and allows command-specific flags.
We've avoided subcommands in the go command to date, and we
should continue to avoid adding them unless it really makes
the experience significantly better. In this case, it does.
Creating subcommands required some changes in the core
command-parsing and help logic to generalize from one
level to multiple levels.
As part of having "go mod init" be a separate command,
this CL changes the failure behavior during module initialization
to be delayed until modules are actually needed.
Initialization can still happen early, but the base.Fatalf
is delayed until something needs to use modules.
This fixes a bunch of commands like 'go env' that were
unhelpfully failing with GO111MODULE=on when not in a
module directory.
Fixes#26432.
Fixes#26581.
Fixes#26596.
Fixes#26639.
Change-Id: I868db0babe8c288e8af684b29d4a5ae4825d6407
Reviewed-on: https://go-review.googlesource.com/126655
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We aren't planning to use this or advertise it much yet,
but having support for it now will make it easier to start
using in the future - older go commands will understand
what 'go 1.20' means and that they don't have go 1.20.
Fixes#23969.
Change-Id: I729130b2690d3c0b794b49201526b53de5093c45
Reviewed-on: https://go-review.googlesource.com/125940
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Saves ~105KB of heap for callers who don't use html.UnescapeString.
(EscapeString is much more common).
Also saves 70KB of binary size, because now the linker can do dead
code elimination. (because #2559 is still open and global maps always
generate init code)
Fixes#26727
Updates #6853
Change-Id: I18fe9a273097e2c7e0cb7f88205cae1bb60fa89b
Reviewed-on: https://go-review.googlesource.com/127075
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Due to a new specification of //line: directives, missing
column info is now treated as column 0, aka "unknown column"
(see https://github.com/golang/go/issues/24183 for details).
As cgo does not add column number to generated //line: directive,
resulting files parsed do not have column info.
Fix by adding column of 1 to generated line directives.
Fixes#26692
Change-Id: Ie9263c0cf666b92d19c34240e745e8f32ffe7174
Reviewed-on: https://go-review.googlesource.com/126675
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ensure that we call FinishType on all the types added to the ptrs map.
We only add a key to ptrKeys once. Once we FinishType for that key,
we'll never look at that key again. But we can add a new type under that
key later, and we'll never finish it.
Make sure we add the key to the ptrKeys list every time we make the list
of types for that key non-empty.
This makes sure we FinishType each pointer type exactly once.
Fixes#26517
Change-Id: Iad86150d516fcfac167591daf5a26c38bec7d143
Reviewed-on: https://go-review.googlesource.com/126275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some of the arguments — particularly format strings passed to git commands — may
contain spaces, and it's useful to be able to paste commands from 'go get -x
foo' directly into a shell to reproduce their output.
Change-Id: I4f0c0b4e05db8b5232458e9a271f2ccbb665e85a
Reviewed-on: https://go-review.googlesource.com/126955
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
