Move the analyzer-only Diagnostic, DiagnosticMessage, Severity, and
locatable diagnostic helper types out of _fe_analyzer_shared and into
package:analyzer.
I paln to make changes outlined in
https://github.com/dart-lang/sdk/issues/63311 and chat discussion.
Keeping these classes in the analyzer simplifies the migration and
avoids introducing a shared abstraction before there is a concrete need
for one.
If we decide later need to have a shared abstraction, we can always
extract one at that point. With coding agents internal code motion is
cheap.
Update analyzer, analysis server plugin, analyzer plugin, linter, and
scanner call sites to import the moved APIs from analyzer libraries, and
refresh API baselines to reflect the new public owner.
Change-Id: Ie0ef0f01c6e4be7ebaac25619ac3e3fe991a44d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/501000
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
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>
* Remove AnalysisErrorListener, `RecordingDiagnosticListener.errors`,
and `RecordingDiagnosticListener.getErrorsForSource`.
* Deprecate `BooleanDiagnosticListener.onError` and
`RecordingDiagnosticListener.onError` in favor of `.onDiagnostic`.
* Deprecate DiagnosticOrErrorListener. Where this class is used in
private API, replace it with DiagnosticListener. Where this class is
used in public API, keep it and ignore the deprecation lint.
Change-Id: Ie9c89008269db8f42e4ebd161df2764d27dfe0da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456100
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This change introduces a new literate API for reporting analyzer
diagnostics. The new API looks like this:
diagnosticReporter.reportError(
diagnosticCode
.withArguments(...) // omitted if diagnostic takes no arguments
.withContextMessages(contextMessages) // may be omitted
.at(astNode),
);
For comparison, the old API looks like this:
diagnosticReporter.atNode(
astNode,
diagnosticCode,
arguments: [...], // omitted if diagnostic takes no arguments
contextMessages: contextMessages, // may be omitted
);
For the moment, this new API is internal to the analyzer; it is not
exposed through the analyzer public API. This is to give us time to
try it out and make changes if necessary before we have to commit to
it.
The advantages of the new API are:
- Better static type checking: with the old API, if we accidentally
forgot to supply arguments to a diagnostic code that required them,
or vice versa, or supplied the wrong number of arguments, the
mistake would not be caught until runtime. If we accidentally
supplied arguments of the wrong type, the mistake would not even be
caught at runtime. With the new API, any of these mistakes will lead
to a compile-time error.
- Better code completion support: with the old API, if we can't
remember whether a diagnostic code requires arguments, we have to
look it up. With the new API, we can type the diagnostic code
followed by `.`, and completions will be offered for either
`.withArguments` (if arguments are required) or
`.withContextMessages` and `.at` (if no arguments are
required). Furthermore, while typing inside the parentheses after
`.withArguments`, completion will offer the names of the required
arguments.
To allow for a gradual transition to the new API, the old API is still
supported. To make this possible, a new sealed class `Reportable` is
introduced, to act as the parameter type for
`DiagnosticReporter.reportError`. It has two derived classes:
- The existing `Diagnostic` class (which was the old parameter type
for `DiagnosticReporter.reportError`)
- A new `LocatedDiagnostic` class (which is the return type of the new
literate `at` method).
The difference between these two classes is that the `Diagnostic`
class has already had its arguments formatted and disambiguated using
`convertTypeNames`, whereas the `LocatedDiagnostic` class hasn't.
The only change to the analyzer public API for now is the introduction
of `Reportable` and the change to the type signature of
`DiagnosticReporter.reportError`. (It would have been hard to avoid
making this public API change, since the method method
`DiagnosticReporter.reportError` is already exposed publically).
To make code review easier, this CL just introduces the necessary
infrastructure to allow a diagnostic code to start supporting the new
literate API, but doesn't make the necessary modifications to any
diagnostic codes to actually support it. In a follow-up CL, I will
flip the flag `literateApiEnabled`, which will change the generated
code and cause the new literate API to be supported.
In follow-up CLs after that, I will transition the analyzer over to
reporting errors using the new API.
Change-Id: I6a6a696478fdd74803c6215c64ec68626819dd95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445803
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In a follow-up CL, I plan to add an extension on `DiagnosticReporter`
that's not exposed through the analyzer public API, so that we can try
out the analyzer's new literate API for diagnostic reporting without
exposing it to analyzer clients yet. The extension will need to be in
the same library as `DiagnosticReporter` (so that it can access a
private method), so in order to avoid exposing the extension through
the analyzer public API, that library will need to be in `src/`.
From the point of view of analyzer clients, this change is a no-op;
the `DiagnosticReporter` class is still available from
`package:analyzer/error/listener.dart` by way of an export directive.
Change-Id: I6a6a696426f43ee57789b8a7ec1c36bc0b8680ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446100
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The following classes are moved from `package:analyzer` to
`package:_fe_analyzer_shared`:
- `Diagnostic`
- `DiagnosticMessage`
- `DiagnosticMessageImpl`
The following declarations are also moved, since they are needed by
the above classes:
- `formatList`
- `Severity`
- `Source`
- `TimestampedData`
There is no change to the analyzer public API, and `export`
declarations have been added to the analyzer libraries that the
declarations have been moved from, so that code depending on these
declarations is unaffected.
These changes are part of a larger arc of work that introduces methods
`.withArguments` and `.at`, forming a literate API for reporting
analyzer errors that looks roughly like this:
diagnosticReporter.reportError(
ERROR_CODE.withArguments(...arguments...).at(...location...));
Moving this code into `_fe_analyzer_shared` is necessary because
scanner error codes are defined inside `_fe_analyzer_shared` (to allow
the scanner to be shared between the analyzer and CFE). Hence, to
avoid a circular depedency between `_fe_analyzer_shared` and
`analyzer`, the `.withArguments` and `.at` methods will need to live
in `_fe_analyzer_shared` too, as well as the classes representing the
diagnostic messages they create.
Note that there are some minor changes to
`pkg/analysis_server_plugin/api.txt` and
`pkg/analyzer_plugin/api.txt`; these have to do with the way the
`api.txt` generator chooses to report referenced elements, and don't
reflect actual API changes.
Change-Id: I6a6a6964a5c46f4a0205ce0d85620669ce55eb3c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only two uses of `Diagnostic.data` have been replaced with
expandos keyed off the `Diagnostic` object. To make this possible, the
`at...` methods of `DiagnosticReporter` have been changed to return
the `Diagnostic` object they create. This paves the way for a future
CL series, in which I plan to change the API for reporting errors to a
more literate API in which the caller will have access to the
`Diagnostic` object.
Change-Id: I40820387abcd53daf934974c93106803d706fe07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/444461
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Work towards #60635
In this change, we rework the AnalysisErrorListener deprecation to
better support users who have their own class that implements
AnalysisErrorListener. This change introduces a sealed supertype,
DiagnosticOrErrorListener, with the old implementation,
AnalysisErrorListener, and the new implementation, DiagnosticListener,
as its sole direct subclasses. Users who have implemented
AnalysisErrorListener should be able to instead implement
DiagnosticListener, and their class is an acceptable instance of
DiagnosticOrErrorListener, wherever that is needed.
In a breaking change we can drop AnalysisErrorListener and deprecate
DiagnosticOrErrorListener, and in the next breaking change, we can drop
DiagnosticOrErrorListener.
For reference, see the first API difference when deprecating AnalysisErrorListener and introducing DiagnosticListener: https://github.com/dart-lang/sdk/commit/903d77cc8229972a424941dcb7b7b79741e833eb#diff-dec15868961d7eadcd009f49d129bebcdb747aaa8dbfde5f5a08884e0cf11e32
Change-Id: I3ccf11d54b41fbca98d020d89978d250c16b4c04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436480
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Work towards https://github.com/dart-lang/sdk/issues/60635
I tried to keep this minimal but still sensible:
* Rename AnalysisErrorListener and all subtypes to use 'Diagnostic'.
* Rename all instantiations of such classes if they previously
contained the word 'error'.
* Rename `RecordingDiagnosticListener.errors` to `.diagnostics`.
* Rename some _testing_ instance members that had the word 'error'
to instead use 'diagnostic'.
Change-Id: I3948e27ba28ac2494092e04f4e1d201a20cc1135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433004
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Work towards https://github.com/dart-lang/sdk/issues/60635
* `AnalysisError._contextMessages` unnecessarily backed the public
`contextMessages` getter; the field is final so it can be public
itself.
* `AnalysisError._correctionMessage` unnecessarily backed the public
`correctionMessage` getter; the field is final so it can be public
itself.
Change-Id: If269d4ed590ef7df81d9b9e3be03766601526d7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425620
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Konstantin Shcheglov