mirror of https://github.com/golang/go.git
go/analysis: update explanation of (no) Diagnostics.Severity
The previous explanation from CL 230312 suggested that multiple Analyzers be used to distinguish severity levels, which is unwieldy to implement and sounds more like a workaround than a principle. I argue there is a principle here: that severity is best determined by the user, not the analyzer itself. This does require that drivers support some kind of filtering or ranking based on Analyzer.Name and Diagnostic.Category. Some already do; perhaps the unitchecker and multichecker drivers should too. Change-Id: I484877baf7963c444285f35c9f03ee3c5e6d7729 Reviewed-on: https://go-review.googlesource.com/c/tools/+/433536 Run-TryBot: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> gopls-CI: kokoro <noreply+kokoro@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
This commit is contained in:
parent
eb25de6e2a
commit
49a686d2a2
|
|
@ -177,14 +177,14 @@ Diagnostic is defined as:
|
|||
The optional Category field is a short identifier that classifies the
|
||||
kind of message when an analysis produces several kinds of diagnostic.
|
||||
|
||||
Many analyses want to associate diagnostics with a severity level.
|
||||
Because Diagnostic does not have a severity level field, an Analyzer's
|
||||
diagnostics effectively all have the same severity level. To separate which
|
||||
diagnostics are high severity and which are low severity, expose multiple
|
||||
Analyzers instead. Analyzers should also be separated when their
|
||||
diagnostics belong in different groups, or could be tagged differently
|
||||
before being shown to the end user. Analyzers should document their severity
|
||||
level to help downstream tools surface diagnostics properly.
|
||||
The Diagnostic struct does not have a field to indicate its severity
|
||||
because opinions about the relative importance of Analyzers and their
|
||||
diagnostics vary widely among users. The design of this framework does
|
||||
not hold each Analyzer responsible for identifying the severity of its
|
||||
diagnostics. Instead, we expect that drivers will allow the user to
|
||||
customize the filtering and prioritization of diagnostics based on the
|
||||
producing Analyzer and optional Category, according to the user's
|
||||
preferences.
|
||||
|
||||
Most Analyzers inspect typed Go syntax trees, but a few, such as asmdecl
|
||||
and buildtag, inspect the raw text of Go source files or even non-Go
|
||||
|
|
|
|||
Loading…
Reference in New Issue