Using `expectStaticType` is a more effective test, because it verifies
that the type is _exactly_ what is expected. It also makes the test
easier to read.
Change-Id: I4b0a22f32601a5dca830a182ff4d37cddd657776
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340580
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Now that we no longer need to support legacy (pre-2.12) code in
google3, we don't need to test our support for it either.
Most of our language tests for legacy code were in `tests/language_2`
and have already been deleted; this CL addresses the few tests that
remain in `tests/language`, mostly dealing with "mixed mode" scenarios
(i.e., interactions between legacy code and null safe code).
Change-Id: I023d84547fdf17fb0599c82fbeb4fd07252ccf0f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341020
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
A quirk of analyzer and CFE implementations is that they resolve
property gets such as `foo.bar` to specific field or getter
declarations that may be not be directly defined on the target type;
for example if `foo` has type `B`, and `B` extends `A`, and `A`
contains a field called `bar`, then `foo.bar` is considered to refer
to `A.bar`, for example:
class A {
int? bar;
}
class B extends A {}
f(B foo) {
print(foo.bar); // Resolved to `A.bar`.
}
This is in contrast with the language specification, which makes a
clean distinction between class _declarations_ and the _interfaces_
implied by those declarations. While a class declaration can contain
(among other things) both getters and fields, which might be concrete
or abstract, an interface doesn't distinguish between getters and
fields, and is inherently abstract.
The advantage of the analyzer/CFE approach is that it allows more
intuitive error messages and "go to definition" behavior, which
benefits users. But it has some ill-defined corner cases involving
complex class hierarchies, because not every property access can be
resolved to a unique declaration (sometimes a getter is multiply
inherited from multiple interfaces, for example). The language spec
approach has the advantage of being well-defined and consistent even
in situations involving complex class hierarchies.
When I initially implemented field promotion, I took advantage of this
quirk of the analyzer and CFE implementations, so that I could make
property gets that refer to field declarations promotable, while
keeping property gets that refer to abstract getter declarations
non-promotable. This caused unpredictable behaviors in the ill-defined
corner cases. It also meant that in certain rare cases, a property
access might not be promoted even when it would be sound to do so
(e.g. a property access might refer to a private abstract getter
declaration, but the only concrete _implementation_ of that abstract
getter was a final field).
This CL changes the rule for promotability so that any get of a
private property is considered promotable, provided that the
containing library doesn't contain any concrete getters, non-final
fields, or external fields with the same name. It no longer matters
whether the private property refers to a field or a getter. This rule
is simpler than the old rule, restores the spec's clean distinction
between class declarations and interfaces, and allows more promotions
without sacrificing soundness.
For additional details please see the breaking change announcement at
https://github.com/dart-lang/sdk/issues/54056, as well as the original
change proposal at https://github.com/dart-lang/language/issues/3328.
Fixes https://github.com/dart-lang/sdk/issues/54056.
Fixes https://github.com/dart-lang/language/issues/3328.
Change-Id: I38ffcb9ecce8bccb93b1b2586a1222a0fb1005a7
Bug: https://github.com/dart-lang/sdk/issues/54056
Bug: https://github.com/dart-lang/language/issues/3328
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337609
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change implements one of the features of experimental feature
`inference-update-3`: with the experimental feature enabled,
assignments to local variables use the declared (or inferred) type of
the local variable as the context for evaluating the RHS of the
assignment, regardless of whether the local variable is promoted. With
the experimental feature disabled, assignments to local variables
continue to use the promoted type of the local variable as the context
for evaluating the RHS of the assignment.
This eliminates one of the scenarios in which the context type of an
assignment is "aspirational" (i.e., not required to be met in order to
prevent a compile time error). Once all aspirational context types
have been removed from the language, we will be able to re-work
coercions to be based on context type, which fixes a number of
usability footguns in the language. See
https://github.com/dart-lang/language/issues/3471 for details.
Bug: https://github.com/dart-lang/language/issues/3471
Change-Id: Ic07ac1810b641a9208c168846cd5fd912088d62b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338802
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests were just failing on the VM for a very long time.
Rewrite them into a simpler version that just tests conditional
importing rather than trying to do clever things with HttpRequest.
R=eernst@google.com
Change-Id: Iebb7f6210ae4f2215c9445695189533116ffb5b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338160
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Use generic types in type tests. This causes types to be retained.
Fixes:
language/control_flow_collections/if_inference_test
language/control_flow_collections/map_set_ambiguity_test
Change-Id: Ie8fe93320ec623cc3812d43bd36550a0fe32f613
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338424
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Work on https://github.com/dart-lang/sdk/issues/54002 revealed that the
test least_upper_bound_greatest_closure_1_test.dart contains 4 static
type expectations that are incorrect according to the definition of `UP`
and this CL corrects those expectations.
The updates associated with 54002 will change the behavior of the cfe
and the analyzer such that they have the correct expectations (they
currently succeed with the incorrect static type expectations, that is,
they need to be updated in order to compute `UP` correctly, but that
will occur as part of the update described in 54002, so we will
approve the test failures caused by this CL and refer to 54002).
Change-Id: Iec6ba253eea9f85efc8af67b372bd7f160145a22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337726
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Eventually we may want to revisit whether it is worth running this test
at all on the web backends. The test was designed to ensure the VM
didn't produce memory leaks when capturing state in closures, as such,
it may be better placed on a different suite.
Today, the test passes in most web configurations. The two exceptions
are:
* ddc-linux-chrome is flaky and times out 50% of the time
* ddc-linux-firefox consistently times out.
Locally, on a machine much faster than our bots, the former completes in
5s and the latter in 25s. In the last 60 days, the chrome configuration
has seen runs on the bots ranging from 8 to 60s (hitting the timeout). I
expect marking the test as slow will fix the flakiness on chrome, but
given that it is 5 times slower on FF, I fear it may not be enough to
make the test pass in FF. Given that it doesn't provide much value to
also have the coverage in FF, I'm inclined to skip it there instead.
Change-Id: Ice25eb401b6af3c6ab8ba3f4b43bf3ce9ee38c83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335020
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This test flakes 0.5% of the time due to long compilation times. It
seems to be intended to be a stress test, so increasing the timeout
seems reasonable.
Change-Id: I508b4e42654dbb01fba9d84bea3bf843d7b59c48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333320
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Previously, if field promotion failed both because the language
version was less than 3.2, *and* for some other reason(s), the
analyzer and CFE only reported the other reason(s). The rationale was
that this was better than reporting just that the language version was
less than 3.2, because if a user upgraded their language version to
3.2 in an attempt to get field promotion to work, and *then* found out
that the property in question was unpromotable for some other reason,
that could be quite frustrating.
With this change, if field promotion fails both because the language
version is less than 3.2 and for some other reason, the analyzer and
CFE report *all* the reasons.
Change-Id: Ib5d3a4621273c1e80d66b66b456119f9053e18b1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332485
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Update the type inference algorithm so that `FlowAnalysis.propertyGet`
is appropriately called when analyzing code that refers to the
representation variable of an extension type.
Flow analysis requires an arbitrary `Object` to represent the property
in question; this is later passed to
`OperationsCfe.isPropertyPromotable`. We use the synthetic
"representation field" (which is actually a `Procedure`) for this
purpose
(`ExtensionTypeRepresentationAccessTarget.representationField`).
Representation variables are considered promotable if they are public
(see
https://github.com/dart-lang/language/pull/3411). `OperationsCfe.isPropertyPromotable`
can tell if the representation variable is public by checking the name
of the synthetic representation field.
Fixes#53439.
Bug: https://github.com/dart-lang/sdk/issues/53439
Change-Id: I8f7ff8fcd8e5a43de419b8441951b52a555fda1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332480
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Add the "vm:keep-name" pragma to the class whose name is checked.
Add isObfuscated to guard the check that includes named parameter
names, since currently they are obfuscated, even if the function is
marked with the "vm:keep-name" pragma.
TEST=language/type_object/runtime_type_function on
vm-aot-obfuscate-linux-release-x64
Fixes: https://github.com/dart-lang/sdk/issues/53879
Cq-Include-Trybots: luci.dart.try:vm-aot-obfuscate-linux-release-x64-try
Change-Id: I7698607ed6e1c95860f2e26ede923320a409eba4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332425
Reviewed-by: Daco Harkes <dacoharkes@google.com>
1. Add `Object` and `Map` to the very short list of names that are
unminified in the app.
2. Tweak test to avoid testing minified name.
Change-Id: Ide0cedc2950b5392eb6963403a48c0f89cd1b50a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332368
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
If the user attempts to promote a property, and their language version
does not permit field promotion, the "why not promoted" logic now
checks whether the language version is the sole reason for the failure
in property promotion. In other words, it checks whether the property
would have been promotable *if* field promotion had been enabled. If
it would, then the context message displayed to the user explains that
the property did not promote because field promotion is not supported
by the current language version.
However, if there is some secondary reason why the property failed to
promote (in other words, if the property would not have been
promotable even if field promotion had been enabled), then the context
message now favors the secondary reason.
Rationale: imagine a user is maintaining a package that doesn't yet
support SDK version 3.2, and that package contains some property
that's non-promotable both because the language version is prior to
3.2 *and* for some other reason (e.g., because the property isn't a
private field). It would be quite frustrating if the user saw a
context message suggesting that the property would be promotable in
SDK 3.2, and then went to a lot of effort to bump their minimum SDK
version, only to discover *after* the bump that the property is still
not promotable.
In the process of making this change, I discovered that the CFE
doesn't support field promotion in patch files. This is because patch
files aren't listed in `SourceLoader.sourceLibraryBuilders`, so the
logic in the `FieldPromotability` is never invoked for those
files. Since patch files are an artifact of SDK development, and will
never be used by end users, it doesn't seem worth going to extra
effort to add this support. However, I've taken care to make sure that
the "why not promoted" logic recovers gracefully in patch files (by
simply not generating a context message).
Change-Id: I6c0d1c0f4b8a7690f6f775408cb5e857b2dd7b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330241
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Johnni Winther