(Part of https://github.com/dart-lang/sdk/issues/63288)
This change migrates the packages owned by the developer experience
team to use the new constructor declaration syntax, described in
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
This change was performed in an automated fashion, by (a) bumping the
packages' SDK constraints to `3.13.0-0`, (b) enabling the lints
`unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor`, (c) fixing the resulting lint
failures using `dart fix`, and then (d) reformatting the affected
files.
To ease code review, I've reverted unrelated formatting changes.
Since this change requires bumping SDK constaints to `3.13.0-0`, it
was only performed on packages that are *not* published on
pub. (Packages that *are* published on pub should remain on lower
language versions until at least after the stable version of 3.13 is
released, so that we don't block users on the stable channel from
receiving updates to those packages.)
Change-Id: Ibb4daebafd239da58251e838ea6a3f336a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505046
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
This file is no longer published and has no other value. Removing it
removes one step from the process of writing a new lint, which improves
our velocity.
Change-Id: Ie81b914bfa59aa8ec2c8fb2921eec2e9963bd601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/503620
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
* `_getAnalysisOptions` did not use it's first parameter, so remove it.
* `_getAnalysisOptions` is only ever passed a non-nullable
`optionsFile`, so make it non-nullable.
* `DriverBasedAnalysisContext.allAnalysisOptions` are
AnalysisOptionsImpl objects, so leave them alone and prevent later
casting.
Change-Id: Ida490f6a9eeba16c14727e48a306ea336a7ce8a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/470500
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Now that the `messages.yaml` files have been converted to consistently
use camelCase for message names, it is no longer necessary for the
logic that consumes `messages.yaml` files to support other case
conventions.
Change-Id: I6a6a69645d6409c12ef409f6b27ae07cc2403557
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the logic in `pkg/linter` 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: I6a6a69645dc1b417c168a3d26ead9e76704ce0d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466131
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the logic in `pkg/linter/tool/machine.dart` and
`pkg/linter/tool/messages_info.dart` so that rather than parsing the
linter's `messages.yaml` file directly, it uses the shared
infrastructure in `pkg/analyzer_utilities` to read it.
This required adding a new `LintMessage` class to
`pkg/analyzer_utilities`, along with logic to validate and interpret
the linter message fields `categories`, `deprecatedDetails`, and
`state`. The corresponding logic in
`pkg/linter/tool/messages_info.dart` has been simplified accordingly.
This paves the way for upcoming `messages.yaml` format changes,
ensuring that those format changes won't break the logic in
`pkg/linter/tool/messages_info.dart`.
Change-Id: I6a6a696445a1fb599970ac4382d458fb31f1944d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466442
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that lint name matching is case insensitive
(https://dart-review.googlesource.com/c/sdk/+/465964), it is no longer
necessary for the lint names `no_runtimeType_toString`,
`prefer_for_elements_to_map_fromIterable`, and
`prefer_iterable_whereType` to be in mixed case in
`lint_names.g.dart`.
This change adjusts them to all lower case, and renames the
corresponding declarations too. This paves the way for a follow-up CL
that will change the case conventions in `pkg/linter/messages.yaml`.
Change-Id: I6a6a6964381f9573dd735bde0ae8dfb103eef174
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465991
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
All the code that remained in this file was hand-authored and inserted
into the generated file using triple-quoted strings in the code
generator.
Moving the code into a handwritten file will make it easier to
maintain in the future.
Change-Id: I6a6a696404276223981416db38785a50a2cbde09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464625
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the process for removing a lint from `pkg/linter` was the
following:
- Remove the lint class's override of
`AbstractAnalysisRule.registerNodeProcessors` (effectively changing
the rule into a no-op).
- Change its override of `AnalysisRule.diagnosticCode` to return the
pseudo-diagnostic code `removedLint`.
- Modify its constructor to use `RuleState.removed`, so that the lint
would be marked as being in the "removed" state.
This change introduces a new class, `RemovedAnalysisRule`, as the
standard way to represent an analysis rule that has been removed. So
the new process for removing a lint from `pkg/linter` will be to
remove its class entirely and instead register an instance of
`RemovedAnalysisRule`.
This avoids the need for the pseudo-diagnostic code `removedLint` to
exist at all, and also makes the representation of a removed lint much
more compact.
To help encourage clients to use the new `RemovedAnalysisRule` class,
the `RuleState.removed` constructor has been deprecated. It will be
removed in a future version of the analyzer.
Change-Id: I6a6a6964726595b7bb32664846cf4e4722bbb4f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/463463
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Removes all the generated classes derived from `DiagnosticCode` that
are specific to a type of diagnostic, except for those associated with
lints (`LinterLintCode`, `LinterLintWithoutArguments`, and
`LinterLintTemplate`). These exceptions are needed because the base
class for lint codes, `LintCode`, is part of the anlyzer public API,
and so it's necessary for lint codes to all implement it.
The generated static constants in these classes are removed too
(including the ones in `LinterLintCode`), since they are no longer
used; the analyzer and related packages have all been transitioned
over to refer to top level diagnostic constants instead.
Note that the class `ParserErrorCode` could not be completely removed,
because it is dependend upon by `package:dart_style`. So a stub
version of it is added to
`package:analyzer/src/dart/scanner/scanner.dart` (the file that
`package:dart_style` imports it from) as a temporary workaround.
Change-Id: I6a6a69648acac350e4e2249efe50ae9c652772b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461880
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Moves the `removedLint` constant from the generated file
`pkg/linter/lib/src/lint_codes.g.dart` (where it was a static const
inside the `LinterLintCode` class) to the handwritten file
`pkg/linter/lib/src/diagnostic.dart` (where it is a top level
constant), and adjusts usages.
This paves the way for a follow-up CL that will remove the generated
file `pkg/linter/lib/src/lint_codes.g.dart` entirely.
Change-Id: I6a6a69641554f98b19b1e1c4ef488439da21cca5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461780
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Changes the analyzer and related packages so that when they refer to
diagnostic constants, they do so via the import prefix `diag`, which
refers to the appropriate `diagnostic.dart` file containing the top
level diagnostic constant declarations, rather than the static
declarations inside `DiagnosticCode`-derived classes (which will soon
be removed).
This CL was created by the following steps:
- Run the script
`pkg/analyzer_utilities/tool/messages/switch_to_toplevel_diagnostics.dart`.
- Execute `dart fix --apply --code=unused_import,unnecessary_import`
on the following directories (this removes imports that are no
longer necessary due to the change):
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end`
- `pkg/analyzer_cli`
- Execute `dart format` on the following files and directories:
- `pkg/analysis_server`
- `pkg/analyzer`
- `pkg/linter`
- `pkg/analysis_server_plugin`
- `pkg/analyzer_plugin`
- `pkg/analyzer_testing`
- `pkg/front_end/test/scanner_test.dart`
(Note that `pkg/front_end` and `pkg/analyzer_cli` are not
re-formatted as whole directories because they contain `.dart` files
that are test cases rather than source code, and reformatting those
files might change test expectations.)
- Manually add `diag` to
pkg/front_end/test/spell_checking_list_tests.txt.
- Manually fix the ignore comment in
`pkg/analyzer_testing/lib/src/analysis_rule/pub_package_resolution.dart`. (The
script `switch_to_toplevel_diagnostics.dart` automatically adds it
after `import 'package:analyzer/src/diagnostic/diagnostic.dart' as
diag;`, but then executing `dart format` bumps the ignore comment to
the following line, where it has no effect.)
Change-Id: I6a6a69643022aab2b5a6224fb4124eead243260d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461521
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Modifies the analyzer diagnostic message code generation logic so that
it's capable of generating diagnostic constants either:
- As static constants inside `DiagnosticCode`-derived classes such as
`CompileTimeErrorCode`
- Or as top level constants inside of new files called
`diagnostic.g.dart`.
The behavior is controlled through the constant
`generateTopLevelConstants`. This constant is currently `false`, which
means that diagnostic constants are still generated as static
constants inside `DiagnosticCode`-derived classes (as they have been
for quite some time). This CL introduces the new `diagnostic.g.dart`
files, but they are currently empty.
In a follow-up CL I will flip the flag to `true` and re-run the code
generation logic, and in a later CL, I'll remove the flag. The reason
for spreading the work across multiple CLs is twofold:
- To make code review easier
- To make merge conflicts easier to deal with (since the flag flip CL
can easily be regenerated if merge conflicts arise).
Note that when the flag is set to `true`, static constants will still
be generated to the `DiagnosticCode`-derived classes to avoid breaking
code in the analyzer and related packages, but these constants will
simply redirect to the constants in the new `diagnostic.g.dart` files.
Change-Id: I6a6a696452d1a81a45010b374e898f0fa5fe5c9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461260
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the deprecated `LinterLintCode` constructor, and renames
`LinterLintCode.internal` to `LinterLintCode`.
In https://dart-review.googlesource.com/c/sdk/+/459140,
`LinterLintCode` was renamed to `LinterLintCode.internal`, but the old
`LinterLintCode` constructor was left around because there were still
some references to it in google3. This allowed the signature of
`LinterLintCode.internal` to be evolved without introducing breakages.
Now that google3 code no longer uses the `LinterLintCode` constructor,
we can remove it and rename `LinterLintCode.internal` back to
`LinterLintCode`.
Change-Id: I6a6a6964bb9cd5d129612446cd1f035cd0f6a75e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459201
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes nearly all of the special handling of `uniqueName` in
constructors in the `DiagnosticCode` class hierarchy.
With three exceptions, the value passed for the named parameter
`uniqueName` is the same as the value that will eventually be stored
in the `DiagnosticCode.uniqueName` field. The three exceptions are the
constructors for `LintCode` and `SecurityLintCode`, and the unnamed
constructor for `LinterLintCode`. These constructors allow
`uniqueName` to be `null`, and if `null` is supplied, they replace it
with `LintCode.$name`.
These exceptions are needed for analyzer API compatibility in the case
of `LintCode`, and for compatibility with google3 code in the case of
`SecurityLintCode` and `LinterLintCode`.
In follow-up CLs, I will be updating google3 code to make the
exceptions in `SecurityLintCode` and `LinterLintCode` unnecessary.
Change-Id: I6a6a6964d828c3a8db6563d47347d5ca8f550ac3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459001
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Changes the static types of the diagnostic message constants for the
analyzer (and linter) from derived classes like
`ParserErrorWithoutArguments`, `ParserErrorTemplate`, or
`ParserErrorCode` to the corresponding base classes
(`DiagnosticWithoutArguments`, `DiagnosticWithArguments`, or
`DiagnosticCode`). The actual runtime types of the constants is
unchanged.
This is a step toward simplifying the `DiagnosticCode` class
hierarchy.
Change-Id: I6a6a69643773adcf5834a9b9e3be90623611d4e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458961
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the class heading in `pkg/linter/messages.yaml` from
`LintCode` to `LinterLintCode`. This fixes an inconsistency by
ensuring that in both analyzer-style `messages.yaml` files
(`pkg/linter/messages.yaml` and `pkg/analyzer/messages.yaml`), all
class headings match the name of the corresponding generated error
class.
Fixing this inconsistency allows the signature of
`MessageWithAnalyzerCode.toAnalyzerCode` to be simplified--it no
longer needs a `diagnosticClassInfo` parameter, since it can obtain
one from `analyzerCode.diagnosticClass`.
Note that there are no changes to generated code, so the behavior of
the analyzer and linter is unaffected.
Change-Id: I6a6a69644221d8d93b32a454bd5ff8519fbd6971
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458960
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds the constructor parameter `uniqueNameCheck` to `DiagnosticCode`
and derived classes. If a non-null value is supplied for this
parameter, an assertion checks that it's equal to
`uniqueName`. (Passing a `null` value disables the assertion; this is
necessary to preserve analyzer API compatibility).
The reason for this change is that the value supplied for `uniqueName`
when calling constructors in the `DiagnosticCode` class hierarchy is
not necessarily the same as the value that is eventually stored in the
`uniqueName` field; it goes through a sequence of manipulations while
being passed up the superclass chain that make its actual behavior
difficult to follow. The `uniqueNameCheck` field allows me to test the
theory that the actual values that wind up in `uniqueName` are simply
the analyzer codes, with the exception that `LinterLintCode.` is
replaced with `LintCode.`.
In a follow-up CL, I plan to eliminate nearly all the manipulations of
`uniqueName` that occur while being passed up the superclass chain,
which will simplify the code generation logic for computing
`uniqueName` values. Adding `uniqueNameCheck` now allows me to test
out the new, simpler logic, and verify that it will produce the same
result as today's more complex logic.
The `uniqueNameCheck` parameter is marked as `@deprecated` to prevent
clients from trying to use it; this ensures that when I remove it in a
follow-up CL, it won't be necessary to bump the analyzer major
version.
Change-Id: I6a6a696440bce62a31b988d12064244e54e37b6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458820
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the constructors for `LintCodeWithExpectedTypes`, and the code
generated DiagnosticCode classes, so that all their constructor
parameters are named parameters.
This makes the classes in the `DiagnosticCode` hierarchy more uniform:
excluding test classes, the only remaining constructors that have
required positional parameters are now `LintCode` (which is part of
the analyzer public API and can't easily be changed), the unnamed
constructor for `LinterLintCode` (which is deprecated and will soon be
removed), and `SecurityLintCode` (which is used internally in google3
and will require more effort to change).
This change paves the way for follow-up CLs in which I will be
flattening the `DiagnosticCode` hierarchy; those follow-up CLs will
change which constructors are called by generated code, so it will be
easier to write and review them if they don't have to switch between
named and unnamed parameters.
Change-Id: I6a6a696432c8dc701fcd87a82350d185787f5d77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Replaces imports of `pkg/analyzer/lib/src/lint/linter.dart` with
direct imports of the files it re-exports:
- `package:analyzer/analysis_rule/analysis_rule.dart`
- `package:analyzer/analysis_rule/rule_context.dart`
Also inlines the typedefs `LintRule` = `AnalysisRule` and
`LinterContext` = `RuleContext`.
The rationale for this change is that implementers of lints inside of
google3 tend to use existing lint rules as a starting point; this has
resulted in a lot of internal code importing from
`package:analyzer/src`, which makes modifying analyzer internals more
difficult. Changing existing lint rules to use proper analyzer public
APIs should help curb this trend.
Change-Id: I6a6a6964136534b393c9504bea11d22eafb11c05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459180
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Renames the constructor `LinterLintCode()` to
`LinterLintCode.internal()`, and updates all call sites.
The old `LinterLintCode()` constructor remains, but is deprecated.
This change will allow the signature of the constructor to be changed
in future CL's, without breaking some internal Google code that makes
use of the `LinterLintCode()` constructor.
Separately, I will upate the internal Google code to use `LintCode()`
instead, and then I will rename `LinterLintCode.internal()` back to
simply `LinterLintCode()`.
Change-Id: I6a6a6964764652646d233d348dfeae82db5c5569
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459140
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes several references to derived diagnostic types
(`CompileTimeErrorCode`, `WarningCode`, etc.) to simply
`DiagnosticCode`.
This paves the way for a follow-up CL that will change the static
types of the generated analyzer diagnostic code objects to more
general types. This is part of a longer-term effort to simplify the
`DiagnosticCode` class hierarchy.
Change-Id: I6a6a69642561aebf2607e834fa09fa608cb4fa10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/458587
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the variables `analyzerMessages`, `feAnalyzerSharedMessages`,
`frontEndMessages`, and `lintMessages` from maps (keyed by analyzer
code or front end code) to lists. The map functionality is no longer
needed now that analyzer and front end codes are stored in the
`Message` objects, and maps are available in `diagnosticTables` for
looking up messages by name when needed.
Change-Id: I6a6a6964138f9bd17d3595b3ed8aaf4aadd9ecfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457540
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moves the methods `outputConstantHeader`, `toAnalyzerCode`, and
`toAnalyzerComments` from the `Messages` class to the subtype
`MessageWithAnalyzerCode` (which is changed into a mixin). This is a
more appropriate place for these methods because they only pertain to
messages that are code generated into the analyzer.
Change-Id: I6a6a6964f9d575cb7bd9c1d25e99d6a1d445f497
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457501
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Modifies the message code generation framework so that the
`analyzerCode` and `frontEndCode` values associated with diagnostic
messages are stored in the corresponding `Message` objects.
This makes it easier to check for duplicate analyzer codes because
all `Message` objects that lead to analyzer diagnostics now support an
`analyzerCode` getter. (There is a new interface these objects:
`MessageWithAnalyzerCode`.)
It also paves the way for a follow-up CL in which I plan to centralize
and clean up the logic for reporting duplicate codes. This will in
turn allow me to sanity check the analyzer `sharedName` codes.
Change-Id: I6a6a69649c751d2ff7219baf4add20742b867d09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457500
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Performs the following renames:
- Most referecense to "error code" or "error" are changed to
"diagnostic":
- `_allErrorClassNames` -> `_allDiagnosticClassNames`
- `AnalyzerErrorGenerator` -> `AnalyzerDiagnosticGenerator`
- `errorClass` -> `diagnosticClass`
- `_errorClassesByName` -> `_diagnosticClassesByName`
- `ErrorClassInfo` -> `DiagnosticClassInfo`
- `ErrorCodeParameter` -> `DiagnosticParameter`
- `ErrorCodeParameterType` -> `DiagnosticParameterType`
- `GeneratedErrorClassInfo` -> `GeneratedDiagnosticClassInfo`
- `GeneratedErrorCodeFile` -> `GeneratedDiagnosticFile`
- `SharedToAnalyzerErrorCodeTables` -> `SharedToAnalyzerDiagnosticTables`
- `sortedSharedErrors` -> `sortedSharedDiagnostics`
- A few references to "error" are dropped:
- `camelCaseErrorName` -> `camelCaseName`
- `snakeCaseErrorName` -> `snakeCaseName`
- The class hierarchy `ErrorCodeInfo` is renamed to use the
nomenclature `Message`:
- `AliasErrorCodeInfo` -> `AliasMessage`
- `analyzerCodeToInfo` -> `analyzerCodeToMessage`
- `AnalyzerErrorCodeInfo` -> `AnalyzerMessage`
- `CfeStyleErrorCodeInfo` -> `CfeStyleMessage`
- `ErrorCodeInfo` -> `Message`
- `FrontEndErrorCodeInfo` -> `FrontEndMessage`
- `SharedErrorCodeInfo` -> `SharedMessage`
- Local variables are renamed accordingly.
There is no functional change.
To aid in code review, patchset 1 contains just the renames, with no
sort order changes. Patchset 2 was obtained from patchset 1 by sorting
`pkg/analyzer_utilities/lib/messages.dart` (the only file in which
declaration order needs to change due to sorting).
Change-Id: I6a6a6964117916dee1e4073073f9173882973377
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Splits the `ErrorClassInfo` class into two classes:
- `ErrorClassInfo`, representing any concrete error class in the
analyzer or linter.
- `GeneratedErrorClassInfo`, representing an error class that is code
generated.
Also, adds `linterLintCodeInfo` to the `errorClasses` list. This list
now describes all concrete error error classes in the analyzer and
linter, whether they are generated or not.
This paves the way for a follow-up CL which will use the
`errorClasses` list to validate that any analyzer error codes
referenced by a `messages.yaml` entry (such as those in
`pkg/_fe_analyzer_shared/messages.yaml` or
`pkg/front_end/messages.yaml` refer to existing error classes.
Change-Id: I6a6a6964836480426d5025509c6c9c87f089f4ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454684
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Moves all the code from
`pkg/analyzer/tool/messages/error_code_info.dart` into
`pkg/analyzer_utilities/lib/analyzer_messages.dart`. This code
describes the analyzer and linter diagnostic codes, and is used by
diagnostic message code generation logic.
Moving this code into `pkg/analyzer_utilities` will allow it to be
referenced by the front end and shared diagnostic code generators. In
a future CL, I will take advantage of this in order to validate
references to analyzer diagnostic codes in
`pkg/_fe_analyzer_shared/messages.yaml` and
`pkg/front_end/messages.yaml`.
Change-Id: I6a6a696412647b54908cba1cf41801eebcd09923
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452480
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Creates a new class `AnalyzerCode`, representing an analyzer error
code as a class name and an error name, and consistently uses it in
places that previously represented analyzer error codes as simple
strings.
This change allows for better validation. In follow-up CLs, I will use
this as a vehicle for cleaning up the `messages.yaml` files to refer
to error codes more consistently. For instance:
- Currently, the class name is not specified in all circumstances; I
will change this so that it is always specified. This in turn will
allow error codes of type other than `ParserErrorCode` to be shared
between the analyzer and CFE.
- Currently, some parts of `messages.yaml` refer to errors using
`UPPER_SNAKE_CASE` while others use `lower_snake_case`. I will
change this so that `lower_snake_case` is used consistently.
Change-Id: I6a6a696405de7d7e89b1ee11baa776ee639be8fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/452460
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Adds some missing `$`s to fix string interpolation when reporting
errors in the `messages.yaml` file. Also adds a try/catch so that if
an error occurs while processing a particular lint code, the lint code
in question will always be reported.
This should make it easier to track down problems when working on the
linter's `messages.yaml` file.
Change-Id: I6a6a6964072522ac4f43579f28f8d190a0c794f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451840
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Moves the following top level declarations, as well as other
declarations they depend on, from
`pkg/analyzer/tool/messages/error_code_info.dart` into
`package:analyzer_utilities`, so that they can be imported by the CFE's
diagnostic code generator:
- `frontEndMessages`
- `placeholderPattern`
- `FrontEndErrorCodeInfo`
There is no functional change.
In a follow-up CL, I will modify
`pkg/front_end/tool/generate_messages_lib.dart` to use these
declarations.
Change-Id: I6a6a69642230f0b943ccaf800c1f9e569c5b7579
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The constant `literateApiEnabled` was a temporary artifact of the
rollout of the analyzer's new literate API for diagnostic
reporting. Now that the literate API is enabled, it is no longer
needed.
Hardcoding this constant simplifies the code generation logic for
analyzer and linter diagnostics. This should help pave the way for
sharing more of the code generation logic with the CFE.
Change-Id: I6a6a6964c16db74613f6c7d9a3f8ee6789b38dda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447944
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The new updateAnalysisOptions4 parameter is a callback function,
similar to updateAnalysisOptions3, but with one removed parameter
itself, the `DartSdk sdk` parameter.
The one place where this parameter was used in the callback passed by
the caller, was in DAS's ContextManager, and it was just used in order
to compute a FeatureSet from (a) the computed DartSdk and (b) the
command-line `--enable-experiment` options. We can instead provide a
`enabledExperiments` parameter on AnalysisContextCollectionImpl,
leading to a simpler API and still a simple implementation in
ContextBuilder.
The reason for the incremental migration is that dartdoc, and possibly
some internal clients, use updateAnalysisOptions3.
Change-Id: Ie990ab8f7b850aed1ce3ef39ab71c01835c080da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447400
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
A mechanism is added to allow the types of diagnostic arguments to be
checked at runtime. This mechanism is enabled for all analyzer
diagnostic codes except for syntactic errors (since those are
generated by the shared parser using the CFE's argument substitution
mechanism, which is already strongly typed).
To avoid introducing backwards incompatibilities to analyzer clients,
the types are only checked at runtime if the diagnostic code
implements the new `DiagnosticCodeWithExpectedTypes` interface.
The expected types are determined by the type annotations in the
`messages.yaml` file. These are the same type annotations used in the
new literate API for diagnostic error reporting. So this should ease
the transition into the new literate API, which will make any such
type errors into compile-time errors.
Change-Id: I6a6a696473f1d75686ba4405a1bef1e978d88993
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445785
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Previously, the generated files containing definitions of diagnostic
messages were not sorted. This didn't cause a failure in
`verify_sorted_test.dart` because the definitions of diagnostic
messages were all static constant fields, and member sorting ignores
fields.
However, a follow-up CL will be introducing static methods to
implement the new `.withArguments()` functionality for error codes
that take arguments, and these will need to be sorted. So to prepare
for that, this CL modifies the code generator so that its output is
already sorted.
Change-Id: I6a6a6964c476d8a7b5841860998c50b01e592942
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446120
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Parker Lougheed