Paul Berry
26c90ed46b
Prior to this CL, the analyzer's set of unignorable diagnostic code names (`AnalysisOptionsImpl.unignorableDiagnosticCodeNames`) was constructed in the following way: - For each entry in the `cannot-ignore` section of the `analysis_options.yaml` file that matches the name of a severity code, the names of all diagnostic codes with matching severities were added (1). - All other entries in the `cannot-ignore` section were converted to upper case and then added (2). However, diagnostic codes associated with lints are named using `lower_snake_case`, while analyzer diagnonstic codes are named using `UPPER_SNAKE_CASE`. Some of the logic that consumed `AnalysisOptionsImpl.unignorableDiagnosticCodeNames` didn't account for this, resulting in some subtle bugs: - When the resolved correction producer base class `_BaseIgnoreDiagnostic` attempted to figure out if a diagnostic was unignorable, it compared elements of `unignorableDiagnosticCodeNames` to `DiagnosticCode.name`, which meant that it would successfully recognize non-lint codes as unignorable, but it would only recognize that a lint code was unignorable if it was included in `unignorableDiagnosticCodeNames` by putting the name of a severity in the `cannot-ignore` section of the `analysis_options.yaml` file. - When `LibraryAnalyzer._filterIgnoredDiagnostics` attempted to block unignorable diagnostics from being ignored, it compared elements of `unignorableDiagnosticCodeNames` to `DiagnosticCode.name`, `DiagnosticCode.uniqueName`, and `DiagnosticCode.name.toUpperCase()`. This worked, however the comparison to `DiagnosticCode.uniqueName` had no effect. Note that values of `DiagnosticCode.uniqueName` always take the form `ClassName.snake_case_diagnostic_code` or `ClassName.SNAKE_CASE_DIAGNOSTIC_CODE`. It's impossible for any of the values added to `AnalysisOptionsImpl.unignorableDiagnosticCodeNames` to ever match this, because (1) always adds values of `DiagnosticCode.name` (which never contains a `.`), and (2) always adds strings that have been converted to upper case. - When `IgnoreValidator.reportErrors` attempted to report unignorable and duplicate entries, it compared elements of `unignorableDiagnosticCodeNames` to `IgnoredDiagnosticName.name`, which is always lower case. That meant that it would only recognize that a diagnostic code was unignorable if the diagnostic code was associated with a lint and was included in `unignorableDiagnosticCodeNames` by putting the name of a severity in the `cannot-ignore` section of the `analysis_options.yaml` file. (Note, however, that this bug was unobservable because the reporting of the `unignorable_ignore` diagnostic is currently disabled; I will address this in a follow-up CL.) - Additionally, the logic to populate `AnalysisOptionsImpl.unignorableDiagnosticCodeNames` based on a severity code had a bug in its handling of error processors: if one or more error processors were used to change the severity of a diagnostic, then entries would be added to `AnalysisOptionsImpl.unignorableDiagnosticCodeNames` corresponding to both the original and the new severity. These buggy behaviors have been fixed by: - Streamlining and simplifying the logic that builds `AnalysisOptionsImpl.unignorableDiagnosticCodeNames`, and ensuring that all strings added to it are all lower case. - Changing all logic that checks whether a string is contained in `AnalysisOptionsImpl.unignorableDiagnosticCodeNames` so that it first converts that string to lower case. - Removing the ineffective logic in `LibraryAnalyzer._filterIgnoredDiagnostics` that attempted to compare elements of `unignorableDiagnosticCodeNames` to `DiagnosticCode.uniqueName`. Change-Id: I6a6a6964d89c139492dbb11d8ba3b2d33c0e2ee8 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462864 Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Paul Berry <paulberry@google.com>
analysis_server_plugin package
This package offers support for writing Dart analysis server plugins, for Dart 3.10 (Flutter 3.38) and later.
Analysis server plugins empower developers to contribute their own Dart static
analysis in IDEs and at the command line via dart analyze and flutter analyze. Analysis server plugins can offer the following static analyses:
- analysis rules, which report diagnostics in the IDE, and at the command line
- IDE quick fixes, which are local refactorings offered to users to correct a given diagnostic
- IDE quick assists, which are local refactorings that are offered at specific syntax nodes in code, but do not necessarily correct a static code issue
Review the following documents for how to write and how to use analysis server plugins: