[dev.link] Merge branch 'master' into dev.link

2 conflicts, that make sense.
	src/cmd/internal/obj/objfile.go
	src/cmd/link/internal/loader/loader.go

Change-Id: Ib224e2d248cb568fa1e888af79dd908b2f5e05ff

1 files changed, 90 insertions, 58 deletions

diff --git a/src/cmd/go/alldocs.go b/src/cmd/go/alldocs.go
index 8ad4f66d09..4bc87008ff 100644
--- a/src/cmd/go/alldocs.go
+++ b/src/cmd/go/alldocs.go
@@ -93,8 +93,9 @@
 //
 // The -o flag forces build to write the resulting executable or object
 // to the named output file or directory, instead of the default behavior described
-// in the last two paragraphs. If the named output is a directory that exists,
-// then any resulting executables will be written to that directory.
+// in the last two paragraphs. If the named output is an existing directory or
+// ends with a slash or backslash, then any resulting executables
+// will be written to that directory.
 //
 // The -i flag installs the packages that are dependencies of the target.
 //
@@ -661,9 +662,12 @@
 // this automatically as well.
 //
 // The -insecure flag permits fetching from repositories and resolving
-// custom domains using insecure schemes such as HTTP. Use with caution. The
-// GOINSECURE environment variable is usually a better alternative, since it
-// provides control over which modules may be retrieved using an insecure scheme.
+// custom domains using insecure schemes such as HTTP. Use with caution.
+// This flag is deprecated and will be removed in a future version of go.
+// The GOINSECURE environment variable is usually a better alternative, since
+// it provides control over which modules may be retrieved using an insecure
+// scheme. It should be noted that the -insecure flag also turns the module
+// checksum validation off. GOINSECURE does not do that, use GONOSUMDB.
 // See 'go help environment' for details.
 //
 // The second step is to download (if needed), build, and install
@@ -715,6 +719,33 @@
 // environment variable is not set. Executables in $GOROOT
 // are installed in $GOROOT/bin or $GOTOOLDIR instead of $GOBIN.
 //
+// If the arguments have version suffixes (like @latest or @v1.0.0), "go install"
+// builds packages in module-aware mode, ignoring the go.mod file in the current
+// directory or any parent directory, if there is one. This is useful for
+// installing executables without affecting the dependencies of the main module.
+// To eliminate ambiguity about which module versions are used in the build, the
+// arguments must satisfy the following constraints:
+//
+// - Arguments must be package paths or package patterns (with "..." wildcards).
+//   They must not be standard packages (like fmt), meta-patterns (std, cmd,
+//   all), or relative or absolute file paths.
+// - All arguments must have the same version suffix. Different queries are not
+//   allowed, even if they refer to the same version.
+// - All arguments must refer to packages in the same module at the same version.
+// - No module is considered the "main" module. If the module containing
+//   packages named on the command line has a go.mod file, it must not contain
+//   directives (replace and exclude) that would cause it to be interpreted
+//   differently than if it were the main module. The module must not require
+//   a higher version of itself.
+// - Package path arguments must refer to main packages. Pattern arguments
+//   will only match main packages.
+//
+// If the arguments don't have version suffixes, "go install" may run in
+// module-aware mode or GOPATH mode, depending on the GO111MODULE environment
+// variable and the presence of a go.mod file. See 'go help modules' for details.
+// If module-aware mode is enabled, "go install" runs in the context of the main
+// module.
+//
 // When module-aware mode is disabled, other packages are installed in the
 // directory $GOPATH/pkg/$GOOS_$GOARCH. When module-aware mode is enabled,
 // other packages are built and cached but not installed.
@@ -1200,7 +1231,7 @@
 //
 // Usage:
 //
-// 	go mod tidy [-v]
+// 	go mod tidy [-e] [-v]
 //
 // Tidy makes sure go.mod matches the source code in the module.
 // It adds any missing modules necessary to build the current module's
@@ -1211,12 +1242,15 @@
 // The -v flag causes tidy to print information about removed modules
 // to standard error.
 //
+// The -e flag causes tidy to attempt to proceed despite errors
+// encountered while loading packages.
+//
 //
 // Make vendored copy of dependencies
 //
 // Usage:
 //
-// 	go mod vendor [-v]
+// 	go mod vendor [-e] [-v]
 //
 // Vendor resets the main module's vendor directory to include all packages
 // needed to build and test all the main module's packages.
@@ -1225,6 +1259,9 @@
 // The -v flag causes vendor to print the names of vendored
 // modules and packages to standard error.
 //
+// The -e flag causes vendor to attempt to proceed despite errors
+// encountered while loading packages.
+//
 //
 // Verify dependencies have expected content
 //
@@ -1571,6 +1608,9 @@
 // Using GOOS=illumos matches build tags and files as for GOOS=solaris
 // in addition to illumos tags and files.
 //
+// Using GOOS=ios matches build tags and files as for GOOS=darwin
+// in addition to ios tags and files.
+//
 // To keep a file from being considered for the build:
 //
 // 	// +build ignore
@@ -2172,10 +2212,11 @@
 // before resolving dependencies or building the code.
 //
 // The -insecure flag permits fetching from repositories and resolving
-// custom domains using insecure schemes such as HTTP. Use with caution. The
-// GOINSECURE environment variable is usually a better alternative, since it
-// provides control over which modules may be retrieved using an insecure scheme.
-// See 'go help environment' for details.
+// custom domains using insecure schemes such as HTTP. Use with caution.
+// This flag is deprecated and will be removed in a future version of go.
+// The GOINSECURE environment variable is usually a better alternative, since
+// it provides control over which modules may be retrieved using an insecure
+// scheme. See 'go help environment' for details.
 //
 // The -t flag instructs get to also download the packages required to build
 // the tests for the specified packages.
