extension: update gopls v0.23.0-pre.1 settings This is an automated CL which updates the gopls version and settings. For golang/go#80164 Change-Id: Iadd4c017249f127cdcc8a12560336940c9658242 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/794482 Auto-Submit: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Alex Putman <aputman@golang.org>
diff --git a/docs/settings.md b/docs/settings.md index b19fc4d..1d6f7d3 100644 --- a/docs/settings.md +++ b/docs/settings.md
@@ -269,7 +269,7 @@ `"assignVariableTypes"` controls inlay hints for variable types in assign statements: ```go - i/* int*/, j/* int*/ := 0, len(r)-1 + i« int», j« int» := 0, len(r)-1 ``` @@ -278,7 +278,9 @@ `"compositeLiteralFields"` inlay hints for composite literal field names: ```go - {/*in: */"Hello, world", /*want: */"dlrow ,olleH"} + Point2D{«X: »1, «Y: »2} + + Outer{«Embedded.»Field: 0} ``` @@ -290,7 +292,7 @@ for _, c := range []struct { in, want string }{ - /*struct{ in string; want string }*/{"Hello, world", "dlrow ,olleH"}, + «struct{ in string; want string }»{"Hello, world", "dlrow ,olleH"}, } ``` @@ -301,10 +303,10 @@ `"constantValues"` controls inlay hints for constant values: ```go const ( - KindNone Kind = iota/* = 0*/ - KindPrint/* = 1*/ - KindPrintf/* = 2*/ - KindErrorf/* = 3*/ + KindNone Kind = iota« = 0» + KindPrint« = 1» + KindPrintf« = 2» + KindErrorf« = 3» ) ``` @@ -314,7 +316,7 @@ `"functionTypeParameters"` inlay hints for implicit type parameters on generic functions: ```go - myFoo/*[int, string]*/(1, "hello") + myFoo«[int, string]»(1, "hello") ``` @@ -323,7 +325,7 @@ `"ignoredError"` inlay hints for implicitly discarded errors: ```go - f.Close() // ignore error + f.Close()« // ignore error» ``` This check inserts an `// ignore error` hint following any statement that is a function call whose error result is @@ -341,7 +343,7 @@ `"parameterNames"` controls inlay hints for parameter names: ```go - parseInt(/* str: */ "123", /* radix: */ 8) + parseInt(« str: » "123", « radix: » 8) ``` @@ -350,7 +352,7 @@ `"rangeVariableTypes"` controls inlay hints for variable types in range statements: ```go - for k/* int*/, v/* string*/ := range []string{} { + for k« int», v« string» := range []string{} { fmt.Println(k, v) } ``` @@ -813,7 +815,7 @@ | `S1002` | Omit comparison with boolean constant <br/> Before: <br/> if x == true {} <br/> After: <br/> if x {} <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `S1003` | Replace call to strings.Index with strings.Contains <br/> Before: <br/> if strings.Index(x, y) != -1 {} <br/> After: <br/> if strings.Contains(x, y) {} <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `S1004` | Replace call to bytes.Compare with bytes.Equal <br/> Before: <br/> if bytes.Compare(x, y) == 0 {} <br/> After: <br/> if bytes.Equal(x, y) {} <br/> Available since 2017.1 <br/> <br/> Default: `true` | -| `S1005` | Drop unnecessary use of the blank identifier <br/> In many cases, assigning to the blank identifier is unnecessary. <br/> Before: <br/> for _ = range s {} x, _ = someMap[key] _ = <-ch <br/> After: <br/> for range s{} x = someMap[key] <-ch <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `S1005` | Drop unnecessary use of the blank identifier <br/> In many cases, assigning to the blank identifier is unnecessary. <br/> Before: <br/> for _ = range s {} _ = <-ch <br/> After: <br/> for range s{} <-ch <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `S1006` | Use 'for { ... }' for infinite loops <br/> For infinite loops, using for { ... } is the most idiomatic choice. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `S1007` | Simplify regular expression by using raw string literal <br/> Raw string literals use backticks instead of quotation marks and do not support any escape sequences. This means that the backslash can be used freely, without the need of escaping. <br/> Since regular expressions have their own escape sequences, raw strings can improve their readability. <br/> Before: <br/> regexp.Compile("\\A(\\w+) profile: total \\d+\\n\\z") <br/> After: <br/> regexp.Compile(`\A(\w+) profile: total \d+\n\z`) <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `S1008` | Simplify returning boolean expression <br/> Before: <br/> if <expr> { return true } return false <br/> After: <br/> return <expr> <br/> Available since 2017.1 <br/> <br/> Default: `false` | @@ -845,7 +847,7 @@ | `S1040` | Type assertion to current type <br/> The type assertion x.(SomeInterface), when x already has type SomeInterface, can only fail if x is nil. Usually, this is left-over code from when x had a different type and you can safely delete the type assertion. If you want to check that x is not nil, consider being explicit and using an actual if x == nil comparison instead of relying on the type assertion panicking. <br/> Available since 2021.1 <br/> <br/> Default: `true` | | `SA1000` | Invalid regular expression <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1001` | Invalid template <br/> Available since 2017.1 <br/> <br/> Default: `true` | -| `SA1002` | Invalid format in time.Parse <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `SA1002` | Invalid format in time.Parse <br/> time.Parse requires a layout string that uses Go's reference time: 'Mon Jan 2 15:04:05 MST 2006'. The layout must represent this date and time exactly. See https://pkg.go.dev/time#pkg-constants for layout examples. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1003` | Unsupported argument to functions in encoding/binary <br/> The encoding/binary package can only serialize types with known sizes. This precludes the use of the int and uint types, as their sizes differ on different architectures. Furthermore, it doesn't support serializing maps, channels, strings, or functions. <br/> Before Go 1.8, bool wasn't supported, either. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1004` | Suspiciously small untyped constant in time.Sleep <br/> The time.Sleep function takes a time.Duration as its only argument. Durations are expressed in nanoseconds. Thus, calling time.Sleep(1) will sleep for 1 nanosecond. This is a common source of bugs, as sleep functions in other languages often accept seconds or milliseconds. <br/> The time package provides constants such as time.Second to express large durations. These can be combined with arithmetic to express arbitrary durations, for example 5 * time.Second for 5 seconds. <br/> If you truly meant to sleep for a tiny amount of time, use n * time.Nanosecond to signal to Staticcheck that you did mean to sleep for some amount of nanoseconds. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA1005` | Invalid first argument to exec.Command <br/> os/exec runs programs directly (using variants of the fork and exec system calls on Unix systems). This shouldn't be confused with running a command in a shell. The shell will allow for features such as input redirection, pipes, and general scripting. The shell is also responsible for splitting the user's input into a program name and its arguments. For example, the equivalent to <br/> ls / /tmp <br/> would be <br/> exec.Command("ls", "/", "/tmp") <br/> If you want to run a command in a shell, consider using something like the following – but be aware that not all systems, particularly Windows, will have a /bin/sh program: <br/> exec.Command("/bin/sh", "-c", "ls | grep Awesome") <br/> Available since 2017.1 <br/> <br/> Default: `true` | @@ -853,14 +855,14 @@ | `SA1008` | Non-canonical key in http.Header map <br/> Keys in http.Header maps are canonical, meaning they follow a specific combination of uppercase and lowercase letters. Methods such as http.Header.Add and http.Header.Del convert inputs into this canonical form before manipulating the map. <br/> When manipulating http.Header maps directly, as opposed to using the provided methods, care should be taken to stick to canonical form in order to avoid inconsistencies. The following piece of code demonstrates one such inconsistency: <br/> h := http.Header{} h["etag"] = []string{"1234"} h.Add("etag", "5678") fmt.Println(h) <br/> // Output: // map[Etag:[5678] etag:[1234]] <br/> The easiest way of obtaining the canonical form of a key is to use http.CanonicalHeaderKey. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA1010` | (*regexp.Regexp).FindAll called with n == 0, which will always return zero results <br/> If n >= 0, the function returns at most n matches/submatches. To return all results, specify a negative number. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1011` | Various methods in the 'strings' package expect valid UTF-8, but invalid input is provided <br/> Available since 2017.1 <br/> <br/> Default: `false` | -| `SA1012` | A nil context.Context is being passed to a function, consider using context.TODO instead <br/> Available since 2017.1 <br/> <br/> Default: `true` | +| `SA1012` | A nil context.Context is being passed to a function, consider using context.TODO instead <br/> The context package prohibits the use of a nil context. If no parent context is available, a new context should be used, e.g. context.TODO or context.Background. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA1013` | io.Seeker.Seek is being called with the whence constant as the first argument, but it should be the second <br/> Available since 2017.1 <br/> <br/> Default: `true` | -| `SA1014` | Non-pointer value passed to Unmarshal or Decode <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `SA1014` | Non-pointer value passed to Unmarshal or Decode <br/> Functions such as encoding/json.Unmarshal and (*encoding/json.Decoder).Decode require a pointer to the value that should be populated. Passing a non-pointer value results in the function returning an error at runtime, as it cannot modify the target value. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1015` | Using time.Tick in a way that will leak. Consider using time.NewTicker, and only use time.Tick in tests, commands and endless functions <br/> Before Go 1.23, time.Tickers had to be closed to be able to be garbage collected. Since time.Tick doesn't make it possible to close the underlying ticker, using it repeatedly would leak memory. <br/> Go 1.23 fixes this by allowing tickers to be collected even if they weren't closed. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1016` | Trapping a signal that cannot be trapped <br/> Not all signals can be intercepted by a process. Specifically, on UNIX-like systems, the syscall.SIGKILL and syscall.SIGSTOP signals are never passed to the process, but instead handled directly by the kernel. It is therefore pointless to try and handle these signals. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA1017` | Channels used with os/signal.Notify should be buffered <br/> The os/signal package uses non-blocking channel sends when delivering signals. If the receiving end of the channel isn't ready and the channel is either unbuffered or full, the signal will be dropped. To avoid missing signals, the channel should be buffered and of the appropriate size. For a channel used for notification of just one signal value, a buffer of size 1 is sufficient. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1018` | strings.Replace called with n == 0, which does nothing <br/> With n == 0, zero instances will be replaced. To replace all instances, use a negative number, or use strings.ReplaceAll. <br/> Available since 2017.1 <br/> <br/> Default: `false` | -| `SA1020` | Using an invalid host:port pair with a net.Listen-related function <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `SA1020` | Using an invalid host:port pair with a net.Listen-related function <br/> Functions such as net.Listen, net.ListenTCP, and similar, expect a valid network address in the form of host:port. The host, the port, or both, can be omitted, e.g. localhost:8080, :8080 or : are valid host:port pairs. See https://pkg.go.dev/net#Listen for the full documentation. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1021` | Using bytes.Equal to compare two net.IP <br/> A net.IP stores an IPv4 or IPv6 address as a slice of bytes. The length of the slice for an IPv4 address, however, can be either 4 or 16 bytes long, using different ways of representing IPv4 addresses. In order to correctly compare two net.IPs, the net.IP.Equal method should be used, as it takes both representations into account. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1023` | Modifying the buffer in an io.Writer implementation <br/> Write must not modify the slice data, even temporarily. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA1024` | A string cutset contains duplicate characters <br/> The strings.TrimLeft and strings.TrimRight functions take cutsets, not prefixes. A cutset is treated as a set of characters to remove from a string. For example, <br/> strings.TrimLeft("42133word", "1234") <br/> will result in the string "word" – any characters that are 1, 2, 3 or 4 are cut from the left of the string. <br/> In order to remove one string from another, use strings.TrimPrefix instead. <br/> Available since 2017.1 <br/> <br/> Default: `false` | @@ -874,7 +876,7 @@ | `SA1032` | Wrong order of arguments to errors.Is <br/> The first argument of the function errors.Is is the error that we have and the second argument is the error we're trying to match against. For example: <br/> <pre>if errors.Is(err, io.EOF) { ... }</pre><br/> This check detects some cases where the two arguments have been swapped. It flags any calls where the first argument is referring to a package-level error variable, such as <br/> <pre>if errors.Is(io.EOF, err) { /* this is wrong */ }</pre><br/> Available since 2024.1 <br/> <br/> Default: `false` | | `SA2001` | Empty critical section, did you mean to defer the unlock? <br/> Empty critical sections of the kind <br/> mu.Lock() mu.Unlock() <br/> are very often a typo, and the following was intended instead: <br/> mu.Lock() defer mu.Unlock() <br/> Do note that sometimes empty critical sections can be useful, as a form of signaling to wait on another goroutine. Many times, there are simpler ways of achieving the same effect. When that isn't the case, the code should be amply commented to avoid confusion. Combining such comments with a //lint:ignore directive can be used to suppress this rare false positive. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA2002` | Called testing.T.FailNow or SkipNow in a goroutine, which isn't allowed <br/> Available since 2017.1 <br/> <br/> Default: `false` | -| `SA2003` | Deferred Lock right after locking, likely meant to defer Unlock instead <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `SA2003` | Deferred Lock right after locking, likely meant to defer Unlock instead <br/> Deferring a call to Lock immediately after locking is almost always a typo. For example: <br/> mu.Lock() defer mu.Lock() <br/> While this does not strictly guarantee a deadlock depending on how the surrounding code is structured, it is highly likely to be a mistake. The intended code was likely this: <br/> mu.Lock() defer mu.Unlock() <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA3000` | TestMain doesn't call os.Exit, hiding test failures <br/> Test executables (and in turn 'go test') exit with a non-zero status code if any tests failed. When specifying your own TestMain function, it is your responsibility to arrange for this, by calling os.Exit with the correct code. The correct code is returned by (*testing.M).Run, so the usual way of implementing TestMain is to end it with os.Exit(m.Run()). <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA3001` | Assigning to b.N in benchmarks distorts the results <br/> The testing package dynamically sets b.N to improve the reliability of benchmarks and uses it in computations to determine the duration of a single operation. Benchmark code must not alter b.N as this would falsify results. <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA4000` | Binary operator has identical expressions on both sides <br/> Available since 2017.1 <br/> <br/> Default: `true` | @@ -885,7 +887,7 @@ | `SA4006` | A value assigned to a variable is never read before being overwritten. Forgotten error check or dead code? <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA4008` | The variable in the loop condition never changes, are you incrementing the wrong variable? <br/> For example: <br/> <pre>for i := 0; i < 10; j++ { ... }</pre><br/> This may also occur when a loop can only execute once because of unconditional control flow that terminates the loop. For example, when a loop body contains an unconditional break, return, or panic: <br/> <pre>func f() {<br/> panic("oops")<br/>}<br/>func g() {<br/> for i := 0; i < 10; i++ {<br/> // f unconditionally calls panic, which means "i" is<br/> // never incremented.<br/> f()<br/> }<br/>}</pre><br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA4009` | A function argument is overwritten before its first use <br/> Available since 2017.1 <br/> <br/> Default: `false` | -| `SA4010` | The result of append will never be observed anywhere <br/> Available since 2017.1 <br/> <br/> Default: `false` | +| `SA4010` | The result of append will never be observed anywhere <br/> Calls to append produce a new slice value. When the result of append is assigned to a variable that is never subsequently read, the append operation may have an unintended effect. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA4011` | Break statement with no effect. Did you mean to break out of an outer loop? <br/> Available since 2017.1 <br/> <br/> Default: `true` | | `SA4012` | Comparing a value against NaN even though no value is equal to NaN <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA4013` | Negating a boolean twice (!!b) is the same as writing b. This is either redundant, or a typo. <br/> Available since 2017.1 <br/> <br/> Default: `true` | @@ -916,7 +918,6 @@ | `SA5007` | Infinite recursive call <br/> A function that calls itself recursively needs to have an exit condition. Otherwise it will recurse forever, until the system runs out of memory. <br/> This issue can be caused by simple bugs such as forgetting to add an exit condition. It can also happen "on purpose". Some languages have tail call optimization which makes certain infinite recursive calls safe to use. Go, however, does not implement TCO, and as such a loop should be used instead. <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA5008` | Invalid struct tag <br/> Available since 2019.2 <br/> <br/> Default: `true` | | `SA5010` | Impossible type assertion <br/> Some type assertions can be statically proven to be impossible. This is the case when the method sets of both arguments of the type assertion conflict with each other, for example by containing the same method with different signatures. <br/> The Go compiler already applies this check when asserting from an interface value to a concrete type. If the concrete type misses methods from the interface, or if function signatures don't match, then the type assertion can never succeed. <br/> This check applies the same logic when asserting from one interface to another. If both interface types contain the same method but with different signatures, then the type assertion can never succeed, either. <br/> Available since 2020.1 <br/> <br/> Default: `false` | -| `SA5011` | Possible nil pointer dereference <br/> A pointer is being dereferenced unconditionally, while also being checked against nil in another place. This suggests that the pointer may be nil and dereferencing it may panic. This is commonly a result of improperly ordered code or missing return statements. Consider the following examples: <br/> func fn(x *int) { fmt.Println(*x) <br/> // This nil check is equally important for the previous dereference if x != nil { foo(*x) } } <br/> func TestFoo(t *testing.T) { x := compute() if x == nil { t.Errorf("nil pointer received") } <br/> // t.Errorf does not abort the test, so if x is nil, the next line will panic. foo(*x) } <br/> Staticcheck tries to deduce which functions abort control flow. For example, it is aware that a function will not continue execution after a call to panic or log.Fatal. However, sometimes this detection fails, in particular in the presence of conditionals. Consider the following example: <br/> func Log(msg string, level int) { fmt.Println(msg) if level == levelFatal { os.Exit(1) } } <br/> func Fatal(msg string) { Log(msg, levelFatal) } <br/> func fn(x *int) { if x == nil { Fatal("unexpected nil pointer") } fmt.Println(*x) } <br/> Staticcheck will flag the dereference of x, even though it is perfectly safe. Staticcheck is not able to deduce that a call to Fatal will exit the program. For the time being, the easiest workaround is to modify the definition of Fatal like so: <br/> func Fatal(msg string) { Log(msg, levelFatal) panic("unreachable") } <br/> We also hard-code functions from common logging packages such as logrus. Please file an issue if we're missing support for a popular package. <br/> Available since 2020.1 <br/> <br/> Default: `false` | | `SA5012` | Passing odd-sized slice to function expecting even size <br/> Some functions that take slices as parameters expect the slices to have an even number of elements. Often, these functions treat elements in a slice as pairs. For example, strings.NewReplacer takes pairs of old and new strings, and calling it with an odd number of elements would be an error. <br/> Available since 2020.2 <br/> <br/> Default: `false` | | `SA6000` | Using regexp.Match or related in a loop, should use regexp.Compile <br/> Available since 2017.1 <br/> <br/> Default: `false` | | `SA6001` | Missing an optimization opportunity when indexing maps by byte slices <br/> Map keys must be comparable, which precludes the use of byte slices. This usually leads to using string keys and converting byte slices to strings. <br/> Normally, a conversion of a byte slice to a string needs to copy the data and causes allocations. The compiler, however, recognizes m[string(b)] and uses the data of b directly, without copying it, because it knows that the data can't change during the map lookup. This leads to the counter-intuitive situation that <br/> k := string(b) println(m[k]) println(m[k]) <br/> will be less efficient than <br/> println(m[string(b)]) println(m[string(b)]) <br/> because the first version needs to copy and allocate, while the second one does not. <br/> For some history on this optimization, check out commit f5f5a8b6209f84961687d993b93ea0d397f5d5bf in the Go repository. <br/> Available since 2017.1 <br/> <br/> Default: `false` | @@ -933,6 +934,7 @@ | `SA9007` | Deleting a directory that shouldn't be deleted <br/> It is virtually never correct to delete system directories such as /tmp or the user's home directory. However, it can be fairly easy to do by mistake, for example by mistakenly using os.TempDir instead of ioutil.TempDir, or by forgetting to add a suffix to the result of os.UserHomeDir. <br/> Writing <br/> d := os.TempDir() defer os.RemoveAll(d) <br/> in your unit tests will have a devastating effect on the stability of your system. <br/> This check flags attempts at deleting the following directories: <br/> - os.TempDir - os.UserCacheDir - os.UserConfigDir - os.UserHomeDir <br/> Available since 2022.1 <br/> <br/> Default: `false` | | `SA9008` | else branch of a type assertion is probably not reading the right value <br/> When declaring variables as part of an if statement (like in 'if foo := ...; foo {'), the same variables will also be in the scope of the else branch. This means that in the following example <br/> if x, ok := x.(int); ok { // ... } else { fmt.Printf("unexpected type %T", x) } <br/> x in the else branch will refer to the x from x, ok :=; it will not refer to the x that is being type-asserted. The result of a failed type assertion is the zero value of the type that is being asserted to, so x in the else branch will always have the value 0 and the type int. <br/> Available since 2022.1 <br/> <br/> Default: `false` | | `SA9009` | Ineffectual Go compiler directive <br/> A potential Go compiler directive was found, but is ineffectual as it begins with whitespace. <br/> Available since 2024.1 <br/> <br/> Default: `true` | +| `SA9010` | Returned function should be called in defer <br/> If you have a function such as: <br/> func f() func() { // Do something. return func() { // Do something. } } <br/> Then calling that in defer: <br/> defer f() <br/> Is almost always a mistake, since you typically want to call the returned function: <br/> defer f()() <br/> Available since 2026.2 <br/> <br/> Default: `true` | | `ST1000` | Incorrect or missing package comment <br/> Packages must have a package comment that is formatted according to the guidelines laid out in https://go.dev/wiki/CodeReviewComments#package-comments. <br/> Available since 2019.1, non-default <br/> <br/> Default: `false` | | `ST1001` | Dot imports are discouraged <br/> Dot imports that aren't in external test packages are discouraged. <br/> The dot_import_whitelist option can be used to whitelist certain imports. <br/> Quoting Go Code Review Comments: <br/> > The import . form can be useful in tests that, due to circular > dependencies, cannot be made part of the package being tested: > > package foo_test > > import ( > "bar/testutil" // also imports "foo" > . "foo" > ) > > In this case, the test file cannot be in package foo because it > uses bar/testutil, which imports foo. So we use the import . > form to let the file pretend to be part of package foo even though > it is not. Except for this one case, do not use import . in your > programs. It makes the programs much harder to read because it is > unclear whether a name like Quux is a top-level identifier in the > current package or in an imported package. <br/> Available since 2019.1 <br/> Options dot_import_whitelist <br/> <br/> Default: `false` | | `ST1003` | Poorly chosen identifier <br/> Identifiers, such as variable and package names, follow certain rules. <br/> See the following links for details: <br/> - https://go.dev/doc/effective_go#package-names - https://go.dev/doc/effective_go#mixed-caps - https://go.dev/wiki/CodeReviewComments#initialisms - https://go.dev/wiki/CodeReviewComments#variable-names <br/> Available since 2019.1, non-default <br/> Options initialisms <br/> <br/> Default: `false` | @@ -971,8 +973,9 @@ | `directive` | check Go toolchain directives such as //go:debug <br/> This analyzer checks for problems with known Go toolchain directives in all Go source files in a package directory, even those excluded by //go:build constraints, and all non-Go source files too. <br/> For //go:debug (see https://go.dev/doc/godebug), the analyzer checks that the directives are placed only in Go source files, only above the package comment, and only in package main or *_test.go files. <br/> Support for other known directives may be added in the future. <br/> This analyzer does not check //go:build, which is handled by the buildtag analyzer. <br/> <br/> Default: `true` | | `embed` | check //go:embed directive usage <br/> This analyzer checks that the embed package is imported if //go:embed directives are present, providing a suggested fix to add the import if it is missing. <br/> This analyzer also checks that //go:embed directives precede the declaration of a single variable. <br/> Default: `true` | | `embedlit` | simplify references to embedded fields in composite literals <br/> The embedlit analyzer suggests removing redundant embedded field type specifiers from composite literals. Go1.27 introduced the ability to directly initialize fields promoted from embedded struct types without a nested literal. For example, given the following structs: <br/> <pre>type T struct {<br/> U<br/>}</pre><br/> <pre>type U struct {<br/> x int<br/>}</pre><br/> A composite literal such as <br/> <pre>t := T{U: U{x: 1}}</pre><br/> would become <br/> <pre>t := T{x: 1}</pre><br/> Default: `true` | -| `errorsas` | report passing non-pointer or non-error values to errors.As <br/> The errorsas analyzer reports calls to errors.As where the type of the second argument is not a pointer to a type implementing error. For example: <br/> <pre>var unwrappedErr net.DNSError<br/>errors.As(err, unwrappedErr) // should use &unwrappedErr, DNSError.Error has a pointer reciever</pre><br/> <br/> Default: `true` | -| `errorsastype` | Reports misuse of errors.AsType[T] in if/else chains. For example: <br/> <pre>err := f()<br/>if err, ok := errors.AsType[*FooErr](err); ok {<br/> useFoo(err)<br/>} else if err, ok := errors.AsType[*BarErr](err); ok {<br/> useBar(err)<br/>}</pre><br/> In this case, the second call to errors.AsType does not operate on the original error. Instead, its operand is the zero value of type *FooErr produced by the first if statement; this is invariably a mistake. <br/> <br/> Default: `true` | +| `errorsas` | report passing non-pointer or non-error values to errors.As <br/> The errorsas analyzer reports calls to errors.As where the type of the second argument is not a pointer to a type implementing error. For example: <br/> <pre>var unwrappedErr net.DNSError<br/>errors.As(err, unwrappedErr) // should use &unwrappedErr, DNSError.Error has a pointer receiver</pre><br/> <br/> Default: `true` | +| `errorsastype` | replace errors.As with errors.AsType[T] <br/> This analyzer suggests fixes to simplify uses of [errors.As] of this form: <br/> <pre>var myerr *MyErr<br/>if errors.As(err, &myerr) {<br/> handle(myerr)<br/>}</pre><br/> by using the less error-prone generic [errors.AsType] function, introduced in Go 1.26: <br/> <pre>if myerr, ok := errors.AsType[*MyErr](err); ok {<br/> handle(myerr)<br/>}</pre><br/> The fix is only offered if the var declaration has the form shown and there are no uses of myerr outside the if statement. <br/> Default: `true` | +| `errorsastypeshadow` | report shadowing of errors.AsType[T] in if/else chains <br/> For example: <br/> <pre>err := f()<br/>if err, ok := errors.AsType[*FooErr](err); ok {<br/> useFoo(err)<br/>} else if err, ok := errors.AsType[*BarErr](err); ok {<br/> useBar(err)<br/>}</pre><br/> In this case, the second call to errors.AsType does not operate on the original error. Instead, its operand is the zero value of type *FooErr produced by the first if statement; this is invariably a mistake. <br/> Default: `true` | | `fieldalignment` | find structs that would use less memory if their fields were sorted <br/> This analyzer finds structs that can be rearranged to use less memory, and provides a suggested edit with the most compact order. <br/> Note that there are two different diagnostics reported. One checks struct size, and the other reports "pointer bytes" used. Pointer bytes is how many bytes of the object that the garbage collector has to potentially scan for pointers, for example: <br/> <pre>struct { uint32; string }</pre><br/> have 16 pointer bytes because the garbage collector has to scan up through the string's inner pointer. <br/> <pre>struct { string; *uint32 }</pre><br/> has 24 pointer bytes because it has to scan further through the *uint32. <br/> <pre>struct { string; uint32 }</pre><br/> has 8 because it can stop immediately after the string pointer. <br/> Be aware that the most compact order is not always the most efficient. In rare cases it may cause two variables each updated by its own goroutine to occupy the same CPU cache line, inducing a form of memory contention known as "false sharing" that slows down both goroutines. <br/> Unlike most analyzers, which report likely mistakes, the diagnostics produced by fieldanalyzer very rarely indicate a significant problem, so the analyzer is not included in typical suites such as vet or gopls. Use this standalone command to run it on your code: <br/> $ go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest $ fieldalignment [packages] <br/> <br/> <br/> Default: `false` | | `fillreturns` | suggest fixes for errors due to an incorrect number of return values <br/> This checker provides suggested fixes for type errors of the type "wrong number of return values (want %d, got %d)". For example: <br/> <pre>func m() (int, string, *bool, error) {<br/> return<br/>}</pre><br/> will turn into <br/> <pre>func m() (int, string, *bool, error) {<br/> return 0, "", nil, nil<br/>}</pre><br/> This functionality is similar to https://github.com/sqs/goreturns. <br/> Default: `true` | | `fmtappendf` | replace []byte(fmt.Sprintf) with fmt.Appendf <br/> The fmtappendf analyzer suggests replacing `[]byte(fmt.Sprintf(...))` with `fmt.Appendf(nil, ...)`. This avoids the intermediate allocation of a string by Sprintf, making the code more efficient. The suggestion also applies to fmt.Sprint and fmt.Sprintln. <br/> Since its fix is not a Pareto improvement, fmtappendf is disabled by default in the `go fix` analyzer suite; see golang/go#77581. <br/> Default: `true` | @@ -982,7 +985,7 @@ | `httpresponse` | check for mistakes using HTTP responses <br/> A common mistake when using the net/http package is to defer a function call to close the http.Response Body before checking the error that determines whether the response is valid: <br/> <pre>resp, err := http.Head(url)<br/>defer resp.Body.Close()<br/>if err != nil {<br/> log.Fatal(err)<br/>}<br/>// (defer statement belongs here)</pre><br/> This checker helps uncover latent nil dereference bugs by reporting a diagnostic for such mistakes. <br/> Default: `true` | | `ifaceassert` | detect impossible interface-to-interface type assertions <br/> This checker flags type assertions v.(T) and corresponding type-switch cases in which the static type V of v is an interface that cannot possibly implement the target interface T. This occurs when V and T contain methods with the same name but different signatures. Example: <br/> <pre>var v interface {<br/> Read()<br/>}<br/>_ = v.(io.Reader)</pre><br/> The Read method in v has a different signature than the Read method in io.Reader, so this assertion cannot succeed. <br/> Default: `true` | | `infertypeargs` | check for unnecessary type arguments in call expressions <br/> Explicit type arguments may be omitted from call expressions if they can be inferred from function arguments, or from other type arguments: <br/> <pre>func f[T any](T) {}<br/><br/><br/>func _() {<br/> f[string]("foo") // string could be inferred<br/>}</pre><br/> <br/> Default: `true` | -| `inline` | apply fixes based on 'go:fix inline' comment directives <br/> The inline analyzer inlines functions and constants that are marked for inlining. <br/> ## Functions <br/> Given a function that is marked for inlining, like this one: <br/> <pre>//go:fix inline<br/>func Square(x int) int { return Pow(x, 2) }</pre><br/> this analyzer will recommend that calls to the function elsewhere, in the same or other packages, should be inlined. <br/> Inlining can be used to move off of a deprecated function: <br/> <pre>// Deprecated: prefer Pow(x, 2).<br/>//go:fix inline<br/>func Square(x int) int { return Pow(x, 2) }</pre><br/> It can also be used to move off of an obsolete package, as when the import path has changed or a higher major version is available: <br/> <pre>package pkg</pre><br/> <pre>import pkg2 "pkg/v2"</pre><br/> <pre>//go:fix inline<br/>func F() { pkg2.F(nil) }</pre><br/> Replacing a call pkg.F() by pkg2.F(nil) can have no effect on the program, so this mechanism provides a low-risk way to update large numbers of calls. We recommend, where possible, expressing the old API in terms of the new one to enable automatic migration. <br/> The inliner takes care to avoid behavior changes, even subtle ones, such as changes to the order in which argument expressions are evaluated. When it cannot safely eliminate all parameter variables, it may introduce a "binding declaration" of the form <br/> <pre>var params = args</pre><br/> to evaluate argument expressions in the correct order and bind them to parameter variables. Since the resulting code transformation may be stylistically suboptimal, such inlinings may be disabled by specifying the -inline.allow_binding_decl=false flag to the analyzer driver. <br/> (In cases where it is not safe to "reduce" a call—that is, to replace a call f(x) by the body of function f, suitably substituted—the inliner machinery is capable of replacing f by a function literal, func(){...}(). However, the inline analyzer discards all such "literalizations" unconditionally, again on grounds of style.) <br/> ## Constants <br/> Given a constant that is marked for inlining, like this one: <br/> <pre>//go:fix inline<br/>const Ptr = Pointer</pre><br/> this analyzer will recommend that uses of Ptr should be replaced with Pointer. <br/> As with functions, inlining can be used to replace deprecated constants and constants in obsolete packages. <br/> A constant definition can be marked for inlining only if it refers to another named constant. <br/> The "//go:fix inline" comment must appear before a single const declaration on its own, as above; before a const declaration that is part of a group, as in this case: <br/> <pre>const (<br/> C = 1<br/> //go:fix inline<br/> Ptr = Pointer<br/>)</pre><br/> or before a group, applying to every constant in the group: <br/> <pre>//go:fix inline<br/>const (<br/> Ptr = Pointer<br/> Val = Value<br/>)</pre><br/> The proposal https://go.dev/issue/32816 introduces the "//go:fix inline" directives. <br/> You can use this command to apply inline fixes en masse: <br/> <pre>$ go run golang.org/x/tools/go/analysis/passes/inline/cmd/inline@latest -fix ./...</pre><br/> Default: `true` | +| `inline` | apply fixes based on 'go:fix inline' comment directives <br/> The inline analyzer inlines functions, constants, and type aliases that are marked for inlining. <br/> Use this command to apply (just) inline fixes en masse: <br/> <pre>$ go fix -inline ./...</pre><br/> ## Functions <br/> Given a function that is marked for inlining, like this one: <br/> <pre>//go:fix inline<br/>func Square(x int) int { return Pow(x, 2) }</pre><br/> this analyzer will recommend that calls to the function elsewhere, in the same or other packages, should be inlined. <br/> Inlining can be used to move off of a deprecated function: <br/> <pre>// Deprecated: prefer Pow(x, 2).<br/>//go:fix inline<br/>func Square(x int) int { return Pow(x, 2) }</pre><br/> It can also be used to move off of an obsolete package, as when the import path has changed or a higher major version is available: <br/> <pre>package pkg</pre><br/> <pre>import pkg2 "pkg/v2"</pre><br/> <pre>//go:fix inline<br/>func F() { pkg2.F(nil) }</pre><br/> Replacing a call pkg.F() by pkg2.F(nil) can have no effect on the program, so this mechanism provides a low-risk way to update large numbers of calls. We recommend, where possible, expressing the old API in terms of the new one to enable automatic migration. <br/> The inliner takes care to avoid behavior changes, even subtle ones, such as changes to the order in which argument expressions are evaluated. When it cannot safely eliminate all parameter variables, it may introduce a "binding declaration" of the form <br/> <pre>var params = args</pre><br/> to evaluate argument expressions in the correct order and bind them to parameter variables. Since the resulting code transformation may be stylistically suboptimal, such inlinings may be disabled by specifying the -inline.allow_binding_decl=false flag to the analyzer driver. <br/> (In cases where it is not safe to "reduce" a call—that is, to replace a call f(x) by the body of function f, suitably substituted—the inliner machinery is capable of replacing f by a function literal, func(){...}(). However, the inline analyzer discards all such "literalizations" unconditionally, again on grounds of style.) <br/> ## Constants <br/> Given a constant that is marked for inlining, like this one: <br/> <pre>//go:fix inline<br/>const Ptr = Pointer</pre><br/> this analyzer will recommend that uses of Ptr should be replaced with Pointer. <br/> As with functions, inlining can be used to replace deprecated constants and constants in obsolete packages. <br/> A constant definition can be marked for inlining only if it refers to another named constant. <br/> The "//go:fix inline" comment must appear before a single const declaration on its own, as above; before a const declaration that is part of a group, as in this case: <br/> <pre>const (<br/> C = 1<br/> //go:fix inline<br/> Ptr = Pointer<br/>)</pre><br/> or before a group, applying to every constant in the group: <br/> <pre>//go:fix inline<br/>const (<br/> Ptr = Pointer<br/> Val = Value<br/>)</pre><br/> ## Type aliases <br/> Similar to named constants, a type alias can also be marked for inlining: <br/> <pre>//go:fix inline<br/>type A = newpkg.A</pre><br/> The analyzer will replace all references to the annotated type (A) by the type on the right-hand side of the declaration (newpkg.A). <br/> ## Tests <br/> A use of a function, named constant, or type alias X from its dedicated test (TestX), is not inlined, since the purpose of the test is to exercise X itself, even if it is deprecated and other uses of it should be inlined. This applies to benchmarks and examples too, and follows the usual conventions of test function naming. <br/> Similarly, if the symbol X is declared in a file named foo.go, any use of it within a file named foo_test.go will also not be inlined. <br/> Default: `true` | | `loopclosure` | check references to loop variables from within nested functions <br/> This analyzer reports places where a function literal references the iteration variable of an enclosing loop, and the loop calls the function in such a way (e.g. with go or defer) that it may outlive the loop iteration and possibly observe the wrong value of the variable. <br/> Note: An iteration variable can only outlive a loop iteration in Go versions <=1.21. In Go 1.22 and later, the loop variable lifetimes changed to create a new iteration variable per loop iteration. (See go.dev/issue/60078.) <br/> In this example, all the deferred functions run after the loop has completed, so all observe the final value of v [<go1.22]. <br/> <pre>for _, v := range list {<br/> defer func() {<br/> use(v) // incorrect<br/> }()<br/>}</pre><br/> One fix is to create a new variable for each iteration of the loop: <br/> <pre>for _, v := range list {<br/> v := v // new var per iteration<br/> defer func() {<br/> use(v) // ok<br/> }()<br/>}</pre><br/> After Go version 1.22, the previous two for loops are equivalent and both are correct. <br/> The next example uses a go statement and has a similar problem [<go1.22]. In addition, it has a data race because the loop updates v concurrent with the goroutines accessing it. <br/> <pre>for _, v := range elem {<br/> go func() {<br/> use(v) // incorrect, and a data race<br/> }()<br/>}</pre><br/> A fix is the same as before. The checker also reports problems in goroutines started by golang.org/x/sync/errgroup.Group. A hard-to-spot variant of this form is common in parallel tests: <br/> <pre>func Test(t *testing.T) {<br/> for _, test := range tests {<br/> t.Run(test.name, func(t *testing.T) {<br/> t.Parallel()<br/> use(test) // incorrect, and a data race<br/> })<br/> }<br/>}</pre><br/> The t.Parallel() call causes the rest of the function to execute concurrent with the loop [<go1.22]. <br/> The analyzer reports references only in the last statement, as it is not deep enough to understand the effects of subsequent statements that might render the reference benign. ("Last statement" is defined recursively in compound statements such as if, switch, and select.) <br/> See: https://golang.org/doc/go_faq.html#closures_and_goroutines <br/> Default: `true` | | `lostcancel` | check cancel func returned by context.WithCancel is called <br/> The cancellation function returned by context.WithCancel, WithTimeout, WithDeadline and variants such as WithCancelCause must be called, or the new context will remain live until its parent context is cancelled. (The background context is never cancelled.) <br/> Default: `true` | | `maprange` | checks for unnecessary calls to maps.Keys and maps.Values in range statements <br/> Consider a loop written like this: <br/> <pre>for val := range maps.Values(m) {<br/> fmt.Println(val)<br/>}</pre><br/> This should instead be written without the call to maps.Values: <br/> <pre>for _, val := range m {<br/> fmt.Println(val)<br/>}</pre><br/> golang.org/x/exp/maps returns slices for Keys/Values instead of iterators, but unnecessary calls should similarly be removed: <br/> <pre>for _, key := range maps.Keys(m) {<br/> fmt.Println(key)<br/>}</pre><br/> should be rewritten as: <br/> <pre>for key := range m {<br/> fmt.Println(key)<br/>}</pre><br/> Default: `true` | @@ -1006,11 +1009,13 @@ | `simplifycompositelit` | check for composite literal simplifications <br/> An array, slice, or map composite literal of the form: <br/> <pre>[]T{T{}, T{}}</pre><br/> will be simplified to: <br/> <pre>[]T{{}, {}}</pre><br/> This is one of the simplifications that "gofmt -s" applies. <br/> This analyzer ignores generated code. <br/> Default: `true` | | `simplifyrange` | check for range statement simplifications <br/> A range of the form: <br/> <pre>for x, _ = range v {...}</pre><br/> will be simplified to: <br/> <pre>for x = range v {...}</pre><br/> A range of the form: <br/> <pre>for _ = range v {...}</pre><br/> will be simplified to: <br/> <pre>for range v {...}</pre><br/> This is one of the simplifications that "gofmt -s" applies. <br/> This analyzer ignores generated code. <br/> Default: `true` | | `simplifyslice` | check for slice simplifications <br/> A slice expression of the form: <br/> <pre>s[a:len(s)]</pre><br/> will be simplified to: <br/> <pre>s[a:]</pre><br/> This is one of the simplifications that "gofmt -s" applies. <br/> This analyzer ignores generated code. <br/> Default: `true` | +| `slicesbackward` | replace backward loops over slices with slices.Backward <br/> The slicesbackward analyzer suggests replacing manually-written backward loops of the form <br/> <pre>for i := len(s) - 1; i >= 0; i-- {<br/> use(s[i])<br/>}</pre><br/> with the more readable Go 1.23 style using slices.Backward: <br/> <pre>for _, v := range slices.Backward(s) {<br/> use(v)<br/>}</pre><br/> If the loop index is needed beyond just indexing into the slice, both the index and value variables are kept: <br/> <pre>for i, v := range slices.Backward(s) { ... }</pre><br/> Default: `true` | | `slicescontains` | replace loops with slices.Contains or slices.ContainsFunc <br/> The slicescontains analyzer simplifies loops that check for the existence of an element in a slice. It replaces them with calls to `slices.Contains` or `slices.ContainsFunc`, which were added in Go 1.21. <br/> If the expression for the target element has side effects, this transformation will cause those effects to occur only once, not once per tested slice element. <br/> Default: `true` | | `slicesdelete` | replace append-based slice deletion with slices.Delete <br/> The slicesdelete analyzer suggests replacing the idiom <br/> <pre>s = append(s[:i], s[j:]...)</pre><br/> with the more explicit <br/> <pre>s = slices.Delete(s, i, j)</pre><br/> introduced in Go 1.21. <br/> This analyzer is disabled by default. The `slices.Delete` function zeros the elements between the new length and the old length of the slice to prevent memory leaks, which is a subtle difference in behavior compared to the append-based idiom; see https://go.dev/issue/73686. <br/> Default: `false` | | `slicessort` | replace sort.Slice with slices.Sort for basic types <br/> The slicessort analyzer simplifies sorting slices of basic ordered types. It replaces <br/> <pre>sort.Slice(s, func(i, j int) bool { return s[i] < s[j] })</pre><br/> with the simpler `slices.Sort(s)`, which was added in Go 1.21. <br/> Default: `true` | | `slog` | check for invalid structured logging calls <br/> The slog checker looks for calls to functions from the log/slog package that take alternating key-value pairs. It reports calls where an argument in a key position is neither a string nor a slog.Attr, and where a final key is missing its value. For example,it would report <br/> <pre>slog.Warn("message", 11, "k") // slog.Warn arg "11" should be a string or a slog.Attr</pre><br/> and <br/> <pre>slog.Info("message", "k1", v1, "k2") // call to slog.Info missing a final value</pre><br/> Default: `true` | | `sortslice` | check the argument type of sort.Slice <br/> sort.Slice requires an argument of a slice type. Check that the interface{} value passed to sort.Slice is actually a slice. <br/> Default: `true` | +| `sqlrowserr` | sqlrowserr: report failure to check sql.Rows.Err <br/> This analyzer reports uses of sql.Rows in which the result of a query such as db.Query() is assigned to a local variable that is then used in a loop that calls Rows.Next, but lacks a final check of Rows.Err. This causes row iteration errors to be discarded. <br/> For example: <br/> <pre>rows, err := db.Query("select ...") // error: "sql.Rows rows is used in Next loop without final check of rows.Err()"<br/>if err != nil {<br/> return err<br/>}<br/>defer rows.Close() // ignore error<br/>for rows.Next() {<br/> var x int<br/> if err := rows.Scan(&x); err != nil {<br/> return err<br/> }<br/> use(x)<br/>}<br/>/* ...no use of rows.Err()... */</pre><br/> Correct usage of sql.Rows demands both a call to Rows.Close to release resources and a call to Rows.Err to report iteration errors. It is not critical to report resource cleanup errors, but it is crucial to report iteration errors as they would otherwise be indistinguishable from a smaller result. <br/> To avoid false positives, the analyzer is silent if the Rows is passed into or out of the function or assigned somewhere other than a local variable. <br/> It is not this analyzer's goal to ensure proper handling of errors in all cases, but merely the simple mistakes where the user may have been oblivious to the existence of the Rows.Err method. <br/> <br/> Default: `true` | | `stditerators` | use iterators instead of Len/At-style APIs <br/> This analyzer suggests a fix to replace each loop of the form: <br/> <pre>for i := 0; i < x.Len(); i++ {<br/> use(x.At(i))<br/>}</pre><br/> or its "for elem := range x.Len()" equivalent by a range loop over an iterator offered by the same data type: <br/> <pre>for elem := range x.All() {<br/> use(x.At(i)<br/>}</pre><br/> where x is one of various well-known types in the standard library. <br/> Default: `true` | | `stdmethods` | check signature of methods of well-known interfaces <br/> Sometimes a type may be intended to satisfy an interface but may fail to do so because of a mistake in its method signature. For example, the result of this WriteTo method should be (int64, error), not error, to satisfy io.WriterTo: <br/> <pre>type myWriterTo struct{...}<br/>func (myWriterTo) WriteTo(w io.Writer) error { ... }</pre><br/> This check ensures that each method whose name matches one of several well-known interface methods from the standard library has the correct signature for that interface. <br/> Checked method names include: <br/> <pre>Format GobEncode GobDecode MarshalJSON MarshalXML<br/>Peek ReadByte ReadFrom ReadRune Scan Seek<br/>UnmarshalJSON UnreadByte UnreadRune WriteByte<br/>WriteTo</pre><br/> Default: `true` | | `stdversion` | report uses of too-new standard library symbols <br/> The stdversion analyzer reports references to symbols in the standard library that were introduced by a Go release higher than the one in force in the referring file. (Recall that the file's Go version is defined by the 'go' directive its module's go.mod file, or by a "//go:build go1.X" build tag at the top of the file.) <br/> The analyzer does not report a diagnostic for a reference to a "too new" field or method of a type that is itself "too new", as this may have false positives, for example if fields or methods are accessed through a type alias that is guarded by a Go version constraint. <br/> <br/> Default: `true` | @@ -1165,6 +1170,13 @@ Default: `true` +### `ui.moveType` + +(Experimental) moveType enables producing Move Type codeactions. The implementation +is unfinished so we use this setting to gate its use. + + +Default: `false` ### `ui.navigation.importShortcut` importShortcut specifies whether import statements should link to @@ -1276,7 +1288,18 @@ (Experimental) semanticTokens determines whether gopls will return a SemanticTokensProvider at initialization, or respond -to request for semantic tokens. +to requests for semantic tokens. + +This setting being `false` won't necessary disable the client's calls +for semantic tokens. If you want that, it would need to be configured in +the client. For example, in VSCode, this would disable all Go semantic +token calls to the LSP server: + +```json5 +"[go]": { + "editor.semanticHighlighting.enabled": false, +} +``` Default: `false`
diff --git a/extension/package.json b/extension/package.json index 2114a4a..0c0222c 100644 --- a/extension/package.json +++ b/extension/package.json
@@ -2314,7 +2314,7 @@ }, "S1005": { "type": "boolean", - "markdownDescription": "Drop unnecessary use of the blank identifier\n\nIn many cases, assigning to the blank identifier is unnecessary.\n\nBefore:\n\n for _ = range s {}\n x, _ = someMap[key]\n _ = <-ch\n\nAfter:\n\n for range s{}\n x = someMap[key]\n <-ch\n\nAvailable since\n 2017.1\n", + "markdownDescription": "Drop unnecessary use of the blank identifier\n\nIn many cases, assigning to the blank identifier is unnecessary.\n\nBefore:\n\n for _ = range s {}\n _ = <-ch\n\nAfter:\n\n for range s{}\n <-ch\n\nAvailable since\n 2017.1\n", "default": false }, "S1006": { @@ -2474,7 +2474,7 @@ }, "SA1002": { "type": "boolean", - "markdownDescription": "Invalid format in time.Parse\n\nAvailable since\n 2017.1\n", + "markdownDescription": "Invalid format in time.Parse\n\ntime.Parse requires a layout string that uses Go's reference time:\n'Mon Jan 2 15:04:05 MST 2006'. The layout must represent this date and time\nexactly. See https://pkg.go.dev/time#pkg-constants for layout examples.\n\nAvailable since\n 2017.1\n", "default": false }, "SA1003": { @@ -2514,7 +2514,7 @@ }, "SA1012": { "type": "boolean", - "markdownDescription": "A nil context.Context is being passed to a function, consider using context.TODO instead\n\nAvailable since\n 2017.1\n", + "markdownDescription": "A nil context.Context is being passed to a function, consider using context.TODO instead\n\nThe context package prohibits the use of a nil context.\nIf no parent context is available, a new context should be used,\ne.g. context.TODO or context.Background.\n\nAvailable since\n 2017.1\n", "default": true }, "SA1013": { @@ -2524,7 +2524,7 @@ }, "SA1014": { "type": "boolean", - "markdownDescription": "Non-pointer value passed to Unmarshal or Decode\n\nAvailable since\n 2017.1\n", + "markdownDescription": "Non-pointer value passed to Unmarshal or Decode\n\nFunctions such as encoding/json.Unmarshal and\n(*encoding/json.Decoder).Decode require a pointer to the value that should\nbe populated. Passing a non-pointer value results in the function returning an\nerror at runtime, as it cannot modify the target value.\n\nAvailable since\n 2017.1\n", "default": false }, "SA1015": { @@ -2549,7 +2549,7 @@ }, "SA1020": { "type": "boolean", - "markdownDescription": "Using an invalid host:port pair with a net.Listen-related function\n\nAvailable since\n 2017.1\n", + "markdownDescription": "Using an invalid host:port pair with a net.Listen-related function\n\nFunctions such as net.Listen, net.ListenTCP, and similar,\nexpect a valid network address in the form of host:port. The host, the port,\nor both, can be omitted, e.g. localhost:8080, :8080 or : are valid\nhost:port pairs.\nSee https://pkg.go.dev/net#Listen for the full documentation.\n\nAvailable since\n 2017.1\n", "default": false }, "SA1021": { @@ -2619,7 +2619,7 @@ }, "SA2003": { "type": "boolean", - "markdownDescription": "Deferred Lock right after locking, likely meant to defer Unlock instead\n\nAvailable since\n 2017.1\n", + "markdownDescription": "Deferred Lock right after locking, likely meant to defer Unlock instead\n\nDeferring a call to Lock immediately after locking is almost always\na typo. For example:\n\n mu.Lock()\n defer mu.Lock()\n\nWhile this does not strictly guarantee a deadlock depending on how the\nsurrounding code is structured, it is highly likely to be a mistake.\nThe intended code was likely this:\n\n mu.Lock()\n defer mu.Unlock()\n\nAvailable since\n 2017.1\n", "default": false }, "SA3000": { @@ -2674,7 +2674,7 @@ }, "SA4010": { "type": "boolean", - "markdownDescription": "The result of append will never be observed anywhere\n\nAvailable since\n 2017.1\n", + "markdownDescription": "The result of append will never be observed anywhere\n\nCalls to append produce a new slice value. When the result of\nappend is assigned to a variable that is never subsequently read, the\nappend operation may have an unintended effect.\n\nAvailable since\n 2017.1\n", "default": false }, "SA4011": { @@ -2827,11 +2827,6 @@ "markdownDescription": "Impossible type assertion\n\nSome type assertions can be statically proven to be\nimpossible. This is the case when the method sets of both\narguments of the type assertion conflict with each other, for\nexample by containing the same method with different\nsignatures.\n\nThe Go compiler already applies this check when asserting from an\ninterface value to a concrete type. If the concrete type misses\nmethods from the interface, or if function signatures don't match,\nthen the type assertion can never succeed.\n\nThis check applies the same logic when asserting from one interface to\nanother. If both interface types contain the same method but with\ndifferent signatures, then the type assertion can never succeed,\neither.\n\nAvailable since\n 2020.1\n", "default": false }, - "SA5011": { - "type": "boolean", - "markdownDescription": "Possible nil pointer dereference\n\nA pointer is being dereferenced unconditionally, while\nalso being checked against nil in another place. This suggests that\nthe pointer may be nil and dereferencing it may panic. This is\ncommonly a result of improperly ordered code or missing return\nstatements. Consider the following examples:\n\n func fn(x *int) {\n fmt.Println(*x)\n\n // This nil check is equally important for the previous dereference\n if x != nil {\n foo(*x)\n }\n }\n\n func TestFoo(t *testing.T) {\n x := compute()\n if x == nil {\n t.Errorf(\"nil pointer received\")\n }\n\n // t.Errorf does not abort the test, so if x is nil, the next line will panic.\n foo(*x)\n }\n\nStaticcheck tries to deduce which functions abort control flow.\nFor example, it is aware that a function will not continue\nexecution after a call to panic or log.Fatal. However, sometimes\nthis detection fails, in particular in the presence of\nconditionals. Consider the following example:\n\n func Log(msg string, level int) {\n fmt.Println(msg)\n if level == levelFatal {\n os.Exit(1)\n }\n }\n\n func Fatal(msg string) {\n Log(msg, levelFatal)\n }\n\n func fn(x *int) {\n if x == nil {\n Fatal(\"unexpected nil pointer\")\n }\n fmt.Println(*x)\n }\n\nStaticcheck will flag the dereference of x, even though it is perfectly\nsafe. Staticcheck is not able to deduce that a call to\nFatal will exit the program. For the time being, the easiest\nworkaround is to modify the definition of Fatal like so:\n\n func Fatal(msg string) {\n Log(msg, levelFatal)\n panic(\"unreachable\")\n }\n\nWe also hard-code functions from common logging packages such as\nlogrus. Please file an issue if we're missing support for a\npopular package.\n\nAvailable since\n 2020.1\n", - "default": false - }, "SA5012": { "type": "boolean", "markdownDescription": "Passing odd-sized slice to function expecting even size\n\nSome functions that take slices as parameters expect the slices to have an even number of elements. \nOften, these functions treat elements in a slice as pairs. \nFor example, strings.NewReplacer takes pairs of old and new strings, \nand calling it with an odd number of elements would be an error.\n\nAvailable since\n 2020.2\n", @@ -2912,6 +2907,11 @@ "markdownDescription": "Ineffectual Go compiler directive\n\nA potential Go compiler directive was found, but is ineffectual as it begins\nwith whitespace.\n\nAvailable since\n 2024.1\n", "default": true }, + "SA9010": { + "type": "boolean", + "markdownDescription": "Returned function should be called in defer\n\nIf you have a function such as:\n\n func f() func() {\n // Do something.\n return func() {\n // Do something.\n }\n }\n\nThen calling that in defer:\n\n defer f()\n\nIs almost always a mistake, since you typically want to call the returned\nfunction:\n\n defer f()()\n\nAvailable since\n 2026.2\n", + "default": true + }, "ST1000": { "type": "boolean", "markdownDescription": "Incorrect or missing package comment\n\nPackages must have a package comment that is formatted according to\nthe guidelines laid out in\nhttps://go.dev/wiki/CodeReviewComments#package-comments.\n\nAvailable since\n 2019.1, non-default\n", @@ -3104,12 +3104,17 @@ }, "errorsas": { "type": "boolean", - "markdownDescription": "report passing non-pointer or non-error values to errors.As\n\nThe errorsas analyzer reports calls to errors.As where the type\nof the second argument is not a pointer to a type implementing error.\nFor example:\n\n\tvar unwrappedErr net.DNSError\n\terrors.As(err, unwrappedErr) // should use &unwrappedErr, DNSError.Error has a pointer reciever\n", + "markdownDescription": "report passing non-pointer or non-error values to errors.As\n\nThe errorsas analyzer reports calls to errors.As where the type\nof the second argument is not a pointer to a type implementing error.\nFor example:\n\n\tvar unwrappedErr net.DNSError\n\terrors.As(err, unwrappedErr) // should use &unwrappedErr, DNSError.Error has a pointer receiver\n", "default": true }, "errorsastype": { "type": "boolean", - "markdownDescription": "Reports misuse of errors.AsType[T] in if/else chains.\nFor example:\n\n\terr := f()\n\tif err, ok := errors.AsType[*FooErr](err); ok {\n\t useFoo(err)\n\t} else if err, ok := errors.AsType[*BarErr](err); ok {\n\t useBar(err)\n\t}\n\nIn this case, the second call to errors.AsType does not operate on the\noriginal error. Instead, its operand is the zero value of type *FooErr\nproduced by the first if statement; this is invariably a mistake.\n", + "markdownDescription": "replace errors.As with errors.AsType[T]\n\nThis analyzer suggests fixes to simplify uses of [errors.As] of\nthis form:\n\n\tvar myerr *MyErr\n\tif errors.As(err, &myerr) {\n\t\thandle(myerr)\n\t}\n\nby using the less error-prone generic [errors.AsType] function,\nintroduced in Go 1.26:\n\n\tif myerr, ok := errors.AsType[*MyErr](err); ok {\n\t\thandle(myerr)\n\t}\n\nThe fix is only offered if the var declaration has the form shown and\nthere are no uses of myerr outside the if statement.", + "default": true + }, + "errorsastypeshadow": { + "type": "boolean", + "markdownDescription": "report shadowing of errors.AsType[T] in if/else chains\n\nFor example:\n\n\terr := f()\n\tif err, ok := errors.AsType[*FooErr](err); ok {\n\t useFoo(err)\n\t} else if err, ok := errors.AsType[*BarErr](err); ok {\n\t useBar(err)\n\t}\n\nIn this case, the second call to errors.AsType does not operate on the\noriginal error. Instead, its operand is the zero value of type *FooErr\nproduced by the first if statement; this is invariably a mistake.", "default": true }, "fieldalignment": { @@ -3159,7 +3164,7 @@ }, "inline": { "type": "boolean", - "markdownDescription": "apply fixes based on 'go:fix inline' comment directives\n\nThe inline analyzer inlines functions and constants that are marked for inlining.\n\n## Functions\n\nGiven a function that is marked for inlining, like this one:\n\n\t//go:fix inline\n\tfunc Square(x int) int { return Pow(x, 2) }\n\nthis analyzer will recommend that calls to the function elsewhere, in the same\nor other packages, should be inlined.\n\nInlining can be used to move off of a deprecated function:\n\n\t// Deprecated: prefer Pow(x, 2).\n\t//go:fix inline\n\tfunc Square(x int) int { return Pow(x, 2) }\n\nIt can also be used to move off of an obsolete package,\nas when the import path has changed or a higher major version is available:\n\n\tpackage pkg\n\n\timport pkg2 \"pkg/v2\"\n\n\t//go:fix inline\n\tfunc F() { pkg2.F(nil) }\n\nReplacing a call pkg.F() by pkg2.F(nil) can have no effect on the program,\nso this mechanism provides a low-risk way to update large numbers of calls.\nWe recommend, where possible, expressing the old API in terms of the new one\nto enable automatic migration.\n\nThe inliner takes care to avoid behavior changes, even subtle ones,\nsuch as changes to the order in which argument expressions are\nevaluated. When it cannot safely eliminate all parameter variables,\nit may introduce a \"binding declaration\" of the form\n\n\tvar params = args\n\nto evaluate argument expressions in the correct order and bind them to\nparameter variables. Since the resulting code transformation may be\nstylistically suboptimal, such inlinings may be disabled by specifying\nthe -inline.allow_binding_decl=false flag to the analyzer driver.\n\n(In cases where it is not safe to \"reduce\" a call—that is, to replace\na call f(x) by the body of function f, suitably substituted—the\ninliner machinery is capable of replacing f by a function literal,\nfunc(){...}(). However, the inline analyzer discards all such\n\"literalizations\" unconditionally, again on grounds of style.)\n\n## Constants\n\nGiven a constant that is marked for inlining, like this one:\n\n\t//go:fix inline\n\tconst Ptr = Pointer\n\nthis analyzer will recommend that uses of Ptr should be replaced with Pointer.\n\nAs with functions, inlining can be used to replace deprecated constants and\nconstants in obsolete packages.\n\nA constant definition can be marked for inlining only if it refers to another\nnamed constant.\n\nThe \"//go:fix inline\" comment must appear before a single const declaration on its own,\nas above; before a const declaration that is part of a group, as in this case:\n\n\tconst (\n\t C = 1\n\t //go:fix inline\n\t Ptr = Pointer\n\t)\n\nor before a group, applying to every constant in the group:\n\n\t//go:fix inline\n\tconst (\n\t\tPtr = Pointer\n\t Val = Value\n\t)\n\nThe proposal https://go.dev/issue/32816 introduces the \"//go:fix inline\" directives.\n\nYou can use this command to apply inline fixes en masse:\n\n\t$ go run golang.org/x/tools/go/analysis/passes/inline/cmd/inline@latest -fix ./...", + "markdownDescription": "apply fixes based on 'go:fix inline' comment directives\n\nThe inline analyzer inlines functions, constants, and type aliases\nthat are marked for inlining.\n\nUse this command to apply (just) inline fixes en masse:\n\n\t$ go fix -inline ./...\n\n## Functions\n\nGiven a function that is marked for inlining, like this one:\n\n\t//go:fix inline\n\tfunc Square(x int) int { return Pow(x, 2) }\n\nthis analyzer will recommend that calls to the function elsewhere, in the same\nor other packages, should be inlined.\n\nInlining can be used to move off of a deprecated function:\n\n\t// Deprecated: prefer Pow(x, 2).\n\t//go:fix inline\n\tfunc Square(x int) int { return Pow(x, 2) }\n\nIt can also be used to move off of an obsolete package,\nas when the import path has changed or a higher major version is available:\n\n\tpackage pkg\n\n\timport pkg2 \"pkg/v2\"\n\n\t//go:fix inline\n\tfunc F() { pkg2.F(nil) }\n\nReplacing a call pkg.F() by pkg2.F(nil) can have no effect on the program,\nso this mechanism provides a low-risk way to update large numbers of calls.\nWe recommend, where possible, expressing the old API in terms of the new one\nto enable automatic migration.\n\nThe inliner takes care to avoid behavior changes, even subtle ones,\nsuch as changes to the order in which argument expressions are\nevaluated. When it cannot safely eliminate all parameter variables,\nit may introduce a \"binding declaration\" of the form\n\n\tvar params = args\n\nto evaluate argument expressions in the correct order and bind them to\nparameter variables. Since the resulting code transformation may be\nstylistically suboptimal, such inlinings may be disabled by specifying\nthe -inline.allow_binding_decl=false flag to the analyzer driver.\n\n(In cases where it is not safe to \"reduce\" a call—that is, to replace\na call f(x) by the body of function f, suitably substituted—the\ninliner machinery is capable of replacing f by a function literal,\nfunc(){...}(). However, the inline analyzer discards all such\n\"literalizations\" unconditionally, again on grounds of style.)\n\n## Constants\n\nGiven a constant that is marked for inlining, like this one:\n\n\t//go:fix inline\n\tconst Ptr = Pointer\n\nthis analyzer will recommend that uses of Ptr should be replaced with Pointer.\n\nAs with functions, inlining can be used to replace deprecated constants and\nconstants in obsolete packages.\n\nA constant definition can be marked for inlining only if it refers to another\nnamed constant.\n\nThe \"//go:fix inline\" comment must appear before a single const declaration on its own,\nas above; before a const declaration that is part of a group, as in this case:\n\n\tconst (\n\t C = 1\n\t //go:fix inline\n\t Ptr = Pointer\n\t)\n\nor before a group, applying to every constant in the group:\n\n\t//go:fix inline\n\tconst (\n\t\tPtr = Pointer\n\t\tVal = Value\n\t)\n\n## Type aliases\n\nSimilar to named constants, a type alias can also be marked for inlining:\n\n\t//go:fix inline\n\ttype A = newpkg.A\n\nThe analyzer will replace all references to the annotated type\n(A) by the type on the right-hand side of the declaration (newpkg.A).\n\n## Tests\n\nA use of a function, named constant, or type alias X from its\ndedicated test (TestX), is not inlined, since the purpose of the test\nis to exercise X itself, even if it is deprecated and other uses of it\nshould be inlined.\nThis applies to benchmarks and examples too, and follows the usual\nconventions of test function naming.\n\nSimilarly, if the symbol X is declared in a file named foo.go, any use\nof it within a file named foo_test.go will also not be inlined.", "default": true }, "loopclosure": { @@ -3277,6 +3282,11 @@ "markdownDescription": "check for slice simplifications\n\nA slice expression of the form:\n\n\ts[a:len(s)]\n\nwill be simplified to:\n\n\ts[a:]\n\nThis is one of the simplifications that \"gofmt -s\" applies.\n\nThis analyzer ignores generated code.", "default": true }, + "slicesbackward": { + "type": "boolean", + "markdownDescription": "replace backward loops over slices with slices.Backward\n\nThe slicesbackward analyzer suggests replacing manually-written backward\nloops of the form\n\n\tfor i := len(s) - 1; i >= 0; i-- {\n\t use(s[i])\n\t}\n\nwith the more readable Go 1.23 style using slices.Backward:\n\n\tfor _, v := range slices.Backward(s) {\n\t use(v)\n\t}\n\nIf the loop index is needed beyond just indexing into the slice, both\nthe index and value variables are kept:\n\n\tfor i, v := range slices.Backward(s) { ... }", + "default": true + }, "slicescontains": { "type": "boolean", "markdownDescription": "replace loops with slices.Contains or slices.ContainsFunc\n\nThe slicescontains analyzer simplifies loops that check for the existence of\nan element in a slice. It replaces them with calls to `slices.Contains` or\n`slices.ContainsFunc`, which were added in Go 1.21.\n\nIf the expression for the target element has side effects, this\ntransformation will cause those effects to occur only once, not\nonce per tested slice element.", @@ -3302,6 +3312,11 @@ "markdownDescription": "check the argument type of sort.Slice\n\nsort.Slice requires an argument of a slice type. Check that\nthe interface{} value passed to sort.Slice is actually a slice.", "default": true }, + "sqlrowserr": { + "type": "boolean", + "markdownDescription": "sqlrowserr: report failure to check sql.Rows.Err\n\nThis analyzer reports uses of sql.Rows in which the result of a query\nsuch as db.Query() is assigned to a local variable that is then used\nin a loop that calls Rows.Next, but lacks a final check of Rows.Err.\nThis causes row iteration errors to be discarded.\n\nFor example:\n\n\trows, err := db.Query(\"select ...\") // error: \"sql.Rows rows is used in Next loop without final check of rows.Err()\"\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer rows.Close() // ignore error\n\tfor rows.Next() {\n\t\tvar x int\n\t\tif err := rows.Scan(&x); err != nil {\n\t\t\treturn err\n\t\t}\n\t\tuse(x)\n\t}\n\t/* ...no use of rows.Err()... */\n\nCorrect usage of sql.Rows demands both a call to Rows.Close to release\nresources and a call to Rows.Err to report iteration errors. It is\nnot critical to report resource cleanup errors, but it is crucial to\nreport iteration errors as they would otherwise be indistinguishable\nfrom a smaller result.\n\nTo avoid false positives, the analyzer is silent if the Rows is passed\ninto or out of the function or assigned somewhere other than a local\nvariable.\n\nIt is not this analyzer's goal to ensure proper handling of errors in\nall cases, but merely the simple mistakes where the user may have been\noblivious to the existence of the Rows.Err method.\n", + "default": true + }, "stditerators": { "type": "boolean", "markdownDescription": "use iterators instead of Len/At-style APIs\n\nThis analyzer suggests a fix to replace each loop of the form:\n\n\tfor i := 0; i < x.Len(); i++ {\n\t\tuse(x.At(i))\n\t}\n\nor its \"for elem := range x.Len()\" equivalent by a range loop over an\niterator offered by the same data type:\n\n\tfor elem := range x.All() {\n\t\tuse(x.At(i)\n\t}\n\nwhere x is one of various well-known types in the standard library.", @@ -3544,6 +3559,12 @@ "default": true, "scope": "resource" }, + "ui.moveType": { + "type": "boolean", + "markdownDescription": "(Experimental) moveType enables producing Move Type codeactions. The implementation\nis unfinished so we use this setting to gate its use.\n", + "default": false, + "scope": "resource" + }, "ui.navigation.importShortcut": { "type": "string", "markdownDescription": "importShortcut specifies whether import statements should link to\ndocumentation or go to definitions.\n", @@ -3646,7 +3667,7 @@ }, "ui.semanticTokens": { "type": "boolean", - "markdownDescription": "(Experimental) semanticTokens determines whether gopls will return a\nSemanticTokensProvider at initialization, or respond\nto request for semantic tokens.\n", + "markdownDescription": "(Experimental) semanticTokens determines whether gopls will return a\nSemanticTokensProvider at initialization, or respond\nto requests for semantic tokens.\n\nThis setting being `false` won't necessary disable the client's calls\nfor semantic tokens. If you want that, it would need to be configured in\nthe client. For example, in VSCode, this would disable all Go semantic\ntoken calls to the LSP server:\n\n```json5\n\"[go]\": {\n \"editor.semanticHighlighting.enabled\": false,\n}\n```\n", "default": false, "scope": "resource" }, @@ -3676,42 +3697,42 @@ }, "go.inlayHints.assignVariableTypes": { "type": "boolean", - "markdownDescription": "`\"assignVariableTypes\"` controls inlay hints for variable types in assign statements:\n```go\n\ti/* int*/, j/* int*/ := 0, len(r)-1\n```\n", + "markdownDescription": "`\"assignVariableTypes\"` controls inlay hints for variable types in assign statements:\n```go\n\ti« int», j« int» := 0, len(r)-1\n```\n", "default": false }, "go.inlayHints.compositeLiteralFields": { "type": "boolean", - "markdownDescription": "`\"compositeLiteralFields\"` inlay hints for composite literal field names:\n```go\n\t{/*in: */\"Hello, world\", /*want: */\"dlrow ,olleH\"}\n```\n", + "markdownDescription": "`\"compositeLiteralFields\"` inlay hints for composite literal field names:\n```go\n\tPoint2D{«X: »1, «Y: »2}\n\n\tOuter{«Embedded.»Field: 0}\n```\n", "default": false }, "go.inlayHints.compositeLiteralTypes": { "type": "boolean", - "markdownDescription": "`\"compositeLiteralTypes\"` controls inlay hints for composite literal types:\n```go\n\tfor _, c := range []struct {\n\t\tin, want string\n\t}{\n\t\t/*struct{ in string; want string }*/{\"Hello, world\", \"dlrow ,olleH\"},\n\t}\n```\n", + "markdownDescription": "`\"compositeLiteralTypes\"` controls inlay hints for composite literal types:\n```go\n\tfor _, c := range []struct {\n\t\tin, want string\n\t}{\n\t\t«struct{ in string; want string }»{\"Hello, world\", \"dlrow ,olleH\"},\n\t}\n```\n", "default": false }, "go.inlayHints.constantValues": { "type": "boolean", - "markdownDescription": "`\"constantValues\"` controls inlay hints for constant values:\n```go\n\tconst (\n\t\tKindNone Kind = iota/* = 0*/\n\t\tKindPrint/* = 1*/\n\t\tKindPrintf/* = 2*/\n\t\tKindErrorf/* = 3*/\n\t)\n```\n", + "markdownDescription": "`\"constantValues\"` controls inlay hints for constant values:\n```go\n\tconst (\n\t\tKindNone Kind = iota« = 0»\n\t\tKindPrint« = 1»\n\t\tKindPrintf« = 2»\n\t\tKindErrorf« = 3»\n\t)\n```\n", "default": false }, "go.inlayHints.functionTypeParameters": { "type": "boolean", - "markdownDescription": "`\"functionTypeParameters\"` inlay hints for implicit type parameters on generic functions:\n```go\n\tmyFoo/*[int, string]*/(1, \"hello\")\n```\n", + "markdownDescription": "`\"functionTypeParameters\"` inlay hints for implicit type parameters on generic functions:\n```go\n\tmyFoo«[int, string]»(1, \"hello\")\n```\n", "default": false }, "go.inlayHints.parameterNames": { "type": "boolean", - "markdownDescription": "`\"parameterNames\"` controls inlay hints for parameter names:\n```go\n\tparseInt(/* str: */ \"123\", /* radix: */ 8)\n```\n", + "markdownDescription": "`\"parameterNames\"` controls inlay hints for parameter names:\n```go\n\tparseInt(« str: » \"123\", « radix: » 8)\n```\n", "default": false }, "go.inlayHints.rangeVariableTypes": { "type": "boolean", - "markdownDescription": "`\"rangeVariableTypes\"` controls inlay hints for variable types in range statements:\n```go\n\tfor k/* int*/, v/* string*/ := range []string{} {\n\t\tfmt.Println(k, v)\n\t}\n```\n", + "markdownDescription": "`\"rangeVariableTypes\"` controls inlay hints for variable types in range statements:\n```go\n\tfor k« int», v« string» := range []string{} {\n\t\tfmt.Println(k, v)\n\t}\n```\n", "default": false }, "go.inlayHints.ignoredError": { "type": "boolean", - "markdownDescription": "`\"ignoredError\"` inlay hints for implicitly discarded errors:\n```go\n\tf.Close() // ignore error\n```\nThis check inserts an `// ignore error` hint following any\nstatement that is a function call whose error result is\nimplicitly ignored.\n\nTo suppress the hint, write an actual comment containing\n\"ignore error\" following the call statement, or explicitly\nassign the result to a blank variable. A handful of common\nfunctions such as `fmt.Println` are excluded from the\ncheck.\n", + "markdownDescription": "`\"ignoredError\"` inlay hints for implicitly discarded errors:\n```go\n\tf.Close()« // ignore error»\n```\nThis check inserts an `// ignore error` hint following any\nstatement that is a function call whose error result is\nimplicitly ignored.\n\nTo suppress the hint, write an actual comment containing\n\"ignore error\" following the call statement, or explicitly\nassign the result to a blank variable. A handful of common\nfunctions such as `fmt.Println` are excluded from the\ncheck.\n", "default": false } }