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 -->