@@ -2586,72 +2627,63 @@
 //
 // Maintaining module requirements
 //
-// The go.mod file is meant to be readable and editable by both
-// programmers and tools. The go command itself automatically updates the go.mod file
-// to maintain a standard formatting and the accuracy of require statements.
-//
-// Any go command that finds an unfamiliar import will look up the module
-// containing that import and add the latest version of that module
-// to go.mod automatically. In most cases, therefore, it suffices to
-// add an import to source code and run 'go build', 'go test', or even 'go list':
-// as part of analyzing the package, the go command will discover
-// and resolve the import and update the go.mod file.
-//
-// Any go command can determine that a module requirement is
-// missing and must be added, even when considering only a single
-// package from the module. On the other hand, determining that a module requirement
-// is no longer necessary and can be deleted requires a full view of
-// all packages in the module, across all possible build configurations
-// (architectures, operating systems, build tags, and so on).
-// The 'go mod tidy' command builds that view and then
-// adds any missing module requirements and removes unnecessary ones.
+// The go.mod file is meant to be readable and editable by both programmers and
+// tools. Most updates to dependencies can be performed using "go get" and
+// "go mod tidy". Other module-aware build commands may be invoked using the
+// -mod=mod flag to automatically add missing requirements and fix inconsistencies.
+//
+// The "go get" command updates go.mod to change the module versions used in a
+// build. An upgrade of one module may imply upgrading others, and similarly a
+// downgrade of one module may imply downgrading others. The "go get" command
+// makes these implied changes as well. See "go help module-get".
+//
+// The "go mod" command provides other functionality for use in maintaining
+// and understanding modules and go.mod files. See "go help mod", particularly
+// "go help mod tidy" and "go help mod edit".
 //
 // As part of maintaining the require statements in go.mod, the go command
 // tracks which ones provide packages imported directly by the current module
 // and which ones provide packages only used indirectly by other module
 // dependencies. Requirements needed only for indirect uses are marked with a
-// "// indirect" comment in the go.mod file. Indirect requirements are
+// "// indirect" comment in the go.mod file. Indirect requirements may be
 // automatically removed from the go.mod file once they are implied by other
 // direct requirements. Indirect requirements only arise when using modules
 // that fail to state some of their own dependencies or when explicitly
 // upgrading a module's dependencies ahead of its own stated requirements.
 //
-// Because of this automatic maintenance, the information in go.mod is an
-// up-to-date, readable description of the build.
-//
-// The 'go get' command updates go.mod to change the module versions used in a
-// build. An upgrade of one module may imply upgrading others, and similarly a
-// downgrade of one module may imply downgrading others. The 'go get' command
-// makes these implied changes as well. If go.mod is edited directly, commands
-// like 'go build' or 'go list' will assume that an upgrade is intended and
-// automatically make any implied upgrades and update go.mod to reflect them.
-//
-// The 'go mod' command provides other functionality for use in maintaining
-// and understanding modules and go.mod files. See 'go help mod'.
-//
-// The -mod build flag provides additional control over updating and use of go.mod.
-//
-// If invoked with -mod=readonly, the go command is disallowed from the implicit
-// automatic updating of go.mod described above. Instead, it fails when any changes
-// to go.mod are needed. This setting is most useful to check that go.mod does
-// not need updates, such as in a continuous integration and testing system.
-// The "go get" command remains permitted to update go.mod even with -mod=readonly,
-// and the "go mod" commands do not take the -mod flag (or any other build flags).
+// The -mod build flag provides additional control over the updating and use of
+// go.mod for commands that build packages like "go build" and "go test".
+//
+// If invoked with -mod=readonly (the default in most situations), the go command
+// reports an error if a package named on the command line or an imported package
+// is not provided by any module in the build list computed from the main module's
+// requirements. The go command also reports an error if a module's checksum is
+// missing from go.sum (see Module downloading and verification). Either go.mod or
+// go.sum must be updated in these situations.
+//
+// If invoked with -mod=mod, the go command automatically updates go.mod and
+// go.sum, fixing inconsistencies and adding missing requirements and checksums
+// as needed. If the go command finds an unfamiliar import, it looks up the
+// module containing that import and adds a requirement for the latest version
+// of that module to go.mod. In most cases, therefore, one may add an import to
+// source code and run "go build", "go test", or even "go list" with -mod=mod:
+// as part of analyzing the package, the go command will resolve the import and
+// update the go.mod file.
 //
 // If invoked with -mod=vendor, the go command loads packages from the main
 // module's vendor directory instead of downloading modules to and loading packages
 // from the module cache. The go command assumes the vendor directory holds
 // correct copies of dependencies, and it does not compute the set of required
 // module versions from go.mod files. However, the go command does check that
-// vendor/modules.txt (generated by 'go mod vendor') contains metadata consistent
+// vendor/modules.txt (generated by "go mod vendor") contains metadata consistent
 // with go.mod.
 //
-// If invoked with -mod=mod, the go command loads modules from the module cache
-// even if there is a vendor directory present.
+// If the go command is not invoked with a -mod flag, and the vendor directory
+// is present, and the "go" version in go.mod is 1.14 or higher, the go command
+// will act as if it were invoked with -mod=vendor. Otherwise, the -mod flag
+// defaults to -mod=readonly.
 //
-// If the go command is not invoked with a -mod flag and the vendor directory
-// is present and the "go" version in go.mod is 1.14 or higher, the go command
-// will act as if it were invoked with -mod=vendor.
+// Note that neither "go get" nor the "go mod" subcommands accept the -mod flag.
 //
 // Pseudo-versions
 //