Previously, the logic to decode an aliased analyzer message from yaml
only decoded the `aliasFor` and `comment` fields of the alias, and
ignored all other fields (including `deprecatedMessage`). This meant
that when deprecating one error code in favor of another, it was
necessary for the new code to be an alias for the old one. But that's
the opposite of what we usually want when deprecating things; we
usually want old thing to be an alias for the new one, so that the
behavior will be unchanged when the deprecated thing later gets
removed.
This CL refactors the yaml decoding logic for analyzer messages, so
that there's more sharing between aliased and non-aliased
messages. Now, when one message is an alias for another, we can choose
which of the two messages to mark as deprecated.
Change-Id: Ib5ddff62c75724ba55c4a5b19729792f1dcffbec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This looks pretty beefy; it is more-or-less 3 parts:
* Removing the `implicit-casts: false`, `implicit-dynamic: false`
modes:
* Remove `AnalysisOptionsFileConfig.implicitCasts|implicitDynamic`
* Remove `AnalysisOptionsImpl.implicitCasts|implicitDynamic`
* Remove `TypeSystemImpl.implicitCasts`
* Remove all behavioral tests of the modes
* Remove Analysis Options-parsing code that handled `strong-mode`
* Remove ability to fix deprecated modes (introduced before Dart 3).
* Move some non-generated AnalysisOptionsHintCodes and
AnalysisOptionsWarningCodes to be generated. As
`AnalysisOptionsHintCode.STRONG_MODE_SETTING_DEPRECATED` was the
last `AnalysisOptionsHintCode` code, there were problems with the
code-generator, unless I moved these non-generated codes.
* `DEPRECATED_LINT_HINT`, `DEPRECATED_LINT_HINT_WITH_REPLACEMENT`,
`DUPLICATE_RULE_HINT`, `INCOMPATIBLE_LINT`, `UNDEFINED_LINT`.
* Those codes are then added to error_fix_status.yaml.
Change-Id: Ic165b60ca85f08f92886433eac5f5da5b7dd5021
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316483
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* Move many identifiers from snake_case or SCREAMING_SNAKE_CASE to
camelCase. I think I restricted the changes to private API.
* Add an ignore in generated files for constant_identifier_names;
we often just mirror names found in YAML files or whatever, where
things are not necessarily named according to Effective Dart
standards.
* Avoid some implementation imports which I think were accidental.
* Use single quotes in some more places.
Bug: https://github.com/dart-lang/sdk/issues/48784
Change-Id: I439fe50cb9f8f8f5e9c74ce594aea15e394ee7da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Although I eventually hope that the analyzer and front end
`messages.yaml` files can support exactly the same functionality, at
the moment there are differences, and I need to introduce a few
additional differences in upcoming CLs. Having two classes to
represent analyzer and front end messages will make it easier to deal
with these differences.
Change-Id: I6148ed71a69d8e94b8c4f78d4168a04ec1c83cb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218780
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, `pkg/analyzer/test/verify_diagnostics_test.dart` and
`pkg/analyzer/tool/diagnostics/generate.dart` extracted documentation
from the code of the analyzer error classes. However, since this code
is generated from `messages.yaml`, it's much cleaner to just extract
the documentation directly from the YAML.
Change-Id: I7dc3eb73abbf5d72f203abbf04e43856b60d2a89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215648
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change moves a lot of logic into `error_code_info.dart`. In a
follow-up CL I'll make use of this code to re-work
`verify_diagnostics_test.dart` and the code generator for the
analyzer's `diagnostics.md` file.
Change-Id: I0dca7d30a9def771f03c6a51d26335aeab1c964c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215662
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change standardizes most of the analyzer to refer to problem
messages and correction messages using the names `problemMessage` and
`correctionMessage` (consistent with the naming convention used in the
analyzer and CFE `messages.yaml` files).
Change-Id: I72f078a368c65b346626f560cc721fcff4836452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215151
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
For errors that are shared between the front end and the analyzer, we
move the `documentation` and `comment` fields from
`pkg/analyzer/messages.yaml` to `pkg/front_end/messages.yaml` (where
the rest of the information about the error is). This eliminates the
need to have any entries at all for these shared errors in the
`pkg/analyzer/messages.yaml` file, so we no longer need the boolean
flag `copyFromCfe` in this file.
This simplifies generation of analyzer error codes, so we go ahead and
take this opportuntity to remove the old `syntactic_errors.g.dart`
file, and instead code generate all the shared messages directly into
`syntactic_errors.analyzer.g.dart`.
In a follow-up CL I'll rename `syntactic_errors.analyzer.g.dart` back
to `syntactic_errors.g.dart` to reduce confusion.
Change-Id: I1e314e51c94ef595d9d6de8ba2b30e12a18382a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215155
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change the terms `template`/`tip` in the analyzer and front end's
`messages.yaml` files to `problemMessage`/`correctionMessage`.
Rationale: these terms were previously agreed on for unifying the
analyzer and front end, and they are currently used in the
`Diagnostic` class, which is part of the analyzer public API.
Change-Id: Ifaed92ab5176bba7b7f4c3bb915e9839520330f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215149
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
I've included both the YAML file (`messages.yaml`) and the script I
used to create it (`extract_errors_to_yaml.dart`), so that we can keep
the YAML file up to date until we finish writing logic that code
generates the analyzer errors from the YAML file.
Change-Id: Icbdcaf63a37105b666b11f7356e3fa246a8d65cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214133
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, these mappings were computed on the fly during generation
of syntactic_errors.g.dart. Moving the mappings to their own data
structure makes the logic easier to re-use.
Change-Id: I1c38649b8c4aa4a42a6aa560faf67502d1c6560f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215001
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In follow-up CLs I will build on this data structure to do more
sophisticated YAML error message processing, including generation of
existing analyzer error codes from YAML.
Change-Id: If5d22e2ac3d5c123e3700f8d46c327920a941689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214076
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Sam Rawlins