Path exclusions should ideally be defined inside a project's
`analysis_options.yaml` file, rather than being added programatically.
Plus, there's a bug with the constructor that causes this parameter to
be completely ignored anyways, so it's been obsolete and non-functional
for a while now. `getExcludedGlobs` in the `_ContextLocator` handles
parsing and adding excluded paths from the analysis server already, so
we should look into deprecating and removing this parameter.
Change-Id: I6c023041c7bb5fa4cb9dedc629afa4ea6ecb63d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/511160
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
These files had comments indicating that running
`pkg/analysis_server/tool/spec/generate_files` would regenerate them,
but that was not the case.
Change-Id: I6ceb6352edf6eab5e746276a0a2f33b16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/507521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
(Part of https://github.com/dart-lang/sdk/issues/63288)
Updates the `CodeGenerator` mixin so that it outputs `ignore_for_file`
comments to ignore the following lints:
- unnecessary_type_name_in_constructor
- unnecessary_ignore
- duplicate_ignore
This mixin is used by the code generators that produce the Dart
wrappers for the analysis server and analyzer plugin wire protocols.
This is a first step towards migrating the packages `analysis_server`,
`analysis_server_client`, and `analyzer_plugin` packages to use the
new constructor declaration syntax, since it will allow the
`unnecessary_type_name_in_constructor` lint to be enabled without
breaking generated code.
Once all the packages have had their SDK constraints bumped to a
language version that supports the new syntax, I'll update the code
generator to use the new syntax, and remove the ignores.
For more information about the new constructor declaration syntax, see
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.
Change-Id: Ied17e3ea772546675aad48efc324f6f16a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505521
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This change migrates the analyzer_utilities package 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: Ib9564fe588b1118f7e810bd39ff9c6576a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505066
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When I'm doing breaking changes, I put generatons into their own
analysis context, to use a stable version of the analyzer. All these
generators are in tool/, so never API.
Change-Id: Ic0488a7f2c8111955de685dbd2cb170cfbb21274
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/497421
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Replace the hand-written header flag formatting for elements and
fragments with writeHeaderFlags(...flagsForTesting). This makes the
printed output come from the same generated flag definitions as the
element model instead of maintaining separate lists of writeIf calls.
Mark computed element flags such as hasDefaultValue, hasInitializer, and
hasNonFinalField in the generated metadata, and add the missing
generated overrides needed to expose them through flagsForTesting. This
also lets the shared path report flags such as isSimplyBounded and
hasEnclosingTypeParameterReference consistently.
Because hasNonFinalField now needs to round-trip through bundles for
enums, update the bundle reader and writer and bump the data version.
Change-Id: I7c126fe4bc69fd6b191f339ddc420b05cd8b5ee7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/495860
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This CL is part of an effort to bump the SDK requirement to `3.12.0-0`
for all the packages in `pkg` that are not published to `pub`, so that
we can get better testing of the "private named parameters" feature.
(Packages that *are* published to `pub` can't be safely bumped yet,
because SDK 3.12 hasn't been released, and I don't want to block those
packages' ability to publish useful updates to customers.)
This change covers the following packages, which are owned by the
developer experience team:
- pkg/analysis_server_client
- pkg/linter
- pkg/server_plugin
- pkg/telemetry
Changes to `pubspec.yaml` files were made manually.
Changes to `.dart` files were made automatically (with a few
exceptions; see below), using `dart fix` to migrate to using private
named parameters where it is possible to do so without changing
semantics. Note that this migration is conservative; see
https://github.com/dart-lang/sdk/issues/58607 for details.
The exceptions are:
- pkg/analysis_server_client/lib/handler/notification_handler.dart
- pkg/analysis_server_client/lib/src/protocol/protocol_common.dart
- pkg/analysis_server_client/lib/src/protocol/protocol_generated.dart
These are code-generated files are checked by the trybots to make sure
they are correct. The code generator runs the formatter, and the
formatter's behavior depends on the current language version. To
minimize the risk of accidental behavioral changes, I addressed this
by manually running these files through `dart format` and then
verifying that the result matches what the code generator would
produce.
Change-Id: I5a0baa28904890a0b7e4234b12f587f66a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/487621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The customization mechanism provides the following pieces of
functionality:
- Allows access to the package name, the analysis context, the list of
public API libraries, and the set of top level public API elements.
- Allows customizing the logic for deciding which top level elements
to show details about.
- Provides hooks to allow additional code to be executed after setup
and after the initial scan.
This customization mechanism is used when generating
`pkg/analyzer/api.txt` to recognize that any element annotated with
`@AnalyzerPublicApi` should have details shown, even if it is not
exported in any analyzer public library.
The class used to perform customization, `ApiSummaryCustomizer`, is
marked `base` so that we can add additional hooks in the future
without breaking clients.
With this change, the API summary tool no longer has any hard-coded
analyzer-specific functionality.
Change-Id: I6a6a6964fcc626db8e8e387c306fc1ff03fbc0a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482442
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the logic for deciding whether to output details about a top
level element. Previously, details would be output if the library
containing the element's declaration was in `lib` but not
`lib/src`. This led to a bug: if a top level element was declared in
`lib/src` but exported by an `export` directive in `lib`, no details
would be output, and the API summary would just show `(non-public)`
after the exported name.
This bug was mostly benign because we were working around it with an
analyzer-specific hack: when analyzing the `analyzer` package, top
level elements with an annotation of type `AnalyzerPublicApi` would
have their details output regardless of where they were declared. But
it wasn't completely benign: the tool was failing to output details of
`DartDocumentLinkVisitor` and `DocumentLink` (from
`package:analyzer_plugin`), as well as `PackageBuilder` (from
`package:analyzer_testing`).
The new logic is: details are output if the element appears in the
export namespace of any library in `lib` but not `lib/src`. I've
re-run the API summary tool so the `api.txt` files in
`package:analyzer_plugin` and `package:analyzer_testing` now include
the details they were missing.
The analyzer-specific hack is left in place, though, because there are
some analyzer classes that aren't exported, but still considered part
of the analyzer public API. In a follow-up CL, I will make the API
summary tool extensible so that this analyzer-specific logic can be
injected by the analyzer when generating its `api.txt` file, and it
won't pollute the incipient `api_summary` tool.
Change-Id: I6a6a69641d656caa4f8e6361557c13fa7485e422
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds the modifiers `abstract`, `base`, `final`, and `interface` to the
API summary output.
This information is an important part of the public API of a package,
because it determines whether a client can:
- Construct an instance of the class,
- Extend the class, or
- Implement the class.
Change-Id: I6a6a6964ba07db1714bc2fcb549cc15230e87058
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482362
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes two minor bugs with the sorting of members in the API summary
tool:
- The technique for placing getters next to their corresponding
setters was to sort them lexicographically based on
`Element.apiName`, which in the case of setters appends `=`. This
mostly worked, but due to the fact that `=` is between `9` and `A`
in ASCII, it was wrong in a few corner cases. For example, it would
sort `x`, `x=`, `x1`, and `x1=` in the order `x`, `x1`, `x1=`,
`x=`. Fixing this didn't affect any `api.txt` files in practice.
- The technique for sorting constructors also used `Element.apiName`,
which in the case of an unnamed constructor is `new`. This meant
that if a class had both named and unnamed constructors, the unnamed
constructor would not always be sorted before the other
constructors.
The fix for both bugs is to sort by `Element.name` (which does not add
`=` for setters and is the empty string for unnamed constructors), and
then to break ties by explicitly checking whether the element is a
setter.
Change-Id: I6a6a69648fb5915266a9111c5d884531bba4405d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482361
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests cover all the functionality of the API summary tool.
Note that since the `ApiDescription` constructor requires an
`AnalysisContext`, I added a public `contextCollection` getter to the
`PubPackageResolutionTest` base class.
There are a few loose ends I intend to address in follow-up CLs. They
have been noted in TODO comments:
- Annotate when classes are `abstract`, `final`, or `interface`.
- Move `pub_package_resolution.dart` out of
`package:analyzer_testing/src` (so that when I publish this as a
separate package, that package won't be dependent on private
implementation details of `package:analyzer_testing`).
Change-Id: I6a6a69643064115997f6586ff5161ddf4c9f96ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482360
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change splits the file `pkg/analyzer_utilities/lib/tool/api.dart`
into several files:
- `api_description.dart`, which contains the `ApiDescription` class
that does the bulk of the work.
- `extensions.dart`, which contains utility extensions.
- `member_sorting.dart`, which encapsulates information about how to
sort members.
- `node.dart`, which defines the tree data structure that is used to
build the output.
- `unique_namer.dart`, which defines the logic for disambiguating
elements that have the same name.
- `uri_sorting.dart`, which encapsulates information about how to sort
URIs.
- `summarize_package.dart`, which contains the code for driving the
`ApiDescription` class.
This is in preparation for extracting this logic from
`analyzer_utilities` and releasing them as a separate pub package
called `api_summary`, so that they can be used by other
projects. Accordingly, I've placed all of these files in their own
directory, `pkg/analyzer_utilities/lib/src/api_summary`. The files
that will eventually wind up in `package:api_summary/src` are in
`pkg/analyzer_utilities/lib/src/api_summary/src`.
(Under ordinary circumstances it would be strange to have a `src`
directory nested inside another `src` directory, but I believe that in
this case it's justified, since it allows us to see which files will
eventually end up in the public API of the `api_summary` package and
which will not.)
I still want to do some final polishing of the tool before publishing
it as its own package:
- Adding unit tests
- Fixing a few bugs
- Generalizing some behaviors that currently only make sense when
analyzing the `analyzer` package.
I intend to do this polishing in follow-up CLs. Then, once the
`api_summary` package is published, I will import the package into the
SDK and remove all the files in
`pkg/analyzer_utilities/lib/src/api_summary`.
Change-Id: I6a6a6964a5f71a732bbee0bfcdcec9458737d703
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482101
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
These extensions were previously in `pkg/analyzer_utilities`, which is
not published on `pub`. That meant they could not be used from within
the `lib` directory of any package that *is* published on
`pub`. Specifically, they could not be used from within
`pkg/analyzer_testing/lib`.
In a follow-up CL, I will modify the testing logic so that after
printing `To accept the current state, expect:`, it prints diagnostic
codes in their proper camelCase format.
Change-Id: I6a6a696432d7162906b2c235ea88310dc0aa1fa9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/480040
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The purpose of this tool was to aid in transitioning front_end and
related packages away from the old `codes_generated.dart` and to the
new `diagnostic.g.dart` files. Now that the `codes_generated.dart`
files are no longer present, the tool is no longer needed.
Change-Id: I6a6a696416f4b09d03d90aace9be5e6e10cd100c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476140
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Translates code in the `compiler` package so that it imports
diagnostic codes from `package:front_end/src/codes/diagnostic.dart`
rather than `package:front_end/src/api_prototype/codes.dart`.
Note that a previous CL
(https://dart-review.googlesource.com/c/sdk/+/475929) performed the
same conversion on other packages; I failed to realize at the time
that `pkg/compiler` needed to be converted too.
This CL was created by adding `compiler` to the list of packages
handled by
`pkg/analyzer_utilities/tool/messages/use_prefixed_import_instead_of_code.dart`,
and re-running it.
Change-Id: I6a6a696415f1d9a8241aad6360942d340eafb383
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476146
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
This tool searches the front_end, and related packages, for any use of
a `withArgumentsOld` method whose target is a diagnostic constant
whose parameters are documented, and transitions it to a use of
`withArguments` (which accepts named parameters rather than positional
ones).
Any uses of `withArgumentsOld` targeting a diagnostic constant whose
parameters are undocumented is left alone. This will allow me to
ensure that I've had a chance to review every parameter of every
diagnostic message, documenting it and giving it a better name if
necessary, before uses of that diagnostic message are transitioned. I
plan to do this work in small batches over the next week or two.
The tool also outputs counts of how many `withArgumentsOld` calls were
not transitioned, for ease in tracking progress.
As of this moment, there is only one diagnostic message whose
parameters are documented (privateNamedParameterDuplicatePublicName),
so I've gone ahead and run the tool to transition the one call site
that targets it to `withArguments`.
Change-Id: I6a6a69644ec0944be9a626d9b539d2956edc19ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/476141
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This tool will be used to automatically migrate the code in
`pkg/front_end` (and related packages) from using the old
`codes_generated.dart` and `cfe_codes_generated.dart` files to the new
`diagnostic.g.dart` files.
Change-Id: I6a6a6964b720180b9cf7a3cadf94fa70fe42c1c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475927
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In https://dart-review.googlesource.com/c/sdk/+/468080, the private
implementation of the `DiagnosticCode` class was changed so that the
unique name of the error code is now stored in a field called
`_uniqueName`. (Previously it was stored in a field called
`uniqueName`. This inadvertently broke the
`use_literate_api_in_analyzer.dart` script. The fix is simple: change
`use_literate_api_in_analyzer.dart` to access the unique name using
the `_uniqueName` field.
Change-Id: I6a6a6964088b30506e52c1e1ae47c75293f5910c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468902
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Adds the file `use_literate_api_in_analyzer.dart`. This script reads
the analyzer source files and identifies any places where the old
diagnostic reporting API is being used, e.g.:
_diagnosticReporter.atNode(
node,
diag.deprecatedExtend,
arguments: [element.name!],
);
And refactors the code to use the new "literate" diagnostic reporting
API, e.g.:
_diagnosticReporter.report(
diag.deprecatedExtend.withArguments(typeName: element.name!).at(node),
);
The idea is to automate the majority of the migration from the old to
the new diagnostic reporting API by taking care of the most
straightforward cases. More complex cases are skipped; they will have
to be migrated manually. In particular, any call site that contains
one of the following things will be left alone:
- A diagnostic code that isn't a direct reference to a diagnostic code
constant (e.g., in the above example, `diag.deprecatedExtend` is ok
because it refers directly to the `deprecatedExtend` constant).
- An argument list that isn't a list literal, or is a list literal
containing flow control or spreads (e.g., in the above example,
`[element.name!]` is ok because it's a simple list literal with no
flow control or spreads).
- A comment somewhere inside the invocation. These are left to human
translation so that the meaning of the comment can be preserved.
The script also skips translation of any diagnostic codes that use the
placeholder parameter names `p0`, `p1`, `p2`, etc. The rationale is
that if we start using the placeholder names now, then in the future
when we want to assign more reasonable parameter names, refactoring
will be more difficult. In future CLs, I plan to give better names to
some of these placeholder parameters, and then re-run the script to
allow more migration to occur.
Change-Id: I6a6a696404b42ca67e5208cb4e80de17e485551c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467385
Commit-Queue: Paul Berry <paulberry@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>
Adds a temporary utility, `switch_to_camel_case.dart`, that will
switch the `messages.yaml` files to using `camelCase` for message
keys, `sharedName` fields, and `analyzerCode` fields.
In follow-up CLs, I will run the script and then remove it. This will
eliminate a significant inconsistency between the diagnostic code
formats in the analyzer and the front end.
Change-Id: I6a6a69645d4342abceb8f51d2e2e1d065ebef8d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466560
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Updates the logic in `pkg/analyzer_utilities` and
`pkg/front_end/test/messages_suite.dart` for processing
`messages.yaml` files so that:
- Message keys in analyzer-style `messages.yaml` files can be
`camelCase`, `lower_snake_case`, or `UPPER_SNAKE_CASE` (previously
they could only be `lower_snake_case` or `UPPER_SNAKE_CASE`).
- Message keys in CFE-style `messages.yaml` files can be either
`camelCase` or `PascalCase` (previously they could only be
`PascalCase`).
- `sharedName` fields can be `camelCase`, `lower_snake_case`, or
`UPPER_SNAKE_CASE` (previously they could only be `lower_snake_case`
or `UPPER_SNAKE_CASE`).
- `analyzerCode` fields in `pkg/_fe_analyzer_shared/messages.yaml` can
be `ClassName.lower_snake_case`, `ClassName.UPPER_SNAKE_CASE`, or
`camelCase`, where `ClassName` is ignored (previously they could
only be `ClassName.lower_snake_case` or
`ClassName.UPPER_SNAKE_CASE`).
This paves the way for a follow-up CL in which all these fields and
keys will be standardized to `camelCase`, and then the ability to
specify them in `lower_snake_case` or `UPPER_SNAKE_CASE` will be
removed. This will eliminate a significant inconsistency between the
diagnostic code formats in the analyzer and the front end.
Note that a few diagnostic names contain an underscore immediately
followed by a digit in their snake case representation:
- `final_not_initialized_constructor_1`
- `final_not_initialized_constructor_2`
- `final_not_initialized_constructor_3_plus`
- `lines_longer_than_80_chars`
When these are converted to `camelCase` form, the code generator will
no longer know to introduce the underscores when converting them back
to `snake_case` form (e.g. `finalNotInitializedConstructor1` will get
converted to `final_not_initialized_constructor1`). The snake case
forms are an important part of the customer facing API (since they are
what is accepted in `// ignore:` comments), so in order to preserve
the existing snake case names, a hardcoded map is introduced,
`_snakeCaseExceptions`.
Change-Id: I6a6a696444ccd92dd6574a7cde08da88ac5a7135
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will be used in a follow-up CL to recognize changes to the format
of `pkg/front_end/messages.yaml` and
`pkg/_fe_analyzer_shared/messages.yaml`.
Change-Id: I6a6a6964274aa116d9f0051ce7c099a9b8d84277
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466444
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Renames the class `AnalyzerCode` to `DiagnosticCodeName`, so that it
can be re-used for front end diagnostic codes.
Sorting makes the change look bigger than it is; there is no change
other than a rename and a few comment changes.
Change-Id: I6a6a6964190ad4d8986643c1e8be4a4b8088c5f7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466466
Reviewed-by: Konstantin Shcheglov <scheglov@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>
Changes the diagnostic message code generator so that the strings
passed to `DiagnosticCode.name` and `DiagnosticCode.uniqueName` are
always all lower case, regardless of how the name is specified in the
`messages.yaml` file.
This paves the way for a follow-up CL that will stnadardize the
capitalization of the message names in the `messages.yaml` files.
Change-Id: I6a6a6964d17d7d258ff2c1fad261072fa6f9a432
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465720
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the representation of `sharedName` in the diagnostic message
code generation logic from a simple string to an `AnalyzerCode`. This
allows analyzer codes to be treated more uniformly by the code
generation logic, which in turn paves the way for follow-up CLs that
will convert all analyzer codes in `messages.yaml` files to camelCase
representations.
Change-Id: I6a6a696441b3b69468d5843788f95f63f374c66b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465700
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With the removal of diagnostic classes from
`DiagnosticCode.uniqueName`
(https://dart-review.googlesource.com/c/sdk/+/464240), there is no
longer any code that depends on diagnostic code class names, so it is
safe to remove this field.
This paves the way for follow-up CLs that will remove the diagnostic
code class names entirely from the `messages.yaml` files.
Change-Id: I6a6a6964fc892689148f3156be37fca2be0a6b78
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465661
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This paves the way for a follow-up CL that will remove the diagnostic
class name from `AnalyzerCode`, preventing
`verify_diagnostics_test.dart` from seeing it.
Change-Id: I6a6a696446594d225f6d1cbdf70f19a4cde18b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465703
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will be used in the diagnostic message code generator, to help
with the transition from snake case diagnostic names to camel case
diagnostic names.
Change-Id: I6a6a69646a16869caa04e7b3741382b0f5d6e6cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465484
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Modifies the code generation logic that populates the
`DiagnosticCode.uniqueName` field so that it doesn't include the
diagnostic's class name.
This paves the way for removing the last remenants of the diagnostic
classes from the analyzer.
Change-Id: I6a6a696453fe1f2bd8bd3cea00a9a496392fbf98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464240
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Now that this script has been used to add `type:` entries to the
analyzer-style `messages.yaml` files, and validation is in place to
ensure that future diagnostics have `type:` entries, the script is no
longer needed.
Change-Id: I6a6a69644fda49cbbaec643c8b3950d74be88d17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464245
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Now that all diagnostic codes in analyzer-style `messages.yaml` files
have a `type:` entry, it can safely be used to determine the
diagnostic's type. This replaces the old logic that inferred
diagnostic types from the diagnostic's class name (diagnostics under
the heading `CompileTimeErrorCode` have type `compileTimeError`, those
under `StaticWarningCode` have type `staticWarning`, etc).
This paves the way for removing the notion of diagnostic code class
entirely.
Change-Id: I6a6a69646fdcaccaef6f8c32a1ebf303a54548d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464283
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds a script, `add_types_to_yaml.dart`, which will add `type:`
entries to analyzer-style `messages.yaml` files.
Currently the only function of these entries is that they are checked
against the diagnostic types implied by the diagnostic's class name
(diagnostics under the heading `CompileTimeErrorCode` must have type
`compileTimeError`, those under `StaticWarningCode` must have type
`staticWarning`, etc).
In a follow-up CL I will run the script, adding these `type:` entries,
and then change the code generation logic to use them instead of
inferring the type from the diagnostic code's class. This will pave
the way for removing the notion of diagnostic code class entirely.
Change-Id: I6a6a6964fc4c06a7b2c15fd10d0bd500c3c3f3f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464281
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the logic for parsing analyzer-style `messages.yaml` files so
that an optional `type:` entry is accepted. When present, the type
will be checked against the type inferred from the diagnostic code's
class (`CompileTimeErrorCode` has type `compileTimeError`,
`StaticWarningCode` has type `staticWarning`, etc).
In a follow-up CL I will add these `type:` entries, and change the
code generation logic to use them instead of inferring the type from
the diagnostic code's class. This will pave the way for removing the
notion of diagnostic code class entirely.
Change-Id: I6a6a6964d58f06ea6573702f9afcc61b5370eda8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/464242
Reviewed-by: Konstantin Shcheglov <scheglov@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>
No more flag, always parse into the new AST, always visit new AST nodes,
always return them as child entities, parent-child structure reflects
the new AST.
So, use `namePart` and `body` where possible. Deprecate previous
properties.
This is still de jure a breaking change, because `parent` of deprecated
properties changes. De facto this required very few changes in google3.
Once this CL lands, I will publish `analyzer 10.0.0`, migrate everything
to new properties, delete deprecated properties, and publish `analyzer
11.0.0`.
Maybe deprecate `NamedCompilationUnitMember.name` and migrate to
subclass specific `name` or `namePart` properties before publishing
`analyzer 10.0.0`. This part is not breaking per se.
* Deprecations in `ClassDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `EnumDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `name`, `typeParameters` are deprecated, use `namePart` instead.
* Deprecations in `ExtensionDeclaration`:
* Properties `leftBracket`, `members`, `rightBracket` are deprecated, use `body` instead.
* Deprecations in `ExtensionTypeDeclaration`:
* Properties `leftBracket`, `constants`, `members`, `rightBracket` are deprecated, use `body` instead.
* Properties `constKeyword`, `name`, `representation`, `typeParameters` are deprecated,
use `primaryConstructor` instead.
* **Breaking Change:** While the deprecated members mentioned above still exist in the AST,
their parent nodes have changed. This means that code relying on specific parent-child
relationships for these nodes might break.
Bug: https://github.com/dart-lang/sdk/issues/61701
Change-Id: Ic48104da8b029c9b454bbd2336574b7823025565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461841
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Kallen Tu