84fbdf01ff
This is the final CL in the series adding PGO preprocessing support to cmd/go. Now that the tool is hooked up, we integrate with the build cache to cache the result. This is fairly straightforward. One difference is that the compile and link do caching through updateBuildID. However, preprocessed PGO files don't have a build ID, so it doesn't make much sense to hack our way through that function when it is simple to just add to the cache ourselves. As as aside, we could add a build ID to the preproccessed file format, though it is not clear if it is worthwhile. The one place a build ID could be used is in buildActionID, which currently compute the file hash of the preprocessed profile. With a build ID it could simply read the build ID. This would save one complete read of the file per build (cmd/go caches the hash), but each compile process also reads the entire file, so this is a small change overall. Fixes #58102. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I86e2999a08ccd264230fbb1c983192259b7288e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/569425 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> |
||
|---|---|---|
| .. | ||
| initial | ||
| next | ||
| asm.html | ||
| go1.17_spec.html | ||
| go_mem.html | ||
| go_spec.html | ||
| godebug.md | ||
| README.md | ||
Release Notes
The initial and next subdirectories of this directory are for release notes.
For developers
Release notes should be added to next by editing existing files or creating new files.
At the end of the development cycle, the files will be merged by being concatenated in sorted order by pathname. Files in the directory matching the glob "*stdlib/*minor" are treated specially. They should be in subdirectories corresponding to standard library package paths, and headings for those package paths will be generated automatically.
Files in this repo's api/next directory must have corresponding files in
doc/next/*stdlib/*minor.
The files should be in the subdirectory for the package with the new
API, and should be named after the issue number of the API proposal.
For example, if the directory 6-stdlib/99-minor is present,
then an api/next file with the line
pkg net/http, function F #12345
should have a corresponding file named doc/next/6-stdlib/99-minor/net/http/12345.md.
At a minimum, that file should contain either a full sentence or a TODO,
ideally referring to a person with the responsibility to complete the note.
Use the following forms in your markdown:
[http.Request] # symbol documentation; auto-linked as in Go doc strings
[#12345](/issue/12345) # GitHub issues
[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.
To prepare the release notes for a release, run golang.org/x/build/cmd/relnote generate.
That will merge the .md files in next into a single file.