extension: update gopls v0.17.0-pre.4 settings

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

For golang/go#70301

Change-Id: I8d61814996c67ff6af8b782cfdc72eb7db3edc29
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/633935
Commit-Queue: Gopher Robot <[email protected]>
kokoro-CI: kokoro <[email protected]>
Reviewed-by: Robert Findley <[email protected]>
Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
Auto-Submit: Gopher Robot <[email protected]>

Author: gopherbot

docs/settings.md

@@ -780,7 +780,6 @@ Example Usage:
 | `testinggoroutine` | report calls to (*testing.T).Fatal from goroutines started by a test <br/> Functions that abruptly terminate a test, such as the Fatal, Fatalf, FailNow, and Skip{,f,Now} methods of *testing.T, must be called from the test goroutine itself. This checker detects calls to these functions that occur within a goroutine started by the test. For example: <br/> <pre>func TestFoo(t *testing.T) {<br/>    go func() {<br/>        t.Fatal("oops") // error: (*T).Fatal called from non-test goroutine<br/>    }()<br/>}</pre><br/> Default: `true` |
 | `tests` | check for common mistaken usages of tests and examples <br/> The tests checker walks Test, Benchmark, Fuzzing and Example functions checking malformed names, wrong signatures and examples documenting non-existent identifiers. <br/> Please see the documentation for package testing in golang.org/pkg/testing for the conventions that are enforced for Tests, Benchmarks, and Examples. <br/> Default: `true` |
 | `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` |
-| `undeclaredname` | suggested fixes for "undeclared name: <>" <br/> This checker provides suggested fixes for type errors of the type "undeclared name: <>". It will either insert a new statement, such as: <br/> <pre><> :=</pre><br/> or a new function declaration, such as: <br/> <pre>func <>(inferred parameters) {<br/>	panic("implement me!")<br/>}</pre><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 an return statement, a call to panic, an infinite loop, or similar constructs. <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` |
@@ -789,6 +788,8 @@ Example Usage:
 | `unusedvariable` | check for unused variables and suggest fixes <br/> Default: `false` |
 | `unusedwrite` | checks for unused writes <br/> The analyzer reports instances of writes to struct fields and arrays that are never read. Specifically, when a struct object or an array is copied, its elements are copied implicitly by the compiler, and any element write to this copy does nothing with the original object. <br/> For example: <br/> <pre>type T struct { x int }</pre><br/> <pre>func f(input []T) {<br/>	for i, v := range input {  // v is a copy<br/>		v.x = i  // unused write to field x<br/>	}<br/>}</pre><br/> Another example is about non-pointer receiver: <br/> <pre>type T struct { x int }</pre><br/> <pre>func (t T) f() {  // t is a copy<br/>	t.x = i  // unused write to field x<br/>}</pre><br/> Default: `true` |
 | `useany` | check for constraints that could be simplified to "any" <br/> Default: `false` |
+| `waitgroup` | check for misuses of sync.WaitGroup <br/> This analyzer detects mistaken calls to the (*sync.WaitGroup).Add method from inside a new goroutine, causing Add to race with Wait: <br/> <pre>// WRONG<br/>var wg sync.WaitGroup<br/>go func() {<br/>        wg.Add(1) // "WaitGroup.Add called from inside new goroutine"<br/>        defer wg.Done()<br/>        ...<br/>}()<br/>wg.Wait() // (may return prematurely before new goroutine starts)</pre><br/> The correct code calls Add before starting the goroutine: <br/> <pre>// RIGHT<br/>var wg sync.WaitGroup<br/>wg.Add(1)<br/>go func() {<br/>	defer wg.Done()<br/>	...<br/>}()<br/>wg.Wait()</pre><br/> Default: `true` |
+| `yield` | report calls to yield where the result is ignored <br/> After a yield function returns false, the caller should not call the yield function again; generally the iterator should return promptly. <br/> This example fails to check the result of the call to yield, causing this analyzer to report a diagnostic: <br/> <pre>yield(1) // yield may be called again (on L2) after returning false<br/>yield(2)</pre><br/> The corrected code is either this: <br/> <pre>if yield(1) { yield(2) }</pre><br/> or simply: <br/> <pre>_ = yield(1) && yield(2)</pre><br/> It is not always a mistake to ignore the result of yield. For example, this is a valid single-element iterator: <br/> <pre>yield(1) // ok to ignore result<br/>return</pre><br/> It is only a mistake when the yield call that returned false may be followed by another call. <br/> Default: `true` |
 ### `ui.diagnostic.analysisProgressReporting`
 
 analysisProgressReporting controls whether gopls sends progress

extension/package.json

@@ -2321,11 +2321,6 @@
                   "markdownDescription": "check for calls of (time.Time).Format or time.Parse with 2006-02-01\n\nThe timeformat checker looks for time formats with the 2006-02-01 (yyyy-dd-mm)\nformat. Internationally, \"yyyy-dd-mm\" does not occur in common calendar date\nstandards, and so it is more likely that 2006-01-02 (yyyy-mm-dd) was intended.",
                   "default": true
                 },
-                "undeclaredname": {
-                  "type": "boolean",
-                  "markdownDescription": "suggested fixes for \"undeclared name: <>\"\n\nThis checker provides suggested fixes for type errors of the\ntype \"undeclared name: <>\". It will either insert a new statement,\nsuch as:\n\n\t<> :=\n\nor a new function declaration, such as:\n\n\tfunc <>(inferred parameters) {\n\t\tpanic(\"implement me!\")\n\t}",
-                  "default": true
-                },
                 "unmarshal": {
                   "type": "boolean",
                   "markdownDescription": "report passing non-pointer or non-interface values to unmarshal\n\nThe unmarshal analysis reports calls to functions such as json.Unmarshal\nin which the argument type is not a pointer or an interface.",
@@ -2365,6 +2360,16 @@
                   "type": "boolean",
                   "markdownDescription": "check for constraints that could be simplified to \"any\"",
                   "default": false
+                },
+                "waitgroup": {
+                  "type": "boolean",
+                  "markdownDescription": "check for misuses of sync.WaitGroup\n\nThis analyzer detects mistaken calls to the (*sync.WaitGroup).Add\nmethod from inside a new goroutine, causing Add to race with Wait:\n\n\t// WRONG\n\tvar wg sync.WaitGroup\n\tgo func() {\n\t        wg.Add(1) // \"WaitGroup.Add called from inside new goroutine\"\n\t        defer wg.Done()\n\t        ...\n\t}()\n\twg.Wait() // (may return prematurely before new goroutine starts)\n\nThe correct code calls Add before starting the goroutine:\n\n\t// RIGHT\n\tvar wg sync.WaitGroup\n\twg.Add(1)\n\tgo func() {\n\t\tdefer wg.Done()\n\t\t...\n\t}()\n\twg.Wait()",
+                  "default": true
+                },
+                "yield": {
+                  "type": "boolean",
+                  "markdownDescription": "report calls to yield where the result is ignored\n\nAfter a yield function returns false, the caller should not call\nthe yield function again; generally the iterator should return\npromptly.\n\nThis example fails to check the result of the call to yield,\ncausing this analyzer to report a diagnostic:\n\n\tyield(1) // yield may be called again (on L2) after returning false\n\tyield(2)\n\nThe corrected code is either this:\n\n\tif yield(1) { yield(2) }\n\nor simply:\n\n\t_ = yield(1) && yield(2)\n\nIt is not always a mistake to ignore the result of yield.\nFor example, this is a valid single-element iterator:\n\n\tyield(1) // ok to ignore result\n\treturn\n\nIt is only a mistake when the yield call that returned false may be\nfollowed by another call.",
+                  "default": true
                 }
               }
             },