Filippo Valsorda [Tue, 21 Aug 2018 20:50:04 +0000 (14:50 -0600)]
[release-branch.go1.11] crypto/tls: make ConnectionState.ExportKeyingMaterial a method
The unexported field is hidden from reflect based marshalers, which
would break otherwise. Also, make it return an error, as there are
multiple reasons it might fail.
Russ Cox [Sat, 18 Aug 2018 18:16:26 +0000 (14:16 -0400)]
[release-branch.go1.11] cmd/go: add go.sum entries to go mod download -json output
Clients of 'go mod download', particularly proxies, may need
the hashes of the content they downloaded, for checking against
go.sum entries or recording elsewhere.
Change-Id: Ic36c882cefc540678e1bc5a3dae1e865d181aa69
Reviewed-on: https://go-review.googlesource.com/129802
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 46033d7639cb1399029b99bb0cdc53d2b8f4bd08)
Reviewed-on: https://go-review.googlesource.com/130615
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is possible to enter the parent-walking directory loop in a way that
it will loop forever - if mdir is empty, and d reaches ".". To avoid
this, make sure that the 'd = filepath.Dir(d)' step only happens if the
parent directory is actually different than the current directory.
This fixes some of the tests like TestImport/golang.org_x_net_context,
which were never finishing before.
While at it, also fix TestImport/golang.org_x_net, which seems to have
the wrong expected error. The root of the x/net repo doesn't have a
go.mod file, nor is part of a module itself, so it seems like the
expected error should reflect that.
After these two changes, 'go test cmd/go/internal/modload' passes on my
linux/amd64 machine.
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.
Russ Cox [Sat, 18 Aug 2018 02:32:22 +0000 (22:32 -0400)]
cmd/go: allow 'go run x.go' to use nearby internal imports in module mode
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.
Russ Cox [Sat, 18 Aug 2018 01:25:52 +0000 (21:25 -0400)]
cmd/go: fix and reenable TestAccidentalGitCheckout
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.
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.
Russ Cox [Fri, 17 Aug 2018 19:40:55 +0000 (15:40 -0400)]
cmd/go: treat VCS errors as hard errors in module search
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
$
Russ Cox [Fri, 17 Aug 2018 18:47:31 +0000 (14:47 -0400)]
cmd/go: remove go mod fix, add go help go.mod
"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".
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.
Russ Cox [Fri, 10 Aug 2018 20:28:48 +0000 (16:28 -0400)]
cmd/go: do not turn list ./nonexist into a network lookup
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.
Russ Cox [Fri, 17 Aug 2018 16:40:18 +0000 (12:40 -0400)]
cmd/go: report which patterns match each package in list
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.
Russ Cox [Fri, 10 Aug 2018 04:01:48 +0000 (00:01 -0400)]
cmd/go: fix -gcflags, -ldflags not applying to current directory
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.
Russ Cox [Fri, 10 Aug 2018 17:26:32 +0000 (13:26 -0400)]
cmd/go: distinguish patterns from the results of matching them
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.
Daniel Martí [Thu, 16 Aug 2018 13:39:13 +0000 (14:39 +0100)]
cmd/vet: don't suggest ... if it breaks a program
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...)
Dan Johnson [Wed, 15 Aug 2018 23:48:44 +0000 (16:48 -0700)]
cmd/compile: make duplicate anonymous interface output deterministic
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.
Russ Cox [Sat, 11 Aug 2018 00:05:44 +0000 (20:05 -0400)]
cmd/go: ignore import "C" files in module loader in non-cgo mode
Obviously, including files that import "C" when cgo is disabled is wrong.
The package load step correctly excludes them and finds no files at all,
which then causes a failure.
Fixes #26927.
Change-Id: I00e6d6450e783d467d20bde99e91240ecb0db837
Reviewed-on: https://go-review.googlesource.com/129062
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: David du Colombier <0intro@gmail.com>
Russ Cox [Sat, 11 Aug 2018 00:22:21 +0000 (20:22 -0400)]
cmd/go: ignore /tmp/go.mod
Two different people have created /tmp/go.mod for experimentation
and then had other tests that create fresh work directories
below /tmp fail unexpectedly because the go command finds
/tmp/go.mod. Refuse to use /tmp/go.mod. /tmp/anything/go.mod is fine.
The change, while addressing issue #26352, introduced another
regression (#26930), which is worse. Reverting this change in
favor of a better fix for the original issue.
Updates #26352.
Fixes #26930.
Change-Id: I71ad12a8212992cce5c1e73907d1f7460f98d9e8
Reviewed-on: https://go-review.googlesource.com/129255
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Richard Musiol [Sun, 5 Aug 2018 16:52:15 +0000 (18:52 +0200)]
cmd/compile/internal/gc: add nil check for closure call on wasm
This commit adds an explicit nil check for closure calls on wasm,
so calling a nil func causes a proper panic instead of crashing on the
WebAssembly level.
Johan Brandhorst [Fri, 3 Aug 2018 14:48:16 +0000 (14:48 +0000)]
net/http: support configuring fetch options
The default WASM RoundTripper is implemented using
the browser Fetch API. Some options don't readily map to
existing http.Request options, so we use the precedent
set by the TrailerPrefix constant to allow a user to configure
the "mode" and "credentials" options by supplying them
as headers in the http.Request.
Russ Cox [Fri, 10 Aug 2018 03:44:43 +0000 (23:44 -0400)]
cmd/go: report implicit cgo inputs in go list -compiled
Tools using go list -compiled expect to see an Imports list
that includes all the imports in CompiledGoFiles.
Make sure the list includes the cgo-generated imports.
Russ Cox [Fri, 10 Aug 2018 03:17:45 +0000 (23:17 -0400)]
cmd/go: do not try to understand git fetch --depth=1 errors
We used to try a git fetch --depth=1 of a specific hash and
distinguish between an error meaning
"that's not a hash I can give you directly"
(in which case we fall through and pull the whole repo)
and some other error like connection failure, bad ssh key
(in which case we give up).
We've had repeated problems trying to understand the
error meanings so just stop doing that, and fall back to
trying a full fetch on any error at all. If the error really
was some kind of network or auth or i/o problem, then
it will happen the second time and we can report it then.
Russ Cox [Fri, 10 Aug 2018 01:08:24 +0000 (21:08 -0400)]
cmd/go: display cached compiler output more often
CL 77110 arranged for caching and redisplaying compiler output
when reusing a compile artifact from the build cache.
It neglected to redisplay compiler and linker output when avoiding
the compile and link steps by reusing the target output binary
as a cached result. It also neglected to redisplay compiler and linker
output when avoiding the compile and link (and test) steps by reusing
cached test output.
This CL brings back the compiler and linker output in those two cases,
provided it can be found in the build cache. If it can't be found in the
build cache, then the go command still reuses the binaries and avoids
the compile/link/test steps. (It's not worth doing all that work again
just to repeat diagnostic output.)
Russ Cox [Thu, 9 Aug 2018 20:36:48 +0000 (16:36 -0400)]
cmd/go: fix install target name for versioned binaries
For a package in the module root, using the containing directory name
might mean the directory in the module cache, in which case the
executable has a final @v1.2.3 in it, which is no good. Fix that.
While we're here, change go install example.com/cmd/foo/v2 to
install foo instead of the less useful "v2".
Fixes #24667.
Fixes #26869.
Change-Id: Ie40ca1bc9e27955441f1cdb7abd3a1f69034c9f5
Reviewed-on: https://go-review.googlesource.com/128900 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Russ Cox [Tue, 7 Aug 2018 19:50:24 +0000 (15:50 -0400)]
cmd/go: fix module loader and test-only dependencies
go list all was not behaving as documented - it did not pick up
test dependencies except when running in "go test" and "go vet".
It should pick them up always.
Also the module loader was ignoring tests when using "go list -test",
which led to load failures.
Fixing all required adjustments to mod_patterns test.
Removed error-prone exact listings.
Fixes #26279.
Fixes #26906.
Change-Id: I9c5acaf2275be20fd2349859589502190d3e7a78
Reviewed-on: https://go-review.googlesource.com/128358 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Suzy Mueller [Thu, 9 Aug 2018 17:05:54 +0000 (13:05 -0400)]
cmd/go: make 'go list -test' report the correct import path
When a test variant of a package is created, the two versions cannot
share memory for the fields that contain information about their
imports, as these will be different between the two packagse.
Both the Internal.Imports and the Imports fields must be able to be
updated in the test variant without affecting the values of the
original.
David Chase [Wed, 18 Jul 2018 20:18:28 +0000 (16:18 -0400)]
cmd/compile: update delve's reference data for ssa/debug_test
Recent versions of Delve pay attention to the debugging changes
for 1.11, which causes different (better!) debugging behavior.
Update the reference data to reflect this.
Change-Id: I2efa165aa71769ace9f7885b4ce3420cd9b2d3a3
Reviewed-on: https://go-review.googlesource.com/128697
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Thu, 9 Aug 2018 21:38:32 +0000 (17:38 -0400)]
cmd/go: skip TestScript/mod_patterns on nocgo builders
Updates #26906.
Change-Id: I61b08180aefe9cfc109a1009ca251ee6970eb2df
Reviewed-on: https://go-review.googlesource.com/128879
Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Mon, 6 Aug 2018 20:59:31 +0000 (16:59 -0400)]
cmd/go/internal: factor out modload.QueryPackage and use in in modget
modload.Import contains a loop that looks for the module containing a package.
Because we overload Import to locate both packages and modules, that loop
contains a bunch of special-cases for modules with empty roots.
In this change, we factor out the loop into a new function (QueryPackage) and
use that directly in modget.getQuery. That restores the invariant that
the paths passed to modload.Import must be importable packages, and fixes 'go
get' lookups for packages that have moved between a module and submodules with
the same path prefix.
Bryan C. Mills [Mon, 6 Aug 2018 21:25:10 +0000 (17:25 -0400)]
cmd/go/internal/modload: report errors explicitly from Lookup
Previously, we reported errors directly in (*loader).load via base.Errorf.
Unfortunately, (*loader).load can be called from contexts in which such errors
should not be considered fatal, such as by load.PackagesAndErrors.
Instead, we save the errors in pkg.err and modify Lookup to return that error.
This change is a bit awkward: we end up suppressing a "no Go files" error for
packages at the root of newly-imported modules, even if they really do contain
source files. I believe that that's due to a special-case lookup for modules in
the build list, which allows us to "validate" imports for modules in the build
list even though we haven't actually downloaded their sources (or verified that
they actually contain the requested package). The fix for that issue is in the
change that follows this one.
Rebecca Stambler [Thu, 9 Aug 2018 16:34:19 +0000 (12:34 -0400)]
go/types: fix errors in recording type information
In my previous change, I didn't use the correct functions for continuing
to record type informations after errors. Change to using the correct
functions, and add a comment to clarify in expr.go.
Updates #22467
Change-Id: I66ebb636ceb2b994db652343430f0551db0050c3
Reviewed-on: https://go-review.googlesource.com/128835
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Bryan C. Mills [Mon, 6 Aug 2018 22:06:06 +0000 (18:06 -0400)]
cmd/go: test that 'go get pkg@version' installs pkg
This test passes, but it encodes several behaviors that I think are bugs.
I suggest that we check it in as-is, and we can update it as the bugs are fixed.
Mostyn Bramley-Moore [Wed, 8 Aug 2018 21:34:43 +0000 (21:34 +0000)]
doc.Example should not worry about unresolved blank identifiers
https://golang.org/pkg/bufio/#example_Scanner_custom is not directly
runnable in the playground via godoc, but if I copy+paste the code into
https://play.golang.org/ then it runs just fine.
This seems to be due to the blank identifier being considered unresolved
in the following line in the example:
_, err = strconv.ParseInt(string(token), 10, 32)
But that's the whole point of blank identifiers- they're not supposed
to be resolved. So let's skip adding the blank identifier to
doc.playExample's unresolved map.
Leigh McCulloch [Sat, 4 Aug 2018 06:40:45 +0000 (06:40 +0000)]
doc/contribute: add examples for finding issues on the issue tracker
For contributors looking for new issues to contribute to it can be
difficult to find issues that need a fix and don't already have a fix
being considered. There are several labels that help guide the way
already, like `NeedsFix`, `HelpWanted`. But many issues with this label
will already have a CL. For new contributors this can be especially
difficult.
Fixes #26494
Change-Id: Ifd38ea65e362b4c580207a06f959646e49ac594f
GitHub-Last-Rev: 6d2b54447b2ee754a6d025f5de3ebd8326e035eb
GitHub-Pull-Request: golang/go#26516
Reviewed-on: https://go-review.googlesource.com/125355 Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Robert Griesemer [Wed, 8 Aug 2018 00:53:59 +0000 (17:53 -0700)]
go/types: if base type for an alias is known, use it when needed
Because methods are type-checked before the receiver base type
is "complete" (i.e., they are checked as part of the receiver
base type), situations occur where aliases of those base types
are used (in those methods) but the alias types are not known
yet (even though their base types are known).
This fix is a temporary work-around that looks syntactically
for the base types of alias types and uses those base types
when we refer to an "incomplete" alias type. The work-around
is completely localized and guarded with a flag so it can be
disabled at short notice.
The correct fix (slated for 1.12) is to decouple type-checking
of methods from their receiver base types. See issue #26854.
Fixes #26390.
Change-Id: I66cc9d834b220c254ac00e671a137cf8a3da59c1
Reviewed-on: https://go-review.googlesource.com/128435 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Daniel Martí [Wed, 8 Aug 2018 12:53:10 +0000 (13:53 +0100)]
net: reduce TestSplice/big's memory usage
The old code used splice on a 2GB []byte when not in short mode, meaning
that running 'go test net' when one had 4GB or less free memory would
easily result in "out of memory" runtime panics.
Instead, use a much smaller size that is still big enough to not fit
into a single splice(2) syscall. The new size is just 5MB, so the test
uses a fraction of the memory it used to, and there's no longer a need
for a different size on short mode.
This also speeds up the test, which goes from ~1.23s to ~0.01s on my
laptop.
Fixes #26867.
Change-Id: Iae1daa5c0995b549f41992f44339be32ca1ee5e4
Reviewed-on: https://go-review.googlesource.com/128535
Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Andrei Tudor Călin <mail@acln.ro> Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Gn Shivakumar [Sun, 29 Jul 2018 17:56:52 +0000 (23:26 +0530)]
cmd/go: 3 cmd/go tests (>8s) made as non-short scripts
* TestAtomicCoverpkgAll -> Script/cover_atomic_pkgall.txt and make it
* non-short
* TestCoverpkgAllRuntime -> Script/cover_pkgall_runtime.txt and make it
* non-short
* TestCpuprofileTwice -> Script/cpu_profile_twice.txt and make it
* non-short
* TestGoTestMainTwice -> make it non-short
Updates #26472
Change-Id: I24f3d4c2a8b6e317adb369a1b1426e693f9571ed
Reviewed-on: https://go-review.googlesource.com/126636 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Bryan C. Mills [Wed, 1 Aug 2018 17:22:02 +0000 (13:22 -0400)]
cmd/go: make 'go get <module>@none' idempotent
Before this change, 'go get <module>@none' for a module not in the build list
would add the module to go.mod (with the explicit version string "none").
Subsequent go commands would fail with 'invalid module version "none"'.
Bryan C. Mills [Fri, 3 Aug 2018 17:43:17 +0000 (13:43 -0400)]
cmd/go/internal/load: pass the importer's package path when checking visibility
A module like "gopkg.in/macaroon.v2" might have a test with a "_test" package
suffix (see https://golang.org/cmd/go/#hdr-Test_packages).
When we compile that test, its ImportStack entry includes the "_test" suffix
even though nothing else can actually import it via that path.
When we look up the module containing such a package, we must use the original
path, not the suffixed one.
On the other hand, an actual importable package may also be named with the
suffix "_test", so we need to be careful not to strip the suffix if it is
legitimately part of the path. We cannot distinguish that case by examining
srcDir or the ImportStack: the srcDir contaning a module doesn't necessarily
bear any relationship to its import path, and the ImportStack doesn't tell us
whether the suffix is part of the original path.
Fortunately, LoadImport usually has more information that we can use: it
receives a parent *Package that includes the original import path.
Richard Musiol [Tue, 31 Jul 2018 13:12:57 +0000 (15:12 +0200)]
syscall/js: extend ValueOf to support arrays and objects
This commits adds []interface{} and map[string]interface{} as quick
ways to create JavaScript arrays and objects. They correspond to the
JavaScript notations [...] and {...}. A type alias can be used for
a concise notation.
GIT_TRACE write message to stderr, while run1 merge both stdout and
stderr. So function which call run1 and rely on its output will failed
to parse the result when run1 success.
By using cmd.Output(), we ensure only cmd standard out is returned.
Fixes #19682
Change-Id: I7002df17fe68aea1860ddc7382c68cc23548bd90
Reviewed-on: https://go-review.googlesource.com/126735 Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Fri, 3 Aug 2018 21:52:54 +0000 (14:52 -0700)]
cmd/internal/objfile: only consider executable segments for load address
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>
Austin Clements [Fri, 3 Aug 2018 15:34:11 +0000 (11:34 -0400)]
runtime: document assumption about wbBufFlush argument slots
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).