Add generated support for removing and replacing AST children directly
on AST nodes. Each generated implementation now knows which of its child
slots can be updated, which required slots cannot be removed, and which
NodeList slots support replacement but not resizing.
Add shared helpers on AstNodeImpl for common mutation operations:
- removeFromParent(), for clearing a nullable child slot.
- replaceWith(), for replacing this node in its parent.
- replaceChild(), for replacing a specific child even when constructing the replacement has already moved children out of the old node.
This makes child mutation slot-aware and moves the behavior onto the
generated node implementations, providing a direct replacement path for
NodeReplacer while keeping invalid removals explicit.
Change-Id: Ic2a44561170206f6006df43879a09b4eebff8a63
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499380
Reviewed-by: Johnni Winther <johnniwinther@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>
Permit `abstract` on top-level variable declarations when the
augmentations feature is enabled. Previously the parser always reported
`abstract` as extraneous at the top level, which rejected valid syntax
and dropped the modifier before later stages could see it.
Thread the abstract token through top-level field parsing, record it on
`TopLevelVariableDeclaration`, and pass it through the front-end
builders. Reorder the field callback arguments so `augment` precedes
`abstract`, matching the augmentation grammar for incomplete top-level
variables and keeping the parser, listener, and outline plumbing
consistent.
Change-Id: I680414a746b707d483e485702685c95f28a9c9ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494564
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
The class `VerifyDiagnosticsTest` is used to verify the correctness of
the values of the `documentation` keys in the `messages.yaml` files. As
a part of that, it verifies that the code snippets in the documentation
follow the rule that
- "Example" snippets generate one instance of the documented diagnostic
and no other diagnostics
- "Common fixed" snippets generate no diagnostics.
Snippets that fail to meet that criteria are not verified because
checking for them has been disabled. A common reason for failing to
meet the criteria is the production of one or more other diagnostics,
typically due to overreporting.
Not verifying them has some drawbacks.
- It's on an all-or-nothing basis; if a diagnostic is ignored all
snippets will be ignored even if only one snippet fails to follow the
rule.
- There's no indication if new diagnostics start being generated for
the snippet.
- There's no indication when the overreporting is fixed so that the
snippets can now be verified.
I propose we add a way to list the additional diagnostics to ignore and
remove these cases from the excluded diagnostics list. Specifically, I
want to add a new directive (in the test's sense, not in the language's
sense of that term) containing a list of expected other diagnostics.
I considered using an ignore comment, but errors can't be ignored this
way and sometimes the diagnostics that need to be ignored are errors.
This CL implements the proposal and removes one diagnostic from the
list as a sample of how this support will be used. If this approach
is adopted, other diagnostics can be removed from the list and the
snippets can be updated accordingly in one or more follow-on CLs.
This will _not_ remove the need for the list of ignored diagnostics
because that list has other use cases. However, I do think that we
should try to find solutions for those other use cases and eventually
remove the list entirely if possible.
Change-Id: I52b6b738e41b2163843caf915a6c0fe7f461ec44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/494620
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
DottedName previously exposed only a list of identifier components, so
the resulting string had to be reconstructed (e.g. by inserting periods)
and could lose the original token stream produced by the parser and
recovery.
Introduce an opt-in, token-based representation:
- Add `DottedName.tokens` containing the full token sequence (including '.').
- Add `useDottedNameInLibraryDirective` to let clients opt into the new shape.
- When the flag is enabled, route `library` / `part of` names through
`DottedName` (`name2` / `libraryName2`) instead of `LibraryIdentifier`.
- Update unlinked/summary serialization and builders to derive names from the
token stream when opted in, keeping offsets and lengths consistent.
- Extend the AST generator to support flag-guarded properties so the migration
can be staged without breaking existing clients.
Fixes: dart-lang/sdk#62819
Bug: https://github.com/dart-lang/sdk/issues/62819
Change-Id: Ibd9eab8919313765b321f464726ffd4c84dd6cb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/485360
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@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>
Modify the AST rewriting phase to transform `SimpleIdentifier` and
`PrefixedIdentifier` nodes into `TypeLiteral` nodes when they resolve to
a type (such as classes, type aliases, `dynamic`, or `Never`) and appear
within a value expression slot.
This change ensures a more consistent AST representation where type
references used as values are distinct from other identifiers.
Key changes include:
- Generating `isInValueExpressionSlot` methods for AST nodes to identify
valid contexts for type literals.
- Updating `AstRewriteVisitor` to perform the conversion.
- Adjusting constant evaluation, completion, and linter rules to support
`TypeLiteral` nodes in expression contexts.
- Adding comprehensive resolution tests for type literals in assignments,
conditionals, loops, and other structures.
Change-Id: I248481dc9c940dfc0cbea4950b918d2e0a3d9bb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479780
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This adds reporting of const constructor with a primary constructor body with a constructor body.
The parser is augmented to provide the start token for the error reporting.
Part of #61700
Change-Id: If5a4dd041ab2b2d812d65aabfbcc72f536b5fe7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478363
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Fixes the small number of places in the analyzer code that were using
the CFE's `withArgumentsOld` mechanism for reporting diagnostics so
that they now use `withArguments`.
Change-Id: I6a6a69647fe88fd2c3c06798bb800c028cca67eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Translates the code in `pkg/analyzer` so that it imports CFE-style
diagnostic codes from
`package:_fe_analyzer_shared/src/messages/diagnostic.dart`, rather
than using the old constant declarations in
`package:_fe_analyzer_shared/src/messages/codes.dart`.
Note that most of the analyzer code that refers to diagnostics uses
analyzer-style diagnostics. This change is just for the small portion
of analyzer code that refers to CFE-style diagnostics. To distinguish
between analyzer-style and CFE-style diagnostics, I've used the prefix
`fe_diag` for the CFE-style diagnostics.
Change-Id: I6a6a69640e38f4e261357486a245fdafa14f3d81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/475925
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the logic in `pkg/analyzer` to use
`DiagnosticCode.lowerCaseName` instead of `DiagnosticCode.name`, and
`DiagnosticCode.lowerCaseUniqueName` instead of
`DiagnosticCode.uniqueName`. This ensures that diagnostic codes are
matched in a case-insensitive fashion.
This paves the way for deprecating (and eventually removing) the
`DiagnosticCode.name` and `DiagnosticCode.uniqueName` getters.
Change-Id: I6a6a6964bae7f2d423e44211d2ad73202da65727
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/466281
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
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>
This merges endX methods for non-top-level members into endMethod, endConstructor, endFactory and endFields.
These methods now have a DeclarationKind parameter that can be used to distinguish them.
Change-Id: I458d37a70b6c7839612f7199dad95f9a61e76e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/462120
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@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>
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>
Refactors the diagnostic message generation logic, specifically the
logic for generating `// ignore_for_file:` comments. This logic is now
encapsulated in a single method,
`AnalyzerDiagnosticPackage.writeIgnoresTo`.
Also removes the logic for generating `// ignore_for_file:
deprecated_member_use_from_same_package` and `ignore_for_file:
constant_identifier_names`, which are no longer needed in any of these
generated files.
This paves the way for a follow-up CL that will introduce a new
generated file, ensuring that we won't have to duplicate this logic
when the new generated file is introduced.
Change-Id: I6a6a6964d0164244aa29b2a08dcca4c920f72e7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461143
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Changes the runtime types of the diagnostic message constants for the
analyzer from derived classes like `ParserErrorWithoutArguments`,
`ParserErrorTemplate`, or `ParserErrorCode` to the corresponding base
classes (`DiagnosticWithoutArgumentsImpl`, `DiagnosticWithArguments`,
or `DiagnosticCodeWithExpectedTypes`). The static types of the
constants are unchanged.
This allows the generated `...Template` classes (which derived from
`DiagnosticWithArguments`) and `...WithoutArguments` classes (which
used `DiagnosticWithoutArguments` as a mixin) to be removed.
Classes such as `ParserErrorCode`, `WarningCode`, etc. remain, but
they are now used solely as namespaces for the generated
constants. They will be removed in a later CL.
The runtime types of the diagnostic message constants for lints are
not changed. They remain `LinterLintWithoutArguments`,
`LinterLintTemplate`, and `LinterLintCode`, so that clients of the
analyzer public API can still identify lint codes by checking whether
they are subtypes of the public API class `LintCode`.
Change-Id: I6a6a69640886d560ba53a1b4351f634778d70db5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459500
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Replaces "is" tests that refer to classes derived from
`DiagnosticCode` with tests on `DiagnosticCode.type`:
- `x is ScannerErrorCode || x is ParserErrorCode` is replaced with
`x.type == DiagnosticType.SYNTACTIC_ERROR`. This is exactly
equivalent, because `ScannerErrorCode` and `ParserErrorCode` are the
only two `DiagnosticCode`-derived classes whose `type` method returns
`SYNTACTIC_ERROR`.
- `x is TodoCode` is replaced with `x.type ==
DiagnosticType.TODO`. This is exactly equivalent, because `TodoCode`
is the only `DiagnosticCode`-derived class whose `type` method
returns `TODO`.
- In `statement_completion.dart`, `x is! HintCode && x is!
WarningCode` is replaced with `x.type ==
DiagnosticType.SYNTACTIC_ERROR`. The new test is less accepting: for
example, it previously accepted diagnostics of type
`StaticWarningCode`. This test is used to short-cut the generation
of statement completions such as completing an incomplete `do`
statement. These completions are only necessary to generate if there
is a syntax error, so there should be no user-visible behavior
change.
- In `fix_processor.dart`, `x is LintCode || x is HintCode || x is
WarningCode` is replaced with `x.type == DiagnosticType.LINT ||
x.type == DiagnosticType.STATIC_WARNING`. The new test is more
accepting: it now accepts any diagnostic code whose type is
`STATIC_WARNING`, when previously it only accepted warnings of type
`WarningCode` (and rejected warnings of types like
`StaticWarningCode`). This test determines when quick fixes like
"ignore diagnostic on this line" are offered, so the behavior change
is appropriate.
- Also replaces a documentation reference to `TodoCode` (in
`todo_codes.dart`) with a reference to `DiagnosticType.TODO`.
These changes pave the way for a follow-up CL in which I plan to
eliminate these derived classes entirely.
Change-Id: I6a6a69647ff62dfe06b0219d8b292da53427cf0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461140
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
It is not longer necessary to have two separate classes, because all
diagnostic classes the code generation logic needs to keep track of
are now code generated diagnostic classes.
Change-Id: I6a6a69640784c841825256d94e74435404307249
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/460701
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
Konstantin Shcheglov