Changes signature of Iterable.singleWhere.
Makes LinkedHashMap no longer be a HashMap.
Change-Id: Ibd7e56e1ac03cb9fb10d19d1328d452fcd06d89f
Reviewed-on: https://dart-review.googlesource.com/32541
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The latter was already passing (because FutureOr<void>.isVoid is true
already, which was a condition of early bailout for MISSING_RETURN).
The former was not working, but is now handled.
Unit tests for each.
Change-Id: I0f6e7ddc71940517c5746c1a5431f4491ee2eef3
Reviewed-on: https://dart-review.googlesource.com/37440
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
In addition to updating the fasta parser error messages, this CL
updates the recovery tests to automatically allow break/continue errors
in the valid and recovery code if those errors appear in the
base code being tested. For example, if the base code is
main() { break; }
the invalid code is
main() { var a break; }
and the expected recovery code is
main() { var a; break; }
then because the base code has a break-error, then that error
is allowed/expected in both the invalid and recovery code
without being explicitly listed in the test.
Change-Id: Ic7c188d6e6fb506ee83b8c99175caab3a82444f2
Reviewed-on: https://dart-review.googlesource.com/38500
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Before any ASTs are constructed, a lookup happens to see if such a constructor exists, otherwise the AST replacement will not proceed, and even temporary ASTs will not be created: in this way we can add the test test_visitMethodInvocations_not_implicit_constructor.
Change-Id: I01e25af5d1eaec659cf02ca89f8a9a5da334e6a9
Reviewed-on: https://dart-review.googlesource.com/37920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jaime Wren <jwren@google.com>
I could not add a test into element_resolver_test.dart as the scope lookup logic does not resolve the type "Object" to the ClassElement for the type Object, that is:
test_visitMethodInvocation_implicit() async {
// Object()
InterfaceType obType = _typeProvider.objectType;
MethodInvocation invocation = AstTestFactory.methodInvocation2("Object");
// The invocation element in visitMethodInvocation is not resolved to be a
// ClassElement in this test harness.
}
This prevents this source from being invoked.
I was however able to get this test, and an accompanying test for named constructors, to work in resolver_test.dart. It felt like the wrong test file to include so I left the tests out- do advise.
test_visitMethodInvocations_implicitConstructor() async {
String code = '''
class A {
A() {}
}
main() {
var v = A(); // marker
}
''';
CompilationUnit unit = await resolveSource(code);
AstNode constructorName = findMarkedIdentifier(code, unit, "(); // marker");
InstanceCreationExpression instanceCreationExpression =
constructorName.parent.parent.parent;
expect(instanceCreationExpression, isNotNull);
expect(instanceCreationExpression, isNotNull);
expect(instanceCreationExpression.constructorName.type.type, isNotNull);
expect(instanceCreationExpression.constructorName.staticElement, isNotNull);
expect(instanceCreationExpression.staticElement, isNotNull);
expect(instanceCreationExpression.staticType, isNotNull);
}
Change-Id: I03214c194f1052d000d7f5e840df80d4f66e2a82
Reviewed-on: https://dart-review.googlesource.com/36365
Commit-Queue: Jaime Wren <jwren@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This warning fires if a top level initializer depends on the type of a
method whose type is subject to type inference. This warning is
needed because the analyzer implementation of top level type inference
doesn't guarantee that the method type will be inferred prior to the
initializer, so it's possible that type inference will produce an
incorrect result. See #31925 for more details.
Change-Id: Iec048d2638877c16ae11a87eae0382b7352f726c
Reviewed-on: https://dart-review.googlesource.com/36841
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The old implementation only validated a whitelisted set of use cases,
so it would often miss important subexpressions. The new
implementation is based on a RecursiveAstVisitor so by default it
visits all subexpressions; we use overrides for the specific cases
where it's not necessary to visit all subexpressions.
Fixes#31963.
Change-Id: Icb9833f51bef26874f655cd2ba4ffc509bfffef3
Reviewed-on: https://dart-review.googlesource.com/36803
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
If an implicitly typed top level variable or field depends on an
implicitly typed instance getter or instance field, the analyzer
implementation of type inference isn't guaranteed to infer the
depended-upon field first, therefore the type might be inferred
incorrectly.
The new front end doesn't have this problem, so the user's code will
execute correctly at runtime, but they might get confusing results
from the analyzer. To alert users of this problem, we issue a
compile-time warning whenever an implicitly typed top level variable
or field depends on an implicitly typed instance getter or instance
field.
Change-Id: I100bcbe1a76472bcb7d493eb12e4a3e2d0605e79
Reviewed-on: https://dart-review.googlesource.com/35385
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In addition to adding missing errors, this CL inlines modifier parsing
as part of a multi step effort to parse modifiers once and provide
better error recovery for class member and top level declarations.
Change-Id: Ibea91a4a3e2073ed6079f0f44ff4bbbb4a98a614
Reviewed-on: https://dart-review.googlesource.com/35300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
A fairly internal case, so I ended up guarding it semi-heavily with
asserts, which could go against convention, but seems fairly safe here.
Two tests: One that sanity checks some edge cases & exemplary values,
and another one that checks each combination programmatically. Together
they should be the best coverage; both the reliance of computers and
the simplicity of specific cases.
Should be very easy to pop in the void type here next.
Bug: 28513
Change-Id: Id20811a77b4de3f2c4ede7a77e1da5a114432e97
Reviewed-on: https://dart-review.googlesource.com/34305
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Brian Wilkerson