as if it had a "vendor/" prefix. For example, within "crypto/tls",
an import of "golang.org/x/crypto/cryptobyte" resolves to
"vendor/golang.org/x/crypto/cryptobyte". When a package with the
same path is imported from a package outside std or cmd, it will
be resolved normally. Consequently, a binary may be built with two
copies of a package at different versions if the package is
imported normally and vendored by the standard library.

The next/ directory contains the only files intended to be mutated.
Each file in that directory contains a list of features that may be added
to the next release of Go. The files in this directory only affect the
warning output from the go api tool. Each file should be named
nnnnn.txt, after the issue number for the accepted proposal.
(The #nnnnn suffix must also appear at the end of each line in the file;

#### Binary Distributions

Official binary distributions are available at https://go.dev/dl/.

After downloading a binary release, visit https://go.dev/doc/install
for installation instructions.

#### Install From Source

If a binary distribution is not available for your combination of
operating system and architecture, visit
https://go.dev/doc/install/source
for source installation instructions.

### Contributing

/test/pass.out
/test/run.out
/test/times.out

# This file includes artifacts of Go build that should not be checked in.
# For files created by specific development environment (e.g. editor),
# use alternative ways to exclude files from git.

	[CL 6789](/cl/6789)                # Gerrit changelists

## For the release team

At the start of a release development cycle, the contents of `next` should be deleted
and replaced with those of `initial`. From the repo root:

    > cd doc
    > rm -r next/*
    > cp -r initial/* next

Then edit `next/1-intro.md` to refer to the next version.

counts the number of HTTP transports that the program
has configured without HTTP/2 support.

## Default GODEBUG Values {#default}

When a GODEBUG setting is not listed in the environment variable,
its value is derived from three sources:
the defaults for the Go toolchain used to build the program,
amended to match the Go version listed in `go.mod`,
and then overridden by explicit `//go:debug` lines in the program.

canonicalizing values (like "interning" or "hash-consing").

Any value of comparable type may be canonicalized with the new
`Make[T]` function, which produces a reference to a canonical copy of
the value in the form of a `Handle[T]`.
Two `Handle[T]` are equal if and only if the values used to produce the
handles are equal, allowing programs to deduplicate values and reduce
their memory footprint.

pkg syscall (windows-386), const FORMAT_MESSAGE_ARGUMENT_ARRAY = 8192
pkg syscall (windows-386), const FORMAT_MESSAGE_FROM_HMODULE = 2048
pkg syscall (windows-386), const FORMAT_MESSAGE_FROM_STRING = 1024
pkg syscall (windows-386), const FORMAT_MESSAGE_FROM_SYSTEM = 4096
pkg syscall (windows-386), const FORMAT_MESSAGE_IGNORE_INSERTS = 512
pkg syscall (windows-386), const FORMAT_MESSAGE_MAX_WIDTH_MASK = 255

Android
=======

For details on developing Go for Android, see the documentation in the
mobile subrepository:

	https://github.com/golang/mobile

To run the standard library tests, enable Cgo and use an appropriate
C compiler from the Android NDK. For example,

	CGO_ENABLED=1 \
	GOOS=android \
	GOARCH=arm64 \
	CC_FOR_TARGET=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang \
	./all.bash

## Compiler {#compiler}

The build time overhead to building with [Profile Guided Optimization](/doc/pgo) has been reduced significantly.
Previously, large builds could see 100%+ build time increase from enabling PGO.
In Go 1.23, overhead should be in the single digit percentages.

## Assembler {#assembler}