all: format code according to Go 1.19 rules

Go 1.19 started reformatting code in a way that makes it more obvious
how it will be rendered on pkg.go.dev. It gets it almost right, but not
entirely. Therefore, I had to modify some of the comments so that they
are formatted correctly.

builder/cc.go

@@ -33,29 +33,29 @@ import (
 // Because of this complexity, every file has in fact two cached build outputs:
 // the file itself, and the list of dependencies. Its operation is as follows:
 //
-//   depfile = hash(path, compiler, cflags, ...)
-//   if depfile exists:
-//     outfile = hash of all files and depfile name
-//     if outfile exists:
-//       # cache hit
-//       return outfile
-//   # cache miss
-//   tmpfile = compile file
-//   read dependencies (side effect of compile)
-//   write depfile
-//   outfile = hash of all files and depfile name
-//   rename tmpfile to outfile
+//	depfile = hash(path, compiler, cflags, ...)
+//	if depfile exists:
+//	  outfile = hash of all files and depfile name
+//	  if outfile exists:
+//	    # cache hit
+//	    return outfile
+//	# cache miss
+//	tmpfile = compile file
+//	read dependencies (side effect of compile)
+//	write depfile
+//	outfile = hash of all files and depfile name
+//	rename tmpfile to outfile
 //
 // There are a few edge cases that are not handled:
-// - If a file is added to an include path, that file may be included instead of
-//   some other file. This would be fixed by also including lookup failures in the
-//   dependencies file, but I'm not aware of a compiler which does that.
-// - The Makefile syntax that compilers output has issues, see readDepFile for
-//   details.
-// - A header file may be changed to add/remove an include. This invalidates the
-//   depfile but without invalidating its name. For this reason, the depfile is
-//   written on each new compilation (even when it seems unnecessary). However, it
-//   could in rare cases lead to a stale file fetched from the cache.
+//   - If a file is added to an include path, that file may be included instead of
+//     some other file. This would be fixed by also including lookup failures in the
+//     dependencies file, but I'm not aware of a compiler which does that.
+//   - The Makefile syntax that compilers output has issues, see readDepFile for
+//     details.
+//   - A header file may be changed to add/remove an include. This invalidates the
+//     depfile but without invalidating its name. For this reason, the depfile is
+//     written on each new compilation (even when it seems unnecessary). However, it
+//     could in rare cases lead to a stale file fetched from the cache.
 func compileAndCacheCFile(abspath, tmpdir string, cflags []string, thinlto bool, printCommands func(string, ...string)) (string, error) {
 	// Hash input file.
 	fileHash, err := hashFile(abspath)
@@ -252,13 +252,14 @@ func hashFile(path string) (string, error) {
 // file is assumed to have a single target named deps.
 //
 // There are roughly three make syntax variants:
-// - BSD make, which doesn't support any escaping. This means that many special
-//   characters are not supported in file names.
-// - GNU make, which supports escaping using a backslash but when it fails to
-//   find a file it tries to fall back with the literal path name (to match BSD
-//   make).
-// - NMake (Visual Studio) and Jom, which simply quote the string if there are
-//   any weird characters.
+//   - BSD make, which doesn't support any escaping. This means that many special
+//     characters are not supported in file names.
+//   - GNU make, which supports escaping using a backslash but when it fails to
+//     find a file it tries to fall back with the literal path name (to match BSD
+//     make).
+//   - NMake (Visual Studio) and Jom, which simply quote the string if there are
+//     any weird characters.
+//
 // Clang supports two variants: a format that's a compromise between BSD and GNU
 // make (and is buggy to match GCC which is equally buggy), and NMake/Jom, which
 // is at least somewhat sane. This last format isn't perfect either: it does not