From 49a686d2a23a20b8f98e6b0432b4c475d05e87c4 Mon Sep 17 00:00:00 2001 From: Alan Donovan Date: Fri, 23 Sep 2022 11:30:48 -0400 Subject: [PATCH] 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 TryBot-Result: Gopher Robot Reviewed-by: Hyang-Ah Hana Kim gopls-CI: kokoro Reviewed-by: Robert Findley --- go/analysis/doc.go | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/go/analysis/doc.go b/go/analysis/doc.go index 03c31525e3..2c49e33589 100644 --- a/go/analysis/doc.go +++ b/go/analysis/doc.go @@ -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