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>
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>
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>
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 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>
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>
The only remaining deprecated snake-case name was
`ParserErrorCode.UNEXPECTED_TOKEN`, which is no longer being used by
`package:dart_style`.
Note that the commit that removed `package:dart_style`'s use of
`ParserErrorCode.UNEXPECTED_TOKEN`
(https://github.com/dart-lang/dart_style/commit/ade6076f731c39306e3dd32608dfd00622e4492f)
was also the commit that bumped `package:dart_style`'s pubspec
dependency to permit analyzer versions >= `9.0.0`. Since the current
version of `package:analyzer` is `9.0.1-dev`, this means that `pub
get` will never pair a future version of `dart:analyzer` with a
version of `package:dart_style` that uses
`ParserErrorCode.UNEXPECTED_TOKEN`, so this removal is safe.
Change-Id: I6a6a6964a6e1dde6d8c1f1420b39f998b8a4073a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462322
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
`DiagnosticClassInfo.typeCode` is replaced with a `code` getter on the
`AnalyzerDiagnosticType` enum.
This is part of a longer term effort to remove the
`DiagnosticCode`-derived classes entirely.
Change-Id: I6a6a69641b013d7c2ce8af3f4d54c82a9980bdb7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462320
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds the abstract getter `MessageWithAnalyzerCode.package` (and
implementations thereof). This returns the package into which this
error code will be generated.
Also adds a check to the `DiagnosticTables._` constructor to verify
that the values returned by this getter are the same as the values
returned by
`MessageWithAnalyzerCode.diagnosticClassInfo.file.package`, and
changes the code generation logic to use the former instead of the
latter where possible.
This paves the way for a follow-up CL that will remove
`MessageWithAnalyzerCode.diagnosticClassInfo`, as part of a larger
effort to remove the generated `DiagnosticCode`-derived classes
entirely.
Change-Id: I6a6a6964b03e53867f7dc7f7307e8e218c080b6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462161
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Since these error codes are generated into the analysis server, it
makes sense for their yaml source to be located inside the server too.
This paves the way for a CL that will remove information about the
particular diagnostic classes from the code generation logic; once
that happens the only way for the code generation to know where to put
the generated error codes will be to look at where their yaml source
is defined.
Change-Id: I6a6a6964418eb42bdabd129a1a19848a1fc22ebb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461982
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Removes the TODO message suggesting that the messages in the
`sharedAnalyzerCodes` variable should be sorted by `camelCaseName`. It
turns out these messages are already sorted by `camelCaseName`.
Also adjusts the documentation string above
`DiagnosticTables.sortedSharedDiagnostics` (the table that
`sharedAnalyzerCodes` is built from during code generation) to clarify
that it is sorted by `camelCaseName`.
Change-Id: I6a6a696499dcae105a1bd6ba4e8a4569a17bc596
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461522
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Now that diagnostic message constants have been fully transitioned to
top level constants, there is no need for the old functionality of
generating them as static fields in classes.
Change-Id: I6a6a6964f61c0d97545fa96ddb6ed48e103d7a8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461525
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, this list was sorted by the full analyzer code
(`ClassName.diagnosticName`). That made sense when the constants in
the list were referenced by `ClassName.diagnosticName`. Now that the
constants are referenced by `diag.diagnosticName`, it makes sense for
the sorting to fit.
The order of entries in this list has no user-visible effect, so from
the user's point of view there is no functional change.
Change-Id: I6a6a696468fa533d6d9d7b9f12914c070c0713af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461585
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the constant `generateTopLevelConstants` from `false` to
`true`, which moves the generated constants for analyzer diagnostics
so that they are now top level constants inside files called
`diagnostic.g.dart`, rather than static constants inside
`DiagnosticCode`-derived classes such as `CompileTimeErrorCode`.
To avoid breaking code in the analyzer and related packages, the
constant declarations inside `DiagnosticCode`-derived classes still
exist, but they simply redirect to the constants in the new
`diagnostic.g.dart` files. The redirecting constants will be deleted
in a follow-up CL.
This CL was created by the following steps:
- Change the constant `generateTopLevelConstants` from `false` to
`true`.
- Re-run diagnostic code generation.
- Manually adjust imports in the parent libraries of the generated
files as needed to fix compile-time errors.
There are no other changes.
Change-Id: I6a6a6964f574bc9ff4ab74b2c6b218842991708b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461440
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@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>
Updates some of the logic in `analyzer_messages.dart` to make use of
the getter `AnalyzerCode.analyzerCodeReference`. There is no change in
the generated code.
This paves the way for a follow-up CL that will move the declarations
of the analyzer diagnostic constants out of classes like
`CompileTimeErrorCode` and to top level constants. When that move
happens, references to these constants will need to be
changed. Consolidating more of the logic in `analyzer_messages.dart`
to use `analyzerCodeReference` reduces the number of places in the
code generator that will need to be updated in order to change these
references.
Change-Id: I6a6a6964534cb68074f316c4f2c914e957b37528
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461144
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Kallen Tu