16b751b6c6
This change makes the checklocks analyzer considerable more powerful, adding: * The ability to traverse complex structures, e.g. to have multiple nested fields as part of the annotation. * The ability to resolve simple anonymous functions and closures, and perform lock analysis across these invocations. This does not apply to closures that are passed elsewhere, since it is not possible to know the context in which they might be invoked. * The ability to annotate return values in addition to receivers and other parameters, with the same complex structures noted above. * Ignoring locking semantics for "fresh" objects, i.e. objects that are allocated in the local frame (typically a new-style function). * Sanity checking of locking state across block transitions and returns, to ensure that no unexpected locks are held. Note that initially, most of these findings are excluded by a comprehensive nogo.yaml. The findings that are included are fundamental lock violations. The changes here should be relatively low risk, minor refactorings to either include necessary annotations to simplify the code structure (in general removing closures in favor of methods) so that the analyzer can be easily track the lock state. This change additional includes two changes to nogo itself: * Sanity checking of all types to ensure that the binary and ast-derived types have a consistent objectpath, to prevent the bug above from occurring silently (and causing much confusion). This also requires a trick in order to ensure that serialized facts are consumable downstream. This can be removed with https://go-review.googlesource.com/c/tools/+/331789 merged. * A minor refactoring to isolation the objdump settings in its own package. This was originally used to implement the sanity check above, but this information is now being passed another way. The minor refactor is preserved however, since it cleans up the code slightly and is minimal risk. PiperOrigin-RevId: 382613300 |
||
|---|---|---|
| .. | ||
| check | ||
| filter | ||
| objdump | ||
| BUILD | ||
| README.md | ||
| analyzers.go | ||
| build.go | ||
| config-schema.json | ||
| config.go | ||
| defs.bzl | ||
| findings.go | ||
| nogo.go | ||
README.md
Extended "nogo" analysis
This package provides a build aspect that perform nogo analysis. This will be
automatically injected to all relevant libraries when using the default
go_binary and go_library rules.
It exists for several reasons.
-
The default
nogoprovided by bazel is insufficient with respect to the possibility of binary analysis. This package allows us to analyze the generated binary in addition to using the standard analyzers. -
The configuration provided in this package is much richer than the standard
nogoJSON blob. Specifically, it allows us to exclude specific structures from the composite rules (such as the Ranges that are common with the set types). -
The bazel version of
nogois run directly against thego_libraryandgo_binarytargets, meaning that any change to the configuration requires a rebuild from scratch (for some reason included all C++ source files in the process). Using an aspect is more efficient in this regard. -
The checks supported by this package are exported as tests, which makes it easier to reason about and plumb into the build system.
-
For uninteresting reasons, it is impossible to integrate the default
nogoanalyzer provided by bazel with internal Google tooling. To provide a consistent experience, this package allows those systems to be unified.
To use this package, import nogo_test from defs.bzl and add a single
dependency which is a go_binary or go_library rule.