golang.org/x/tools/gopls@v0.15.3/doc/analyzers.md (about) 1 # Analyzers 2 3 This document describes the analyzers that `gopls` uses inside the editor. 4 5 Details about how to enable/disable these analyses can be found 6 [here](settings.md#analyses). 7 8 <!-- BEGIN Analyzers: DO NOT MANUALLY EDIT THIS SECTION --> 9 ## **appends** 10 11 appends: check for missing values after append 12 13 This checker reports calls to append that pass 14 no values to be appended to the slice. 15 16 s := []string{"a", "b", "c"} 17 _ = append(s) 18 19 Such calls are always no-ops and often indicate an 20 underlying mistake. 21 22 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/appends) 23 24 **Enabled by default.** 25 26 ## **asmdecl** 27 28 asmdecl: report mismatches between assembly files and Go declarations 29 30 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/asmdecl) 31 32 **Enabled by default.** 33 34 ## **assign** 35 36 assign: check for useless assignments 37 38 This checker reports assignments of the form x = x or a[i] = a[i]. 39 These are almost always useless, and even when they aren't they are 40 usually a mistake. 41 42 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/assign) 43 44 **Enabled by default.** 45 46 ## **atomic** 47 48 atomic: check for common mistakes using the sync/atomic package 49 50 The atomic checker looks for assignment statements of the form: 51 52 x = atomic.AddUint64(&x, 1) 53 54 which are not atomic. 55 56 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/atomic) 57 58 **Enabled by default.** 59 60 ## **atomicalign** 61 62 atomicalign: check for non-64-bits-aligned arguments to sync/atomic functions 63 64 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/atomicalign) 65 66 **Enabled by default.** 67 68 ## **bools** 69 70 bools: check for common mistakes involving boolean operators 71 72 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/bools) 73 74 **Enabled by default.** 75 76 ## **buildtag** 77 78 buildtag: check //go:build and // +build directives 79 80 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/buildtag) 81 82 **Enabled by default.** 83 84 ## **cgocall** 85 86 cgocall: detect some violations of the cgo pointer passing rules 87 88 Check for invalid cgo pointer passing. 89 This looks for code that uses cgo to call C code passing values 90 whose types are almost always invalid according to the cgo pointer 91 sharing rules. 92 Specifically, it warns about attempts to pass a Go chan, map, func, 93 or slice to C, either directly, or via a pointer, array, or struct. 94 95 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/cgocall) 96 97 **Enabled by default.** 98 99 ## **composites** 100 101 composites: check for unkeyed composite literals 102 103 This analyzer reports a diagnostic for composite literals of struct 104 types imported from another package that do not use the field-keyed 105 syntax. Such literals are fragile because the addition of a new field 106 (even if unexported) to the struct will cause compilation to fail. 107 108 As an example, 109 110 err = &net.DNSConfigError{err} 111 112 should be replaced by: 113 114 err = &net.DNSConfigError{Err: err} 115 116 117 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/composite) 118 119 **Enabled by default.** 120 121 ## **copylocks** 122 123 copylocks: check for locks erroneously passed by value 124 125 Inadvertently copying a value containing a lock, such as sync.Mutex or 126 sync.WaitGroup, may cause both copies to malfunction. Generally such 127 values should be referred to through a pointer. 128 129 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/copylocks) 130 131 **Enabled by default.** 132 133 ## **deepequalerrors** 134 135 deepequalerrors: check for calls of reflect.DeepEqual on error values 136 137 The deepequalerrors checker looks for calls of the form: 138 139 reflect.DeepEqual(err1, err2) 140 141 where err1 and err2 are errors. Using reflect.DeepEqual to compare 142 errors is discouraged. 143 144 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/deepequalerrors) 145 146 **Enabled by default.** 147 148 ## **defers** 149 150 defers: report common mistakes in defer statements 151 152 The defers analyzer reports a diagnostic when a defer statement would 153 result in a non-deferred call to time.Since, as experience has shown 154 that this is nearly always a mistake. 155 156 For example: 157 158 start := time.Now() 159 ... 160 defer recordLatency(time.Since(start)) // error: call to time.Since is not deferred 161 162 The correct code is: 163 164 defer func() { recordLatency(time.Since(start)) }() 165 166 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/defers) 167 168 **Enabled by default.** 169 170 ## **deprecated** 171 172 deprecated: check for use of deprecated identifiers 173 174 The deprecated analyzer looks for deprecated symbols and package 175 imports. 176 177 See https://go.dev/wiki/Deprecated to learn about Go's convention 178 for documenting and signaling deprecated identifiers. 179 180 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/deprecated) 181 182 **Enabled by default.** 183 184 ## **directive** 185 186 directive: check Go toolchain directives such as //go:debug 187 188 This analyzer checks for problems with known Go toolchain directives 189 in all Go source files in a package directory, even those excluded by 190 //go:build constraints, and all non-Go source files too. 191 192 For //go:debug (see https://go.dev/doc/godebug), the analyzer checks 193 that the directives are placed only in Go source files, only above the 194 package comment, and only in package main or *_test.go files. 195 196 Support for other known directives may be added in the future. 197 198 This analyzer does not check //go:build, which is handled by the 199 buildtag analyzer. 200 201 202 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/directive) 203 204 **Enabled by default.** 205 206 ## **embed** 207 208 embed: check //go:embed directive usage 209 210 This analyzer checks that the embed package is imported if //go:embed 211 directives are present, providing a suggested fix to add the import if 212 it is missing. 213 214 This analyzer also checks that //go:embed directives precede the 215 declaration of a single variable. 216 217 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/embeddirective) 218 219 **Enabled by default.** 220 221 ## **errorsas** 222 223 errorsas: report passing non-pointer or non-error values to errors.As 224 225 The errorsas analysis reports calls to errors.As where the type 226 of the second argument is not a pointer to a type implementing error. 227 228 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/errorsas) 229 230 **Enabled by default.** 231 232 ## **fieldalignment** 233 234 fieldalignment: find structs that would use less memory if their fields were sorted 235 236 This analyzer find structs that can be rearranged to use less memory, and provides 237 a suggested edit with the most compact order. 238 239 Note that there are two different diagnostics reported. One checks struct size, 240 and the other reports "pointer bytes" used. Pointer bytes is how many bytes of the 241 object that the garbage collector has to potentially scan for pointers, for example: 242 243 struct { uint32; string } 244 245 have 16 pointer bytes because the garbage collector has to scan up through the string's 246 inner pointer. 247 248 struct { string; *uint32 } 249 250 has 24 pointer bytes because it has to scan further through the *uint32. 251 252 struct { string; uint32 } 253 254 has 8 because it can stop immediately after the string pointer. 255 256 Be aware that the most compact order is not always the most efficient. 257 In rare cases it may cause two variables each updated by its own goroutine 258 to occupy the same CPU cache line, inducing a form of memory contention 259 known as "false sharing" that slows down both goroutines. 260 261 262 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/fieldalignment) 263 264 **Disabled by default. Enable it by setting `"analyses": {"fieldalignment": true}`.** 265 266 ## **fillreturns** 267 268 fillreturns: suggest fixes for errors due to an incorrect number of return values 269 270 This checker provides suggested fixes for type errors of the 271 type "wrong number of return values (want %d, got %d)". For example: 272 273 func m() (int, string, *bool, error) { 274 return 275 } 276 277 will turn into 278 279 func m() (int, string, *bool, error) { 280 return 0, "", nil, nil 281 } 282 283 This functionality is similar to https://github.com/sqs/goreturns. 284 285 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/fillreturns) 286 287 **Enabled by default.** 288 289 ## **httpresponse** 290 291 httpresponse: check for mistakes using HTTP responses 292 293 A common mistake when using the net/http package is to defer a function 294 call to close the http.Response Body before checking the error that 295 determines whether the response is valid: 296 297 resp, err := http.Head(url) 298 defer resp.Body.Close() 299 if err != nil { 300 log.Fatal(err) 301 } 302 // (defer statement belongs here) 303 304 This checker helps uncover latent nil dereference bugs by reporting a 305 diagnostic for such mistakes. 306 307 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/httpresponse) 308 309 **Enabled by default.** 310 311 ## **ifaceassert** 312 313 ifaceassert: detect impossible interface-to-interface type assertions 314 315 This checker flags type assertions v.(T) and corresponding type-switch cases 316 in which the static type V of v is an interface that cannot possibly implement 317 the target interface T. This occurs when V and T contain methods with the same 318 name but different signatures. Example: 319 320 var v interface { 321 Read() 322 } 323 _ = v.(io.Reader) 324 325 The Read method in v has a different signature than the Read method in 326 io.Reader, so this assertion cannot succeed. 327 328 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/ifaceassert) 329 330 **Enabled by default.** 331 332 ## **infertypeargs** 333 334 infertypeargs: check for unnecessary type arguments in call expressions 335 336 Explicit type arguments may be omitted from call expressions if they can be 337 inferred from function arguments, or from other type arguments: 338 339 func f[T any](T) {} 340 341 func _() { 342 f[string]("foo") // string could be inferred 343 } 344 345 346 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/infertypeargs) 347 348 **Enabled by default.** 349 350 ## **loopclosure** 351 352 loopclosure: check references to loop variables from within nested functions 353 354 This analyzer reports places where a function literal references the 355 iteration variable of an enclosing loop, and the loop calls the function 356 in such a way (e.g. with go or defer) that it may outlive the loop 357 iteration and possibly observe the wrong value of the variable. 358 359 Note: An iteration variable can only outlive a loop iteration in Go versions <=1.21. 360 In Go 1.22 and later, the loop variable lifetimes changed to create a new 361 iteration variable per loop iteration. (See go.dev/issue/60078.) 362 363 In this example, all the deferred functions run after the loop has 364 completed, so all observe the final value of v [<go1.22]. 365 366 for _, v := range list { 367 defer func() { 368 use(v) // incorrect 369 }() 370 } 371 372 One fix is to create a new variable for each iteration of the loop: 373 374 for _, v := range list { 375 v := v // new var per iteration 376 defer func() { 377 use(v) // ok 378 }() 379 } 380 381 After Go version 1.22, the previous two for loops are equivalent 382 and both are correct. 383 384 The next example uses a go statement and has a similar problem [<go1.22]. 385 In addition, it has a data race because the loop updates v 386 concurrent with the goroutines accessing it. 387 388 for _, v := range elem { 389 go func() { 390 use(v) // incorrect, and a data race 391 }() 392 } 393 394 A fix is the same as before. The checker also reports problems 395 in goroutines started by golang.org/x/sync/errgroup.Group. 396 A hard-to-spot variant of this form is common in parallel tests: 397 398 func Test(t *testing.T) { 399 for _, test := range tests { 400 t.Run(test.name, func(t *testing.T) { 401 t.Parallel() 402 use(test) // incorrect, and a data race 403 }) 404 } 405 } 406 407 The t.Parallel() call causes the rest of the function to execute 408 concurrent with the loop [<go1.22]. 409 410 The analyzer reports references only in the last statement, 411 as it is not deep enough to understand the effects of subsequent 412 statements that might render the reference benign. 413 ("Last statement" is defined recursively in compound 414 statements such as if, switch, and select.) 415 416 See: https://golang.org/doc/go_faq.html#closures_and_goroutines 417 418 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/loopclosure) 419 420 **Enabled by default.** 421 422 ## **lostcancel** 423 424 lostcancel: check cancel func returned by context.WithCancel is called 425 426 The cancellation function returned by context.WithCancel, WithTimeout, 427 and WithDeadline must be called or the new context will remain live 428 until its parent context is cancelled. 429 (The background context is never cancelled.) 430 431 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/lostcancel) 432 433 **Enabled by default.** 434 435 ## **nilfunc** 436 437 nilfunc: check for useless comparisons between functions and nil 438 439 A useless comparison is one like f == nil as opposed to f() == nil. 440 441 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/nilfunc) 442 443 **Enabled by default.** 444 445 ## **nilness** 446 447 nilness: check for redundant or impossible nil comparisons 448 449 The nilness checker inspects the control-flow graph of each function in 450 a package and reports nil pointer dereferences, degenerate nil 451 pointers, and panics with nil values. A degenerate comparison is of the form 452 x==nil or x!=nil where x is statically known to be nil or non-nil. These are 453 often a mistake, especially in control flow related to errors. Panics with nil 454 values are checked because they are not detectable by 455 456 if r := recover(); r != nil { 457 458 This check reports conditions such as: 459 460 if f == nil { // impossible condition (f is a function) 461 } 462 463 and: 464 465 p := &v 466 ... 467 if p != nil { // tautological condition 468 } 469 470 and: 471 472 if p == nil { 473 print(*p) // nil dereference 474 } 475 476 and: 477 478 if p == nil { 479 panic(p) 480 } 481 482 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/nilness) 483 484 **Enabled by default.** 485 486 ## **nonewvars** 487 488 nonewvars: suggested fixes for "no new vars on left side of :=" 489 490 This checker provides suggested fixes for type errors of the 491 type "no new vars on left side of :=". For example: 492 493 z := 1 494 z := 2 495 496 will turn into 497 498 z := 1 499 z = 2 500 501 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/nonewvars) 502 503 **Enabled by default.** 504 505 ## **noresultvalues** 506 507 noresultvalues: suggested fixes for unexpected return values 508 509 This checker provides suggested fixes for type errors of the 510 type "no result values expected" or "too many return values". 511 For example: 512 513 func z() { return nil } 514 515 will turn into 516 517 func z() { return } 518 519 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/noresultvars) 520 521 **Enabled by default.** 522 523 ## **printf** 524 525 printf: check consistency of Printf format strings and arguments 526 527 The check applies to calls of the formatting functions such as 528 [fmt.Printf] and [fmt.Sprintf], as well as any detected wrappers of 529 those functions. 530 531 In this example, the %d format operator requires an integer operand: 532 533 fmt.Printf("%d", "hello") // fmt.Printf format %d has arg "hello" of wrong type string 534 535 See the documentation of the fmt package for the complete set of 536 format operators and their operand types. 537 538 To enable printf checking on a function that is not found by this 539 analyzer's heuristics (for example, because control is obscured by 540 dynamic method calls), insert a bogus call: 541 542 func MyPrintf(format string, args ...any) { 543 if false { 544 _ = fmt.Sprintf(format, args...) // enable printf checker 545 } 546 ... 547 } 548 549 The -funcs flag specifies a comma-separated list of names of additional 550 known formatting functions or methods. If the name contains a period, 551 it must denote a specific function using one of the following forms: 552 553 dir/pkg.Function 554 dir/pkg.Type.Method 555 (*dir/pkg.Type).Method 556 557 Otherwise the name is interpreted as a case-insensitive unqualified 558 identifier such as "errorf". Either way, if a listed name ends in f, the 559 function is assumed to be Printf-like, taking a format string before the 560 argument list. Otherwise it is assumed to be Print-like, taking a list 561 of arguments with no format string. 562 563 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/printf) 564 565 **Enabled by default.** 566 567 ## **shadow** 568 569 shadow: check for possible unintended shadowing of variables 570 571 This analyzer check for shadowed variables. 572 A shadowed variable is a variable declared in an inner scope 573 with the same name and type as a variable in an outer scope, 574 and where the outer variable is mentioned after the inner one 575 is declared. 576 577 (This definition can be refined; the module generates too many 578 false positives and is not yet enabled by default.) 579 580 For example: 581 582 func BadRead(f *os.File, buf []byte) error { 583 var err error 584 for { 585 n, err := f.Read(buf) // shadows the function variable 'err' 586 if err != nil { 587 break // causes return of wrong value 588 } 589 foo(buf) 590 } 591 return err 592 } 593 594 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/shadow) 595 596 **Disabled by default. Enable it by setting `"analyses": {"shadow": true}`.** 597 598 ## **shift** 599 600 shift: check for shifts that equal or exceed the width of the integer 601 602 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/shift) 603 604 **Enabled by default.** 605 606 ## **simplifycompositelit** 607 608 simplifycompositelit: check for composite literal simplifications 609 610 An array, slice, or map composite literal of the form: 611 612 []T{T{}, T{}} 613 614 will be simplified to: 615 616 []T{{}, {}} 617 618 This is one of the simplifications that "gofmt -s" applies. 619 620 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/simplifycompositelit) 621 622 **Enabled by default.** 623 624 ## **simplifyrange** 625 626 simplifyrange: check for range statement simplifications 627 628 A range of the form: 629 630 for x, _ = range v {...} 631 632 will be simplified to: 633 634 for x = range v {...} 635 636 A range of the form: 637 638 for _ = range v {...} 639 640 will be simplified to: 641 642 for range v {...} 643 644 This is one of the simplifications that "gofmt -s" applies. 645 646 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/simplifyrange) 647 648 **Enabled by default.** 649 650 ## **simplifyslice** 651 652 simplifyslice: check for slice simplifications 653 654 A slice expression of the form: 655 656 s[a:len(s)] 657 658 will be simplified to: 659 660 s[a:] 661 662 This is one of the simplifications that "gofmt -s" applies. 663 664 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/simplifyslice) 665 666 **Enabled by default.** 667 668 ## **slog** 669 670 slog: check for invalid structured logging calls 671 672 The slog checker looks for calls to functions from the log/slog 673 package that take alternating key-value pairs. It reports calls 674 where an argument in a key position is neither a string nor a 675 slog.Attr, and where a final key is missing its value. 676 For example,it would report 677 678 slog.Warn("message", 11, "k") // slog.Warn arg "11" should be a string or a slog.Attr 679 680 and 681 682 slog.Info("message", "k1", v1, "k2") // call to slog.Info missing a final value 683 684 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/slog) 685 686 **Enabled by default.** 687 688 ## **sortslice** 689 690 sortslice: check the argument type of sort.Slice 691 692 sort.Slice requires an argument of a slice type. Check that 693 the interface{} value passed to sort.Slice is actually a slice. 694 695 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/sortslice) 696 697 **Enabled by default.** 698 699 ## **stdmethods** 700 701 stdmethods: check signature of methods of well-known interfaces 702 703 Sometimes a type may be intended to satisfy an interface but may fail to 704 do so because of a mistake in its method signature. 705 For example, the result of this WriteTo method should be (int64, error), 706 not error, to satisfy io.WriterTo: 707 708 type myWriterTo struct{...} 709 func (myWriterTo) WriteTo(w io.Writer) error { ... } 710 711 This check ensures that each method whose name matches one of several 712 well-known interface methods from the standard library has the correct 713 signature for that interface. 714 715 Checked method names include: 716 717 Format GobEncode GobDecode MarshalJSON MarshalXML 718 Peek ReadByte ReadFrom ReadRune Scan Seek 719 UnmarshalJSON UnreadByte UnreadRune WriteByte 720 WriteTo 721 722 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/stdmethods) 723 724 **Enabled by default.** 725 726 ## **stringintconv** 727 728 stringintconv: check for string(int) conversions 729 730 This checker flags conversions of the form string(x) where x is an integer 731 (but not byte or rune) type. Such conversions are discouraged because they 732 return the UTF-8 representation of the Unicode code point x, and not a decimal 733 string representation of x as one might expect. Furthermore, if x denotes an 734 invalid code point, the conversion cannot be statically rejected. 735 736 For conversions that intend on using the code point, consider replacing them 737 with string(rune(x)). Otherwise, strconv.Itoa and its equivalents return the 738 string representation of the value in the desired base. 739 740 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/stringintconv) 741 742 **Enabled by default.** 743 744 ## **structtag** 745 746 structtag: check that struct field tags conform to reflect.StructTag.Get 747 748 Also report certain struct tags (json, xml) used with unexported fields. 749 750 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/structtag) 751 752 **Enabled by default.** 753 754 ## **stubmethods** 755 756 stubmethods: detect missing methods and fix with stub implementations 757 758 This analyzer detects type-checking errors due to missing methods 759 in assignments from concrete types to interface types, and offers 760 a suggested fix that will create a set of stub methods so that 761 the concrete type satisfies the interface. 762 763 For example, this function will not compile because the value 764 NegativeErr{} does not implement the "error" interface: 765 766 func sqrt(x float64) (float64, error) { 767 if x < 0 { 768 return 0, NegativeErr{} // error: missing method 769 } 770 ... 771 } 772 773 type NegativeErr struct{} 774 775 This analyzer will suggest a fix to declare this method: 776 777 // Error implements error.Error. 778 func (NegativeErr) Error() string { 779 panic("unimplemented") 780 } 781 782 (At least, it appears to behave that way, but technically it 783 doesn't use the SuggestedFix mechanism and the stub is created by 784 logic in gopls's golang.stub function.) 785 786 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/stubmethods) 787 788 **Enabled by default.** 789 790 ## **testinggoroutine** 791 792 testinggoroutine: report calls to (*testing.T).Fatal from goroutines started by a test 793 794 Functions that abruptly terminate a test, such as the Fatal, Fatalf, FailNow, and 795 Skip{,f,Now} methods of *testing.T, must be called from the test goroutine itself. 796 This checker detects calls to these functions that occur within a goroutine 797 started by the test. For example: 798 799 func TestFoo(t *testing.T) { 800 go func() { 801 t.Fatal("oops") // error: (*T).Fatal called from non-test goroutine 802 }() 803 } 804 805 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/testinggoroutine) 806 807 **Enabled by default.** 808 809 ## **tests** 810 811 tests: check for common mistaken usages of tests and examples 812 813 The tests checker walks Test, Benchmark, Fuzzing and Example functions checking 814 malformed names, wrong signatures and examples documenting non-existent 815 identifiers. 816 817 Please see the documentation for package testing in golang.org/pkg/testing 818 for the conventions that are enforced for Tests, Benchmarks, and Examples. 819 820 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/tests) 821 822 **Enabled by default.** 823 824 ## **timeformat** 825 826 timeformat: check for calls of (time.Time).Format or time.Parse with 2006-02-01 827 828 The timeformat checker looks for time formats with the 2006-02-01 (yyyy-dd-mm) 829 format. Internationally, "yyyy-dd-mm" does not occur in common calendar date 830 standards, and so it is more likely that 2006-01-02 (yyyy-mm-dd) was intended. 831 832 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/timeformat) 833 834 **Enabled by default.** 835 836 ## **undeclaredname** 837 838 undeclaredname: suggested fixes for "undeclared name: <>" 839 840 This checker provides suggested fixes for type errors of the 841 type "undeclared name: <>". It will either insert a new statement, 842 such as: 843 844 <> := 845 846 or a new function declaration, such as: 847 848 func <>(inferred parameters) { 849 panic("implement me!") 850 } 851 852 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/undeclaredname) 853 854 **Enabled by default.** 855 856 ## **unmarshal** 857 858 unmarshal: report passing non-pointer or non-interface values to unmarshal 859 860 The unmarshal analysis reports calls to functions such as json.Unmarshal 861 in which the argument type is not a pointer or an interface. 862 863 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/unmarshal) 864 865 **Enabled by default.** 866 867 ## **unreachable** 868 869 unreachable: check for unreachable code 870 871 The unreachable analyzer finds statements that execution can never reach 872 because they are preceded by an return statement, a call to panic, an 873 infinite loop, or similar constructs. 874 875 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/unreachable) 876 877 **Enabled by default.** 878 879 ## **unsafeptr** 880 881 unsafeptr: check for invalid conversions of uintptr to unsafe.Pointer 882 883 The unsafeptr analyzer reports likely incorrect uses of unsafe.Pointer 884 to convert integers to pointers. A conversion from uintptr to 885 unsafe.Pointer is invalid if it implies that there is a uintptr-typed 886 word in memory that holds a pointer value, because that word will be 887 invisible to stack copying and to the garbage collector. 888 889 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/unsafeptr) 890 891 **Enabled by default.** 892 893 ## **unusedparams** 894 895 unusedparams: check for unused parameters of functions 896 897 The unusedparams analyzer checks functions to see if there are 898 any parameters that are not being used. 899 900 To ensure soundness, it ignores: 901 - "address-taken" functions, that is, functions that are used as 902 a value rather than being called directly; their signatures may 903 be required to conform to a func type. 904 - exported functions or methods, since they may be address-taken 905 in another package. 906 - unexported methods whose name matches an interface method 907 declared in the same package, since the method's signature 908 may be required to conform to the interface type. 909 - functions with empty bodies, or containing just a call to panic. 910 - parameters that are unnamed, or named "_", the blank identifier. 911 912 The analyzer suggests a fix of replacing the parameter name by "_", 913 but in such cases a deeper fix can be obtained by invoking the 914 "Refactor: remove unused parameter" code action, which will 915 eliminate the parameter entirely, along with all corresponding 916 arguments at call sites, while taking care to preserve any side 917 effects in the argument expressions; see 918 https://github.com/golang/tools/releases/tag/gopls%2Fv0.14. 919 920 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/unusedparams) 921 922 **Enabled by default.** 923 924 ## **unusedresult** 925 926 unusedresult: check for unused results of calls to some functions 927 928 Some functions like fmt.Errorf return a result and have no side 929 effects, so it is always a mistake to discard the result. Other 930 functions may return an error that must not be ignored, or a cleanup 931 operation that must be called. This analyzer reports calls to 932 functions like these when the result of the call is ignored. 933 934 The set of functions may be controlled using flags. 935 936 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/unusedresult) 937 938 **Enabled by default.** 939 940 ## **unusedvariable** 941 942 unusedvariable: check for unused variables and suggest fixes 943 944 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/unusedvariable) 945 946 **Disabled by default. Enable it by setting `"analyses": {"unusedvariable": true}`.** 947 948 ## **unusedwrite** 949 950 unusedwrite: checks for unused writes 951 952 The analyzer reports instances of writes to struct fields and 953 arrays that are never read. Specifically, when a struct object 954 or an array is copied, its elements are copied implicitly by 955 the compiler, and any element write to this copy does nothing 956 with the original object. 957 958 For example: 959 960 type T struct { x int } 961 962 func f(input []T) { 963 for i, v := range input { // v is a copy 964 v.x = i // unused write to field x 965 } 966 } 967 968 Another example is about non-pointer receiver: 969 970 type T struct { x int } 971 972 func (t T) f() { // t is a copy 973 t.x = i // unused write to field x 974 } 975 976 [Full documentation](https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/unusedwrite) 977 978 **Disabled by default. Enable it by setting `"analyses": {"unusedwrite": true}`.** 979 980 ## **useany** 981 982 useany: check for constraints that could be simplified to "any" 983 984 [Full documentation](https://pkg.go.dev/golang.org/x/tools/gopls/internal/analysis/useany) 985 986 **Disabled by default. Enable it by setting `"analyses": {"useany": true}`.** 987 988 <!-- END Analyzers: DO NOT MANUALLY EDIT THIS SECTION -->