Changes the logic in `pkg/analyzer` to use
`DiagnosticCode.lowerCaseName` instead of `DiagnosticCode.name`, and
`DiagnosticCode.lowerCaseUniqueName` instead of
`DiagnosticCode.uniqueName`. This ensures that diagnostic codes are
matched in a case-insensitive fashion.
This paves the way for deprecating (and eventually removing) the
`DiagnosticCode.name` and `DiagnosticCode.uniqueName` getters.
Change-Id: I6a6a6964bae7f2d423e44211d2ad73202da65727
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466281
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Currently, diagnostic codes associated with lints are named using
`lower_snake_case`, while analyzer diagnonstic codes are named using
`UPPER_SNAKE_CASE`.
However, when the analyzer builds instances of the `ErrorProcessor`
class, it always uses `UPPER_SNAKE_CASE` names.
Some pieces of logic that matched up `ErrorProcessor`s to diagnostic
codes accounted for this difference; others didn't.
This led to a some buggy behaviors:
- If an instance of `ErrorProcessor` got constructed outside of the
analyzer (by an analyzer client using the analyzer public API), and
it supplied a `lower_snake_case` name, then
`ErrorProcessor.appliesTo` would only successfully match if the name
referred to a lint.
- The resolved correction producer base class `_BaseIgnoreDiagnostic`
(which forms the basis for the quick fixes "Ignore '...' in
`analysis_options.yaml`", "Ignore '...' for this line", and "Ignore
'...' for the whole file") would only notice that a diagnostic was
unignorable if the case matched exactly. In practice, this meant
that when operating on instances of `ErrorProcessor` created by the
analyzer, it wouldn't properly handle lints.
These buggy behaviors have been fixed by:
- Changing the `ErrorProcessor` constructor to always convert the
`code` to lower case.
- Changing all references to `ErrorProcessor.code` to assume lower
case.
Change-Id: I6a6a69645284f646e0c070fc2b55c4a90203d74a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462863
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
* OptionsValidator was defined in the `src/plugin/` directory (the only
file in there), which I found confusing. Moved it to
`src/analysis_options/`.
* OptionsFileValidator, and a few related classes, were defined in the
`src/task/` (the last file in there!), so I moved it to the same
place.
There is more to tidy in here, but this is a simple file-move.
Change-Id: I8f4c5cc0ae4e76eb6c17249457c50ab69c82590d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/443147
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Some of the parameters noted can be required and/or non-nullable as
per our internal usage, but this is all public API, so I'm just leaving
a note.
Mainly just simplify the implementation of ErrorProcessor.getProcessor.
Change-Id: Idebcf4a2485029c914d495cabfa3a1e98824c72c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396360
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
We rename `AnalyzerOptions` to `AnalysisFileOptions`, and change it's
comment from "`analyzer` analysis options constants." to avoid anyone
thinking it is specifying options for the `analyzer` section.
Additionally I privatize some of the static values that are only
present for validation - they are not meant to be used outside of
`options.dart`: `AnalyzerSection._trueOrFalse`,
`AnalyzerSection._options`, `AnalyzerSection._strongModeOptions`,
`AnalyzerSection._languageOptions`, `LinterSection._options`.
I also rename `_TopLevelAnalyzerOptionsValidator` to
`_AnalyzerTopLevelOptionsValidator` to align with
`_LinterTopLevelOptionsValidator`.
Change-Id: I4f5735d8bda8edbaf066387b473c05969c3ba7d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395060
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
I think when I was adding these modes, I put them on AnalysisOptionsImpl
to keep them secret and flexible. But they're pretty stable now.
Also split out the analysis options `include` tests to test merging
of individual lists and maps.
Change-Id: Ie54a1951dc82900c1fdfc06023cfa7cfb2f410a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391020
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Normally I'm all in favor of breaking up methods to improve readability,
especially to reduce indentation. But I was able to inline `_process`
and `_toSeverity`, and stop relying on `utilities_general.dart` and
keep the code with minimal indentation.
Change-Id: I1e0fe3be4b135de15400f9d2c854c21ae5f47240
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/389041
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This really helps in complying with strict-casts. YamlNode.value returns
a `dynamic`, which is then often passed somewhere which accepts Object
(and then does some type tests). To avoid the implicit cast from
`dynamic`, we can use `.valueOrThrow` (or basically just
`.value as Object`).
The extension getter improves readability and avoids a lot of
as-expressions inside conditional expressions etc.
Change-Id: I50d2eebd51d6fc3eccf1c930652dd5ce70dd9eb1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277582
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Currently, "sideways casts" -- type errors where one type is assigned
to an unrelated type -- are reported by both ErrorVerifier and strong
mode's Checker. This leads to duplicate errors that the user can see.
ErrorVerifier's errors are generally better: they give the user more
contextual information and are easier to read. So this CL eliminates
Checker's reporting of these errors and only uses ErrorVerifier's.
However, in strong mode, type errors like this are fatal: DDC can't
generate correct code. So this also automatically upgrades all static
type warnings to errors when strong mode is enabled.
R=brianwilkerson@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1780783002 .
Konstantin Shcheglov