* Replace `identifier` field with `expression`, which means deprecating
`identifier`, redirecting users to `expression`. For now, `expression`
always returns an Identifier. In a future breaking release, it will
return other CommentReferableExpressions.
* SimpleIdentifier, PrefixedIdentifier, PropertyAccess,
ConstructorReference, FunctionReference, and TypeLiteral are all
CommentReferableExpressions, but support is not implemented yet to
parse CommentReferences with those contained expressions.
Bug: https://github.com/dart-lang/sdk/issues/47444
Change-Id: I1905afecf3878cd7dca6e275ef0a2ab80500eb4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216320
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Janice Collins <jcollins@google.com>
This will allow tests to verify multiple substrings are present in the
error message without having to include all the intervening text
(which would make the tests brittle).
Change-Id: I8aeaa7edb7b6da0eadf8c12e8c01d7e0805d9b27
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/217822
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We now print any non-null values of `ExpectedError.message`,
`ExpectedError.messageContains`, and
`ExpectedError.correctionContains`. This should make it easier to
understand what has gone wrong when there's a mismatch due to an
incorrect message or correction string.
Change-Id: I50359008ad15b894b1a5c5512ff6847d07193408
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216820
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Evaluation of a constructor's initializers (field initializers, assert
initializers, and super initializer) are all so much complexity separate
from evaluating a simpler const object that they deserve their own test
classes.
* Move all tests using assert initializers from very old
non_error_resolver.test and from constant.dart to
InstanceCreationEvaluatorTestCases.
* Move many test cases into *TestCases so they are tested in pre- and
post-null safety.
* Introduce more basic tests for assert initializers.
Bug: Preparation for https://github.com/dart-lang/sdk/issues/46081
Change-Id: Ie3e21d2457b1ba34667f85a0f5e3ef0e558f5cb3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This change moves tests out of the older-style test file. In addition:
* additional tests for uninstantiated function tearoff identity.
* additional tests for using a type parameter as a type argument in a
function tearoff in a const expression.
Change-Id: I6c6a6db13144e02794a62d78337013b4a525549a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214139
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In particular:
* integerDivide tests are well-covered in value_test.
* There was not great coverage for logicalShiftRight, so I improved
coverage in value_test.
* remainder tests are well-covered in value_test.
* shiftLeft tests are well-covered in value_test.
* shiftRight tests are well-covered in value_test.
* times tests are well-covered in value_test.
Change-Id: I4d9e584119dbd9c05ad5deae783429636a0b9218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213803
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Previously we had identified this error with the analyzer error code
CompileTimeErrorCode.WRONG_NUMBER_OF_TYPE_ARGUMENTS_CONSTRUCTOR, but
they're not the same error at all. As a result, code like this:
var x = new a.b.c<C>();
would lead to the bogus analyzer error text "The constructor '{0}.{1}'
doesn't have type parameters." (with the placeholders "{0}" and "{1}"
visible to the user).
With this change, the error text is the same as that from the CFE: "A
constructor invocation can't have type arguments after the constructor
name."
Change-Id: Ib69d1ff8f7089e59b71d2dcd9a8ec51edffd94dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213621
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
`typeInstantiate` is a new "operation" in const expressions. It doesn't
do much, but does find the correct staticElement to be used in the
FunctionState.
Instantiated static type is necessary on a FunctionMember.
Change-Id: I15b72c870ce9bfc2b8b1fc592553c988e9cc243c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212604
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
E.g. if reporting a missing ";" after a SyntheticStringToken (e.g. a
inserted identifier) before this CL it would go to the next token and
say we expected the ";" after that, when really we expected it *before*
that token.
Change-Id: I2c358e017edb2f661e307eba03dddaee889086d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205799
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This should reduce the risk of mistakes, since there are many call
sites that create FlowAnalysisHelper objects, and we would have subtle
bugs if the call sites disagreed about when certain pieces of flow
analysis logic should be enabled.
Change-Id: I2c58eebbe05724b231107a0681c9ea668f5d968f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211502
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When the parser encounters a `<` after an expression, it must choose
whether to interpret it as a relational operator or a <typeArguments>
selector. The disambiguation rule is: if the `<` and the tokens
following it *can* be parsed as <typeArguments>, and the token that
follows is a member of a privileged set of tokens, then it is treated
as a <typeArguments> selector; otherwise it is treated as a relational
operator.
This change reduces the privileged set of tokens to the following:
- the "continuation tokens" `(`, `.`, `==`, and `!=`
- the "stop tokens" `)`, `]`, `}`, `;`, `:`, and `,`
The names "continuation tokens" and "stop tokens" reflect the
rationale for choosing these tokens:
- Continuation tokens are tokens that we can reasonably imagine a
programmer wanting to place after a type argument selector to
*continue* the expression. For example, `if (List<int> == T) ...`
is allowed.
- Stop tokens are tokens that can't possibly follow a `>` that is a
relational operator, because they *stop* the expression that's in
progress. For example, `var x = List<int>;` is allowed.
If a user wants to follow a <typeArguments> selector with a token
other than the ones above, they'll have to parenthesize the
expression. So for example, if they want to do `List<int> + 1` (which
could be meaningful if an extension method defined `operator +` for
the type `Type`), they will have to use parentheses, and instead write
`(List<int>) + 1`.
Bug: https://github.com/dart-lang/language/issues/1806
Change-Id: I2816cdac24e55eac3cb3e9920e276404c1228d46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210941
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Previously, the only circumstance in which it was null was during a
few unit tests, and this is easily fixed by creating a
FlowAnalysisHelper object when setting up those tests.
Change-Id: Ida083ec218a2b1ee910bca747a8f5eb320828527
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210280
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With this change, the analyzer logic for performing scope lookups is
now fully separated from the logic for doing type analysis and flow
analysis (ResolverVisitor now only does the latter; the former is done
by ScopeResolverVisitor and ResolutionVisitor). The analyzer now has
a similar separation of concerns between scope lookups and type/flow
analysis as the CFE does; this should help pave the way for sharing
resolution logic between the analyzer and the CFE in the future.
Change-Id: Ie006dfe1b5943bb361dc0aec4525e21572e21e5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209381
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In the two LibraryAnalyzer classes, the list of visitors is always
empty, so there are never any "visitor based lints" to run. (I
suspect that all the visitor based lints were long ago converted to
use the node registry, leaving this code dead).
Removing the last remnants of the visitor based lint logic allows us
to remove the ExceptionHandlingDelegatingAstVisitor class, which in
turn allows us to move its logException method into a simpler class.
In a follow-up CL, I will expand on this class to allow its behavior
to be customized.
Change-Id: I1261a94572ea65eb220a58fb45f6d887e6497fe9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208140
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Konstantin Shcheglov