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:
Alan Donovan 2022-09-23 11:30:48 -04:00
parent eb25de6e2a
commit 49a686d2a2
1 changed files with 8 additions and 8 deletions

View File

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