Use the TFA direct-call metadata to directly call a closure in function
invocations.
Closes#55231.
Tested: existing tests cover the new code paths, but I also added a new
test.
Change-Id: Ib5f26b10efd77570e256196b4bfb07e6bef800c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397260
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
The new formatter supports opting a region of code out from being
formatted. I'm applying this marker to all of the multitests since
those tests are often very sensitive to formatting and easily broken.
This way, anyone touching a multitest (including me when I reformat
the tests) doesn't have to remember to not run the formatter on it.
Unfortunately, this doesn't opt out 100# of the multitests. There are a
handful of multitests that also contain "@dart=" comments and are thus
formatted using the old style where the "// dart format off" marker has
no effect. For those, we'll have to still be careful to not accidentally
format them.
Change-Id: I257d0ee1eb44eee57047be06b8520f0ccc7b56d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396162
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Consider the following code:
void f<T extends void Function(int)>(List<T> x) {
x.first(0);
}
While analyzing the expression `x.first(0)`, the analyzer has to do two things:
- Convert the AST representation from a MethodInvocation (which is
what was initially parsed) to a FunctionExpressionInvocation
targeting a PrefixedIdentifier. This reflects the fact that the
invocation isn't a method invocation after all; it's a function call
invocation applied to a property get.
- Convert the static type of `x.first` from `T` to its bound, `void
Function(int)`, in order to type check the invocation. This is done
using the `TypeSystemImpl.resolveToBound` method.
Previously, `TypeSystemImpl.resolveToBound` was called as part of
converting the AST representation, and the resolved bound (`void
Function(int)` in this example) was stored as the static type of the
FunctionExpressionInvocation target. This led to some minor
inaccuracies in the AST representation (since the type returned by
`TypeSystemImpl.resolveToBound` is *not* the correct type of the
FunctionExpressionInvocation target).
With this change, the call to `TypeSystemImpl.resolveToBound` happens
during resolution of the FunctionExpressionInvocation instead,
allowing the target of the FunctionExpressionInvocation to retain its
correct static type.
I'm in the middle of a larger arc of work trying to introduce a new,
simpler mechanism for flow analysis to be told about the static types
of property gets, and part of that arc of work will involve
introducing a temporary check to verify that the old and new
mechanisms see the same static types. Fixing this incorrect type will
allow the temporary check to pass.
This change also has the side effect of fixing
https://github.com/dart-lang/sdk/issues/56907 (Analyzer fails to
propery type check invocations of complex expressions whose type is a
type parameter). This bug was happening in circumstances where a
FunctionExpressionInvocation arises directly from parsing (rather than
being created from a MethodInvocation), and the static type of the
target is a type variable. Previously, the analyzer was failing to
convert the static type to its bound when analyzing the
FunctionExpressionInvocation, so it was failing to type check the
invocation. Moving the call to `TypeSystemImpl.resolveToBound` into
FunctionExpressionInvocation resolution ensures that the type is
properly resolved to its bound in _all_ circumstances where a
FunctionExpressionInvocation occurs.
Fixes https://github.com/dart-lang/sdk/issues/56907.
Bug: https://github.com/dart-lang/sdk/issues/56907
Change-Id: Id648d5289a6cabe95b8410abd19898acb97fc5e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/390661
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Today, most tests that touch on a behavior variation end up
skipping expectations or the entirety of a test for some
testing configurations. Moving forward, we'd like skip less
and try to account for the behavior variations if that's
reasonable.
This CL shows an approach to improve our test coverage for
behavior variations. We introduce two new methods to
[Expect] that allow us to conditionally check that a
function throws, depending on variation predicates.
The CL changes expectations for errors that don't occur
when dart2js omits parameter type checks or implicit
downcasts.
Note: originally I had the intention to introduce a name
parameter to `Expect.throws` and `Expect.throwsTypeError` to
avoid introducing a new API. However, because these APIs are
used for testing core language features, such as function
parameters themselves, we decided to keep the use of
features in these APIs as simple as it can be.
CoreLibraryReviewExempt: no public library semantic change - only improving test coverage under variations
Change-Id: I531657622655778491eaca8b37ba69ffaab559fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351340
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This updates tests to start using `checkedParamters` and
`checkedImplicitDowncasts` instead of `dart2jsProductionMode`
CoreLibraryReviewExempt: no semantic changes - only updates to use new pkg/expect variations properties
Change-Id: Ie717b4fd44590ff1f977142cf5802c4aace34dea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346910
Reviewed-by: Mayank Patke <fishythefish@google.com>
Language spec does not require that evaluations of the same function
literal should create distinct objects. Remove the parts in `Function`
documentation to reflect that.
Also fixes formatting of markdown.
Invalid test file (with Dart 2 and 3 versions) removed: the tests assume
function literals won't be lifted to top-level.
Change-Id: Ib7a9464ad992cf461e77ef2d8ef336c7b0f4875a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/269721
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Marks `Function` as an extensible type so that DDC knows to use the
symbolized version of the equals operator.
The `Function` class at runtime already has its equals method attached
as the "symbolized" version. Consider `a == b`. When DDC knows `a` is
statically a raw `Function` and non-nullable (more likely with sound
null safety) the generated code should call the symbolized equals
member ex: `a[$_equals](b)`. Without this change the generated code
would be `a.equals(b)` and fail at runtime because the method does
not exist.
With this change co19_2/LibTest/core/Function/operator_eq_A01_t01
starts passing.
Change-Id: I80dd2abbbb04f1b7ab7e21dd14561a45f6e81459
Fixes: https://github.com/dart-lang/sdk/issues/45601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194204
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Robert Nystrom