extension: update gopls v0.21.0-pre.2 settings

This is an automated CL which updates the gopls version and settings.

For golang/go#76367

Change-Id: Ibab5b5e7000fd86b42bdc69e54eba3d0a026599c
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/727382
Auto-Submit: Gopher Robot <[email protected]>
Reviewed-by: Madeline Kalil <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Alan Donovan <[email protected]>

Author: gopherbot

docs/settings.md

@@ -964,7 +964,7 @@ Example Usage:
 | `nilness` | check for redundant or impossible nil comparisons <br/> The nilness checker inspects the control-flow graph of each function in a package and reports nil pointer dereferences, degenerate nil pointers, and panics with nil values. A degenerate comparison is of the form x==nil or x!=nil where x is statically known to be nil or non-nil. These are often a mistake, especially in control flow related to errors. Panics with nil values are checked because they are not detectable by <br/> <pre>if r := recover(); r != nil {</pre><br/> This check reports conditions such as: <br/> <pre>if f == nil { // impossible condition (f is a function)<br/>}</pre><br/> and: <br/> <pre>p := &v<br/>...<br/>if p != nil { // tautological condition<br/>}</pre><br/> and: <br/> <pre>if p == nil {<br/>	print(*p) // nil dereference<br/>}</pre><br/> and: <br/> <pre>if p == nil {<br/>	panic(p)<br/>}</pre><br/> Sometimes the control flow may be quite complex, making bugs hard to spot. In the example below, the err.Error expression is guaranteed to panic because, after the first return, err must be nil. The intervening loop is just a distraction. <br/> <pre>...<br/>err := g.Wait()<br/>if err != nil {<br/>	return err<br/>}<br/>partialSuccess := false<br/>for _, err := range errs {<br/>	if err == nil {<br/>		partialSuccess = true<br/>		break<br/>	}<br/>}<br/>if partialSuccess {<br/>	reportStatus(StatusMessage{<br/>		Code:   code.ERROR,<br/>		Detail: err.Error(), // "nil dereference in dynamic method call"<br/>	})<br/>	return nil<br/>}</pre><br/> ... <br/> Default: `true` |
 | `nonewvars` | suggested fixes for "no new vars on left side of :=" <br/> This checker provides suggested fixes for type errors of the type "no new vars on left side of :=". For example: <br/> <pre>z := 1<br/>z := 2</pre><br/> will turn into <br/> <pre>z := 1<br/>z = 2</pre><br/> Default: `true` |
 | `noresultvalues` | suggested fixes for unexpected return values <br/> This checker provides suggested fixes for type errors of the type "no result values expected" or "too many return values". For example: <br/> <pre>func z() { return nil }</pre><br/> will turn into <br/> <pre>func z() { return }</pre><br/> Default: `true` |
-| `omitzero` | suggest replacing omitempty with omitzero for struct fields <br/> The omitzero analyzer identifies uses of the `omitempty` JSON struct tag on fields that are themselves structs. The `omitempty` tag has no effect on struct-typed fields. The analyzer offers two suggestions: either remove the tag, or replace it with `omitzero` (added in Go 1.24), which correctly omits the field if the struct value is zero. <br/> Replacing `omitempty` with `omitzero` is a change in behavior. The original code would always encode the struct field, whereas the modified code will omit it if it is a zero-value. <br/> Default: `true` |
+| `omitzero` | suggest replacing omitempty with omitzero for struct fields <br/> The omitzero analyzer identifies uses of the `omitempty` JSON struct tag on fields that are themselves structs. For struct-typed fields, the `omitempty` tag has no effect on the behavior of json.Marshal and json.Unmarshal. The analyzer offers two suggestions: either remove the tag, or replace it with `omitzero` (added in Go 1.24), which correctly omits the field if the struct value is zero. <br/> However, some other serialization packages (notably kubebuilder, see https://book.kubebuilder.io/reference/markers.html) may have their own interpretation of the `json:",omitzero"` tag, so removing it may affect program behavior. For this reason, the omitzero modernizer will not make changes in any package that contains +kubebuilder annotations. <br/> Replacing `omitempty` with `omitzero` is a change in behavior. The original code would always encode the struct field, whereas the modified code will omit it if it is a zero-value. <br/> Default: `true` |
 | `plusbuild` | remove obsolete //+build comments <br/> The plusbuild analyzer suggests a fix to remove obsolete build tags of the form: <br/> <pre>//+build linux,amd64</pre><br/> in files that also contain a Go 1.18-style tag such as: <br/> <pre>//go:build linux && amd64</pre><br/> (It does not check that the old and new tags are consistent; that is the job of the 'buildtag' analyzer in the vet suite.) <br/> Default: `true` |
 | `printf` | check consistency of Printf format strings and arguments <br/> The check applies to calls of the formatting functions such as [fmt.Printf] and [fmt.Sprintf], as well as any detected wrappers of those functions such as [log.Printf]. It reports a variety of mistakes such as syntax errors in the format string and mismatches (of number and type) between the verbs and their arguments. <br/> See the documentation of the fmt package for the complete set of format operators and their operand types. <br/> Default: `true` |
 | `rangeint` | replace 3-clause for loops with for-range over integers <br/> The rangeint analyzer suggests replacing traditional for loops such as <br/> <pre>for i := 0; i < n; i++ { ... }</pre><br/> with the more idiomatic Go 1.22 style: <br/> <pre>for i := range n { ... }</pre><br/> This transformation is applied only if (a) the loop variable is not modified within the loop body and (b) the loop's limit expression is not modified within the loop, as `for range` evaluates its operand only once. <br/> Default: `true` |
@@ -996,6 +996,7 @@ Example Usage:
 | `timeformat` | check for calls of (time.Time).Format or time.Parse with 2006-02-01 <br/> The timeformat checker looks for time formats with the 2006-02-01 (yyyy-dd-mm) format. Internationally, "yyyy-dd-mm" does not occur in common calendar date standards, and so it is more likely that 2006-01-02 (yyyy-mm-dd) was intended. <br/> Default: `true` |
 | `unmarshal` | report passing non-pointer or non-interface values to unmarshal <br/> The unmarshal analysis reports calls to functions such as json.Unmarshal in which the argument type is not a pointer or an interface. <br/> Default: `true` |
 | `unreachable` | check for unreachable code <br/> The unreachable analyzer finds statements that execution can never reach because they are preceded by a return statement, a call to panic, an infinite loop, or similar constructs. <br/> Default: `true` |
+| `unsafefuncs` | replace unsafe pointer arithmetic with function calls <br/> The unsafefuncs analyzer simplifies pointer arithmetic expressions by replacing them with calls to helper functions such as unsafe.Add, added in Go 1.17. <br/> Example: <br/> <pre>unsafe.Pointer(uintptr(ptr) + uintptr(n))</pre><br/> where ptr is an unsafe.Pointer, is replaced by: <br/> <pre>unsafe.Add(ptr, n)</pre><br/> Default: `true` |
 | `unsafeptr` | check for invalid conversions of uintptr to unsafe.Pointer <br/> The unsafeptr analyzer reports likely incorrect uses of unsafe.Pointer to convert integers to pointers. A conversion from uintptr to unsafe.Pointer is invalid if it implies that there is a uintptr-typed word in memory that holds a pointer value, because that word will be invisible to stack copying and to the garbage collector. <br/> Default: `true` |
 | `unusedfunc` | check for unused functions, methods, etc <br/> The unusedfunc analyzer reports functions and methods that are never referenced outside of their own declaration. <br/> A function is considered unused if it is unexported and not referenced (except within its own declaration). <br/> A method is considered unused if it is unexported, not referenced (except within its own declaration), and its name does not match that of any method of an interface type declared within the same package. <br/> The tool may report false positives in some situations, for example: <br/>   - for a declaration of an unexported function that is referenced     from another package using the go:linkname mechanism, if the     declaration's doc comment does not also have a go:linkname     comment. <br/>     (Such code is in any case strongly discouraged: linkname     annotations, if they must be used at all, should be used on both     the declaration and the alias.) <br/>   - for compiler intrinsics in the "runtime" package that, though     never referenced, are known to the compiler and are called     indirectly by compiled object code. <br/>   - for functions called only from assembly. <br/>   - for functions called only from files whose build tags are not     selected in the current build configuration. <br/> Since these situations are relatively common in the low-level parts of the runtime, this analyzer ignores the standard library. See https://go.dev/issue/71686 and https://go.dev/issue/74130 for further discussion of these limitations. <br/> The unusedfunc algorithm is not as precise as the golang.org/x/tools/cmd/deadcode tool, but it has the advantage that it runs within the modular analysis framework, enabling near real-time feedback within gopls. <br/> The unusedfunc analyzer also reports unused types, vars, and constants. Enums--constants defined with iota--are ignored since even the unused values must remain present to preserve the logical ordering. <br/> Default: `true` |
 | `unusedparams` | check for unused parameters of functions <br/> The unusedparams analyzer checks functions to see if there are any parameters that are not being used. <br/> To ensure soundness, it ignores:   - "address-taken" functions, that is, functions that are used as     a value rather than being called directly; their signatures may     be required to conform to a func type.   - exported functions or methods, since they may be address-taken     in another package.   - unexported methods whose name matches an interface method     declared in the same package, since the method's signature     may be required to conform to the interface type.   - functions with empty bodies, or containing just a call to panic.   - parameters that are unnamed, or named "_", the blank identifier. <br/> The analyzer suggests a fix of replacing the parameter name by "_", but in such cases a deeper fix can be obtained by invoking the "Refactor: remove unused parameter" code action, which will eliminate the parameter entirely, along with all corresponding arguments at call sites, while taking care to preserve any side effects in the argument expressions; see https://github.com/golang/tools/releases/tag/gopls%2Fv0.14. <br/> This analyzer ignores generated code. <br/> Default: `true` |

extension/package.json

@@ -3152,7 +3152,7 @@
                 },
                 "omitzero": {
                   "type": "boolean",
-                  "markdownDescription": "suggest replacing omitempty with omitzero for struct fields\n\nThe omitzero analyzer identifies uses of the `omitempty` JSON struct tag on\nfields that are themselves structs. The `omitempty` tag has no effect on\nstruct-typed fields. The analyzer offers two suggestions: either remove the\ntag, or replace it with `omitzero` (added in Go 1.24), which correctly\nomits the field if the struct value is zero.\n\nReplacing `omitempty` with `omitzero` is a change in behavior. The\noriginal code would always encode the struct field, whereas the\nmodified code will omit it if it is a zero-value.",
+                  "markdownDescription": "suggest replacing omitempty with omitzero for struct fields\n\nThe omitzero analyzer identifies uses of the `omitempty` JSON struct\ntag on fields that are themselves structs. For struct-typed fields,\nthe `omitempty` tag has no effect on the behavior of json.Marshal and\njson.Unmarshal. The analyzer offers two suggestions: either remove the\ntag, or replace it with `omitzero` (added in Go 1.24), which correctly\nomits the field if the struct value is zero.\n\nHowever, some other serialization packages (notably kubebuilder, see\nhttps://book.kubebuilder.io/reference/markers.html) may have their own\ninterpretation of the `json:\",omitzero\"` tag, so removing it may affect\nprogram behavior. For this reason, the omitzero modernizer will not\nmake changes in any package that contains +kubebuilder annotations.\n\nReplacing `omitempty` with `omitzero` is a change in behavior. The\noriginal code would always encode the struct field, whereas the\nmodified code will omit it if it is a zero-value.",
                   "default": true
                 },
                 "plusbuild": {
@@ -3310,6 +3310,11 @@
                   "markdownDescription": "check for unreachable code\n\nThe unreachable analyzer finds statements that execution can never reach\nbecause they are preceded by a return statement, a call to panic, an\ninfinite loop, or similar constructs.",
                   "default": true
                 },
+                "unsafefuncs": {
+                  "type": "boolean",
+                  "markdownDescription": "replace unsafe pointer arithmetic with function calls\n\nThe unsafefuncs analyzer simplifies pointer arithmetic expressions by\nreplacing them with calls to helper functions such as unsafe.Add,\nadded in Go 1.17.\n\nExample:\n\n\tunsafe.Pointer(uintptr(ptr) + uintptr(n))\n\nwhere ptr is an unsafe.Pointer, is replaced by:\n\n\tunsafe.Add(ptr, n)",
+                  "default": true
+                },
                 "unsafeptr": {
                   "type": "boolean",
                   "markdownDescription": "check for invalid conversions of uintptr to unsafe.Pointer\n\nThe unsafeptr analyzer reports likely incorrect uses of unsafe.Pointer\nto convert integers to pointers. A conversion from uintptr to\nunsafe.Pointer is invalid if it implies that there is a uintptr-typed\nword in memory that holds a pointer value, because that word will be\ninvisible to stack copying and to the garbage collector.",