The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a696467d5dd49e7b44e9fc9000af67504f71c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471762
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a6964bd3211ce15e9b7d96eb98e30d94e9cc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471922
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a696493d545d721d88cb436dba69bd772c21c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471902
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the analyzer code that reports the following errors to use the
literate diagnostic reporting API:
- `undefinedEnumConstant`.
- `undefinedGetter`.
In the process I've cleaned up the type of the second argument (now
called `type`). Previously, some call sites passed in a type and
others passed in a string; now all call sites pass in a type.
Change-Id: I6a6a6964ebeb31ee388432242374df288c896350
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471892
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Converts all analyzer logic that reports the error
`undefinedConstructorInInitializerDefault` to use the literate
diagnostic reporting API.
Previously, one of the call sites passed in a `String` for the
argument, and the other call site passed in a `DartType`. To improve
type safety, I've converted the error to always expect a `String`.
Change-Id: I6a6a69646678a9a0de8f252908eb0b2f6db56854
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471920
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the method `_ClassVerifier._checkDirectSuperTypeNode` to use
the literate diagnostic reporting API.
Also removes the `DiagnosticCode` parameter from
`ErrorVerifier._checkForExtendsOrImplementsDisallowedClass`, which was
not used.
Change-Id: I6a6a696491f4d87d019bd1435f555da1835e7a28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471887
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a6964f4240aa3dafdd7535fdf387143d7e8be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471900
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a6964f37eb51e19869171c9fde662e916f573
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471883
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a696472b2c2edc6a90a3068ac506980a6aa30
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471581
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes all uses of the analyzer's `TopLevelInferenceError` class to
use the literate diagnostic reporting API. To preserve the type safety
guarantees that the literate API provides, I reworked the
`TopLevelInferenceError` class so that it is a sealed class hierarchy,
with each subclass containing a field of the appropriate argument
type.
I also removed the enum value `TopLevelInferenceErrorKind.none`, which
was not used (the lack of a top level inference error is represented
by `null` rather than this enum value).
Change-Id: I6a6a6964c1a39bd700d5fc00e5a782585d63a73f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471864
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a696471331bc9175265619206a0011959bf6a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471611
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a6964fd5560c41fa4f08a6ecae3a33d887dfd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471604
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the `ErrorVerifier._checkForInvalidModifierOnBody` method to
use the literate diagnostic reporting API.
Note that although there was a parameter to allow the caller to
specify the diagnostic code, the value passed into that parameter was
always `diag.invalidModifierOnConstructor`, so I went ahead and
inlined it.
Change-Id: I6a6a6964eeb862205a74b70c9aa541fadb8d1945
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471600
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a696445970ebc7cb0438e7d86ab08da4eed55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471582
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the analyzer logic that reports the following errors to use
the literate diagnostic API:
- mixinApplicationNoConcreteSuperInvokedMember
- mixinApplicationNoConcreteSuperInvokedSetter
Change-Id: I6a6a6964c7d457f8cae92ae2830cca95bd754558
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471606
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Changes the analyzer logic that reports the following errors to use
the literate diagnostic reporting API:
- missingDefaultValueForParameter
- missingDefaultValueForParameterPositional
Change-Id: I6a6a6964db77147967d14c03e5bbbb5637565a0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The return types of the following methods are changed to
`ExpressionTypeAnalysisResult`:
- `NullShortingMixin.finishNullShorting` (previously returned
`SharedTypeView`).
- `NullShortingMixin.handleNullShortingStep` (previously returned
`void`).
- `TypeAnalysisNullShortingInterface.finishNullShorting` (previously
returned `SharedTypeView`).
- `TypeAnalyzer.analyzeExpression` (previously returned
`SharedTypeView`).
With one exception, these methods previously returned a
`SharedTypeView` representing the expression's static type. (The
exception was `NullShortingMixin.handleNullShortingStep`, which
previously returned `void`).
This paves the way for allowing these methods to return additional
information beyond the static type of the expression, such as flow
analysis results and tree rewrite information. (This information is
currently carried around in auxiliary data structures, which leads to
bookkeeping headaches and increases the risk of bugs.)
Change-Id: I6a6a6964572a5fd7fac5496cdbfbc82a10272bba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471323
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Converts the analyzer code that reports the errors
`extraPositionalArguments` and `extraPositionalArgumentsCouldBeNamed`
to use the literate diagnostic reporting API.
Change-Id: I6a6a6964e8d83f460c8ecb95c4a85920d189a211
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471580
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a6964a03b0adf56bde690957bdbe2bf96743a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471520
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Converts all the calls to
`DiagnosticReporter.atConstructorDeclaration` to use the new literate
diagnostic reporting API.
This change had to be done manually because there is no
`atConstructorDeclaration` method in the new API; instead, the
extension method `ConstructorDeclarationExtension.errorRange` is used.
Change-Id: I6a6a696455c1897bc6b079735266cf80e12458ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Also, reworks the error reporting logic in `diagnostic_factory.dart`
to use the analyzer's literate diagnostic reporting API.
This required giving parameter names to the following diagnostic messages:
- duplicatePatternAssignmentVariable
- duplicatePatternField
- referencedBeforeDeclaration
Change-Id: I6a6a6964b53b6571e992702ffb622fc7791f6ee2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471303
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Converts all the diagnostic reporting logic in
`ErrorVerifier._checkForUnnecessaryNullAware` to use the new literate
diagnostic reporting API.
This required a nontrivial rewrite of
`ErrorVerifier._checkForUnnecessaryNullAware`, because the previous
version had some nontrivial interleaving of the logic that computes
the `DiagnosticCode` to report, and the logic that computes the
`List<Object>` of arguments to pass to it. It wasn't possible to
trivially convert this to the more type-safe literate diagnostic API
without untangling it first.
I believe the new version is more straightforward and easier to read,
because:
- In the old version, the logic for deciding which diagnostic to
report was based in part on the kind of null-aware operator, and in
part on an enum value passed in by the caller. In the new version,
it's almost entirely based on an enum passed in by the caller
(except that the choice between `invalidNullAwareOperator` and
`invalidNullAwareOperatorAfterShortCircuit` is made at the last
minute, because it depends on whether short-circuiting is in
effect).
- All the logic for choosing the `DiagnosticCode` and the arguments to
apply to it is now in one place
(`_NullAwareKind.locatableDiagnostic`), so it's easy for the reader
(and the compiler) to verify that the diagnostic code and its
arguments are properly matched up.
- In the old version, the role of deciding whether the expression in
question was null-aware (and thus needs an "unnecessary null aware"
check) was split between the caller and
`_checkForUnnecessaryNullAware`. In the new version,
`_checkForUnnecessaryNullAware` is only called when the expression
is truly null-aware.
- In the old version, there were three separate calls to
`diagnosticReporter`: one to handle static member accesses, one to
handle short-circuiting, and one to handle all other cases; one of
these three made use of the helper function
`DiagnosticFactory.invalidNullAwareAfterShortCircuit`, making the
calls look quite different even though their behavior was quite
similar. In the new version, all the logic funnels into a single
call to `diagnosticReporter`.
Change-Id: I6a6a6964b75016ae5f92a86c176c066c41542445
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471027
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Changes the behavior of `FlowAnalysis.cascadeExpression_afterTarget`
so that if the cascade is null-aware, flow analysis automatically
accounts for the resulting control flow split. Previously, the caller
had to account for the control flow split via a separate call to
`FlowAnalysis.nullAwareAccess_rightBegin`.
This is accomplished by extracting the implementation of
`FlowAnalysis.nullAwareAccess_rightBegin` to a private internal
method, and calling it from
`FlowAnalysis.cascadeExpression_afterTarget`.
This paves the way for a chain of follow-up CLs that will simplify how
flow analysis associates `ExpressionInfo` objects with expressions. It
makes the follow-up CL chain simpler by avoiding the need for some
complex gymnastics to carry an `ExpressionInfo` object between the
call to `FlowAnalysis.cascadeExpression_afterTarget` and a follow-up
call to `FlowAnalysis.nullAwareAccess_rightBegin`.
Note that this change creates some asymmetry, because it is still
necessary for the caller to call `FlowAnalysis.nullAwareAccess_end`
before calling `cascadeExpression_end`. I will address this in a
follow-up CL; for now I've left a TODO comment in
`_FlowAnalysisImpl.cascadeExpression_end`.
Change-Id: I6a6a696483dec4eb4770f63a05cd7c0e16443ae4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471341
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The main bit of this change is to change `add` to `operator []=` and
`getOptions` to `operator []`.
`firstOrDefault` is unused, `forEachOptionsObject` can be replaced with
a for-loop over the options values, and `get _allOptions` can be folded into `get options`.
I also removed all of the "this API is experimental and subject to change" as I think that ship has sailed.
Change-Id: Id9ebe21f35dbad822fa71a5f987b8cf0885c29d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471326
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Changes the resolution logic that rewrites `DotShorthandInvocation` or
`MethodInvocation` into `DotShorthandConstructorInvocation` or
`FunctionExpressionInvocation`, so that it the newly created
expression objects are resolved immediately (by calling
`InstanceCreationExpressionResolver.resolveDotShorthand` or
`FunctionExpressionInvocationResolver.resolve`). Previously the
resolution of these new objects was deferred several layers up the
call stack, to `ResolverVisitor.visitDotShorthandInvocation` or
`ResolverVisitor.visitMethodInvocation`.
This reduces bookkeeping, allowing many resolution methods to return
`void` that previously returned the rewritten expression object. It
also makes resolution logic easier to reason about, by changing the
behavior of methods like `MethodInvocationResolver.resolve` and
`ElementResolver.visitMethodInvocation` so that they always fully
resolve the node they are acting upon (previously they only fully
resolved the node if it was not rewritten).
Note that a few methods still return the rewritten node
:
- `MethodInvocationResolver._resolveReceiverTypeLiteralForDotShorthand`
- `MethodInvocationResolver._rewriteAsFunctionExpressionInvocation`
- `MethodInvocationResolver.resolveDotShorthand`
- `ElementResolver.visitDotShorthandInvocation`
This is necessary because there is some logic in
`ResolverVisitor.visitDotShorthandInvocation` that is skipped if the
node is rewritten into a `DotShorthandConstructorInvocation`. I'm not
certain why this logic needs to be skipped. I will investigate this
and do additional clean-up in a future CL. For now I've left a TODO
comment.
Change-Id: I6a6a6964fbc8dab2d3f3d86c780a7659717ab076
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/469480
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This simplifies reporting logic by avoiding "already reported by the
parser" case. Also, in a follow up CL I plan to support declaring formal
parameters, which do not look as `this._foo` syntax. Supporting this in
the parser would require duplicating more complex logic of building
elements in the analyzer.
Another way to think about it, is that from parser point of view the
code is fine - we did not skip or add any tokens. We can parse and
format this code. But the semantics is not quite right, so it makes
sense to put it in a different place.
Change-Id: I783ed6780e6d66e276c5ed44f08e6ac04145cd1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/470920
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This diagnostic is reported in two circumstances:
- During resolution of a dot shorthand like `const .foo()`, when the
implicitly-referred to class doesn't have a constructor with the
given name.
- During resolution of a const constructor invocation like `const
int.foo()`, when the explicitly-referred to class (`int` in this
example) doesn't have a constructor with the given name.
In both cases, the diagnostic message includes the names of both the
class and the constructor that was sought. But in the first case, the
class name was accidentally derived from the type inference context
rather than the dot shorthand context; these are different in the case
where the dot shorthand appears on the RHS of `==`. Fixed by supplying
the correct context type.
This bug was discovered in the process of converting the analyzer to
use the new literate error reporting mechanism: I needed to assign a
type to the diagnostic message parameter that was to contain the class
name and discovered that I couldn't give a consistent type, because it
was sometimes being filled in with a class name string, and it was
sometimes being filled in with a type. With the fix, it is always
filled in with a class name string.
I also included tests of the other dot shorthand related diagnostics
that mention the class name (they don't exhibit the same bug), as well
as a typo fix for `wrongNumberOfTypeArgumentsDotShorthandConstructor`
(which had mismatched quote symbols).
Fixes https://github.com/dart-lang/sdk/issues/62352.
Change-Id: I6a6a696421b68397b86aac9b1a6e91cce08250ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/470942
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only changes in this CL that were manually written are those in
`messages.yaml`. The others were produced by running the standard
diagnostic message code generator and then running the script
`use_literate_api_in_analyzer.dart`.
Change-Id: I6a6a69645bab7cf8f26ec9524a7bc2294e4a3b3a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/471020
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Changes the uses of `DiagnosticReporter.atElement2` in
`evaluation.dart`, `base_or_final_type_verifier.dart`, and
`getter_setter_types_verifier.dart` to use the new literate diagnostic
reporting mechanism.
Change-Id: I6a6a6964cff8afd9867c2606f3aea334f135cf03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/470820
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov