This adds support for extension types in exhaustiveness checking by
performing extension type erasure on the type before computing the
corresponding static type/space.
Change-Id: Ie75c903aec52a7c34410695787a9bea6008d637d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340442
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL implements the spec change in https://github.com/dart-lang/language/pull/3435. It changes the implementation of UP in the CFE and in the analyzer such that it matches the updated specification in language PR dart-lang/language#3435.
Change-Id: I2fb56c11e671e6917baffb89f9fb231072d22a0a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333922
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Erik Ernst <eernst@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>
This moves pattern variable assignments of fully matched expressions into the case body. This will help backends (dart2js in particular) to reason about the code flow.
Closes#54115
Change-Id: I598a384a829f16e91ab2d6a309499cf20b9cc121
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339122
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Per https://github.com/dart-lang/language/issues/3442 inrospection will
be allowed to succeed if possible, failing if there are cycles.
Change-Id: I341cc4ae87d1399df82cebb1d5c9df7e5070e777
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339620
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
- Removes @staticInterop JS types declarations in favor of
typedefs (the function types' reified types and the typed data's
reified types have changed to make the type hierarchy work in the
JS backends).
- Adds extension types to dart:js_interop
- Adds a fromInteropObject helper to JSObject to avoid casting to
an extension type
- Deletes now stale tests
- Refactors some dart2wasm @staticInterop declarations since they
can no longer implement JS types
- Updates extension types tests to use the prefix extension_type
instead of inline_class
- Updates comments
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ibe04afac9585ddb99fcf6dbaa7f12050d8b876dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332860
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Sometimes when the parser is performing error recovery it skips tokens
until it finds the next `,` or `;`, to try to get back on track. This
is handled by the `Parser.findNextCommaOrSemicolon` method.
When this method encounters a `BeginToken` (i.e., `(`, `[`, `{`, or
`<`), it needs to skip to the matching end token (using the `endToken`
getter), so that it doesn't try to resume parsing inside some nested
structure.
However, sometimes there is no matching end token (either because the
user has failed to properly matched `()`, `[]`, or `{}`, or because
the `BeginToken` is `<`, which doesn't always have a matching `>`). To
avoid a crash when this happens, `Parser.findNextCommaOrSemicolon`
needs to treat an unmatched `BeginToken` like an ordinary token, and
just advance to the next token.
Fixes https://github.com/dart-lang/sdk/issues/54236.
Bug: https://github.com/dart-lang/sdk/issues/54236
Change-Id: Id208c7a46c9c00b69f7f460a638d59486ebaffea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339980
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This normalizes the handling of Object member access on Never by
adding a NeverAccessTarget which holds the needed member and function
type information.
Closes#54230
Change-Id: I4bfb9d746a4abd7094e87f907db7c9298fcd0361
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340183
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This - combiend with sending the scriptUri and offset - allows us to
expression evaluate stuff on extension types.
Change-Id: I0db6c1f52ad3db4ce1a1a2a721e8f3e70033f9ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339900
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This changes the pattern matching lowering to avoid using late final variables (or lowerings thereof) and instead inline the initializer where used. This avoids generating closures that are hard for backends to reason about and optimize.
Closes#52805Closes#53804
Change-Id: Ia887446dd4d4475d05cf852c812bfe4b851de261
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338860
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This adds the `Native.addressOf` function, which takes a constant tear-
off of a method annotated with `@Native` as a parameter and returns a
pointer to the underlying C function.
The CFE will resolve these calls in two steps: First, the existing
transformer for `@Native` methods adds a pragma describing the fully-
resolved native annotation (with the asset id inferred from the library
if not given explicitly). Then, the FFI use sites transformer rewrites
calls to `Native.addressOf` by searching for this pragma on the passed
function and passing the `Native` constants to `Native._addressOf`. The
latter method is implemented in the VM, which can re-use existing parts
already used for `@Native` calls.
An alternative implementation strategy would have been to forward
`addressOf` calls to `Native.ffi_resolver_function` directly without
any special consideration in the VM. However, the chosen approach makes
it easier to support static linking in the future, as this requires
unresolved symbols in the generated assembly.
Closes https://github.com/dart-lang/sdk/issues/50552
TEST=pkg/vm/testcases/transformations/ffi/ffinative.dart
TEST=tests/ffi/native_assets/asset_*_test.dart
TEST=tests/ffi/vmspecific_static_checks_ffinative_test.dart
TEST=pkg/analyzer/test/src/diagnostics/ffi_native_test.dart
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64c-try,vm-aot-win-release-x64-try,vm-kernel-precomp-linux-release-x64-try
CoreLibraryReviewExempt: VM & dart2wasm only feature
Change-Id: Ic8e3a390146dffd44c95578f975a4472db79a0ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
General approach: Find all scopes for an offset,
then pick "the right one".
This still leaves a few offsets where we can't pick 1 scope in the
(non-outline) dills in the out directory though.
More thorough testing will follow.
TEST=ci
Change-Id: I66448498e07aa03f720733bcaf167bbfa30bca2f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338840
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Named parameters can't start with underscores whether they are optional or required.
Change-Id: Iaaeab80f74a691b4981148f06412a60ca115f73e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337883
Auto-Submit: Parker Lougheed <parlough@gmail.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
dart2wasm lowering of async* methods includes call to Stream.where
which takes a closure. The return type of that closure was incorrectly
set to Object?, while it should be bool.
This incorrect static type becomes a problem with more precise
handling of closures in TFA.
Issue: https://github.com/dart-lang/sdk/issues/39692
Change-Id: I35a8a6b198413d564e091a935a8beaff15d6d541
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339200
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
E.g.
```
final bool foo = (1+1==2) ? true : false;
if (foo) {
if (foo) {
print("always true");
}
if (!foo) {
print("always false");
}
}
```
Inside the first if we know `foo` to be true, so there's no reason to do
more if's on it.
Change-Id: I87d0827c47ce0e7277d951c0ec28f19dff09767a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338780
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Includes a cleanup of the errors reported for duplicate instance field.
Previously, in addition to reporting the duplicate, we would report that
the field cannot be used because it is a duplicate and that the
duplicate field hasn't been initialized.
Closes#53467Closes#53320
Change-Id: Ifd94223500809f3be36a1345d9d0c409778eed8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336885
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Previously, UP was eliminating all free variables in the bound instead
of just the variable with that bound.
Closes https://github.com/dart-lang/sdk/issues/54062
Change-Id: Ic0ce9e6b53ecee7d9d1dcb4e76b9214310f63631
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336884
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This language feature allows the user to declare a static type using
`extension type` syntax, for example:
extension type IdNumber(int i) {
operator <(IdNumber other) => i < other.i;
bool isValid(Some parameters) => ...;
}
This behaves similarly to a "wrapper" class:
class IdNumber {
final int i;
IdNumber(this.i);
operator <(IdNumber other) => i < other.i;
bool isValid(Some parameters) => ...;
}
However, at runtime, no wrapper objects are created; instead, an
instance of the extension type is represented directly by its
"representation type" (`int` in the above example), and methods like
`isValid` are resolved statically. This gives developers an
abstraction mechanism with the advantage of zero runtime performance
cost, since no extra heap space is required, and no extra instructions
are needed to convert between an extension type and its underlying
representation.
The disadvantage of using extension types as an abstraction mechanism
is that since no wrapper objects are created at runtime, the
abstraction can be bypassed using `dynamic`, runtime casts, or by
"laundering" the object through contravariant generic methods like
`List.add` (which are runtime checked in Dart). For example:
main() {
var id = IdNumber(1);
var list1 = <int>[];
List<Object> list2 = list1;
list2.add(id); // OK at compile time because `IdNumber` is a
// subtype of `Object`. OK at runtime because
// at runtime, `IdNumber` and `int` are
// indistinguishable.
int i = list1[0];
print(i);
}
Extension types are expected to be particularly useful for
low-overhead decoding of external data formats (such as JSON), and for
inter-operation with other languages (such as Javascript).
For additional information see the feature specification:
https://github.com/dart-lang/language/blob/main/accepted/future-releases/extension-types/feature-specification.md
Change-Id: I900a3a25dcfc38bfa9c9f9b5b9fa20f362883653
Tested: Standard trybots
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335062
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is a reland of commit 262311772b
When running with sound null safety, reducing a logical expression to
the right hand side if the left hand side is constant and does not short
circuit is valid, as the right hand side is guaranteed not to evaluate
to null.
In other modes, however, the right hand side may evaluate to null.
Thus, in thos modes, we return the original node if the RHS is not a
constant boolean value, so that the operator can perform whatever null
checking is required.
Fixes: https://github.com/dart-lang/sdk/issues/54029
Original change's description:
> Reland "[pkg/vm] Handle switch statements in unreachable code eliminator."
>
> This is a reland of commit 92bf76d9e8
>
> In the original CL, the changes to the UCE assumed all
> SwitchStatements were exhaustive. Now if a SwitchStatement isn't
> explicitly or implicitly (via a default case) exhaustive and no case
> matches the tested constant, the SwitchStatement is properly removed.
>
> In addition, if a guaranteed to match case is found, more than one
> cases remain (thus the SwitchStatement is not removed or replaced with
> the single case's body), and the default case is removed, then the
> resulting SwitchStatement is marked as explicitly exhaustive, as this
> serves as a signal to backends that they do not need to handle the
> possibility of no case matching in the absence of a default case.
>
> Original change's description:
> > [pkg/vm] Handle switch statements in unreachable code eliminator.
> >
> > Namely, if the tested expression for a switch statement is constant,
> > then we can remove any constant cases where the constants differ,
> > and if all but a single case is removed, we can replace the switch
> > with the case body.
> >
> > If constant functions are not enabled, then getters annotated with
> > @pragma("vm:platform-const") are still evaluated with the constant
> > function evaluation machinery, but only those and no others (including
> > any functions called within an annotated getter). This way, functions
> > can be annotated with @pragma("vm:platform-const") without having to
> > rewrite them to be a single returned expression.
> >
> > TEST=pkg/vm/test/transformations/unreachable_code_elimination
> > pkg/vm/test/transformations/vm_constant_evaluator
> >
> > Issue: https://github.com/dart-lang/sdk/issues/50473
> > Issue: https://github.com/dart-lang/sdk/issues/31969
> > Change-Id: Ie290d2f1f469326238d66c3d9631f8e696685ff0
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332760
> > Commit-Queue: Tess Strickland <sstrickl@google.com>
> > Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> > Reviewed-by: Alexander Markov <alexmarkov@google.com>
>
> TEST=pkg/vm/test/transformations/unreachable_code_elimination
> pkg/vm/test/transformations/vm_constant_evaluator
>
> Issue: https://github.com/dart-lang/sdk/issues/50473
> Issue: https://github.com/dart-lang/sdk/issues/31969
> Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try
> Change-Id: I557ca933808012e670e306f2d880221a0d7dd670
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334224
> Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Tess Strickland <sstrickl@google.com>
TEST=pkg/vm/test/transformations/unreachable_code_elimination
pkg/vm/test/transformations/vm_constant_evaluator
Change-Id: Ia51b7c5f3b51f57a6a306551fe74b47e0cba3c23
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335828
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
vm.
This identifies all calls to static methods annotated with
`@ResourceIdentifier`, collects the constant arguments passed to the
method, and writes the results into a file.
The purpose of this feature is to be able to pass the recorded
information to packages in a post-compilation step, allowing them to
remove or modify assets based on the actual usage in the code prior to
bundling in the final application.
Tested: pkg/vm/test/transformations/resource_identifier_test.dart
Change-Id: I58cb313b66ee23c1d154dcc242547723a1ced359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329961
Commit-Queue: Moritz Sümmermann <mosum@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Currently, if a not-enabled-by-default experimental flag is on we allow
formatting to fail.
This means that when the flag is flipped there's a risk of failures as
formatter crashes are now not allowed anymore.
The failures for flipping the extension types / inline-class feature
has caused crashes and was fixed before (twice!) in
https://dart-review.googlesource.com/c/sdk/+/336001https://dart-review.googlesource.com/c/sdk/+/335448
But naturally a new test was added after
(https://dart-review.googlesource.com/c/sdk/+/336022) and we had a new
failure on the flag-flip CL.
This CL instead pretends like the inline-class flag is already flipped,
in that the formatter is not allowed to crash because of it.
That should make any new tests added before the flag is flipped that
would otherwise cause a failure upon flag flip, fail, forcing the
update of the status file.
The status file is furtermore updated.
Change-Id: Ifbc3d271a614e5dd747b35b252034087ad155a92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337321
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This is a reland of commit 6f29e7fce4
Original change's description:
> Expire 3.0.0 experiment flags.
>
> TEST=Existing tests covers.
> Change-Id: I161eefdc28c74f63ba1ee926800a01eea03d9930
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331960
> Commit-Queue: Lasse Nielsen <lrn@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
TEST=Existing tests covers.
Change-Id: I384e77744c74774a250be413358a7fa176117167
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332684
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This adds support using experimental features in id testing in DDC and
uses it to add tests for scopes in extensions, extension types and
mixins.
The tests show that the DartScopeBuilder and DartScopeBuilder2 differ
on the scope on instance members in extensions and extension types for
the synthetic #this variable.
Change-Id: Iec0f3b938da567578b1245ada885370fb2a8b33f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335824
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds a CFE test for DartScope that shares the data with the
corresponding DDC test. The CFE test uses the DartScopeBuilder2
which is currently in development to replace the DartScopeBuilder.
Change-Id: I0d6c76957e7a5d28babab14110d430935e686b22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335821
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Deprecate accessing LineInfo, Source, or SourceRange via the
old library (pkg/analyzer/lib/src/generated/source.dart).
Migrate all SDK code to the new library.
Fixes https://github.com/dart-lang/sdk/issues/46420
Change-Id: Ic7c98a5820415c92a457f9fa2756351b05520cd1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335382
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Before (or, currently) we force the `ExperimentalFlag.inlineClass`
experimental flag to be on and it's experimental and we thus basically
always allow the formatter to fail.
With the flag being flipped this allowing it to fail goes away.
This CL fixes some of it by passing flags to the formatter as well, and
"fixes" the rest by putting in status entries.
Change-Id: I059efa0473dc0746bd72b45071c69915d4472b07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336001
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit 262311772b.
Reason for revert: Breaks legacy mode.
Bug: https://github.com/dart-lang/sdk/issues/54029
Original change's description:
> Reland "[pkg/vm] Handle switch statements in unreachable code eliminator."
>
> This is a reland of commit 92bf76d9e8
>
> In the original CL, the changes to the UCE assumed all
> SwitchStatements were exhaustive. Now if a SwitchStatement isn't
> explicitly or implicitly (via a default case) exhaustive and no case
> matches the tested constant, the SwitchStatement is properly removed.
>
> In addition, if a guaranteed to match case is found, more than one
> cases remain (thus the SwitchStatement is not removed or replaced with
> the single case's body), and the default case is removed, then the
> resulting SwitchStatement is marked as explicitly exhaustive, as this
> serves as a signal to backends that they do not need to handle the
> possibility of no case matching in the absence of a default case.
>
> Original change's description:
> > [pkg/vm] Handle switch statements in unreachable code eliminator.
> >
> > Namely, if the tested expression for a switch statement is constant,
> > then we can remove any constant cases where the constants differ,
> > and if all but a single case is removed, we can replace the switch
> > with the case body.
> >
> > If constant functions are not enabled, then getters annotated with
> > @pragma("vm:platform-const") are still evaluated with the constant
> > function evaluation machinery, but only those and no others (including
> > any functions called within an annotated getter). This way, functions
> > can be annotated with @pragma("vm:platform-const") without having to
> > rewrite them to be a single returned expression.
> >
> > TEST=pkg/vm/test/transformations/unreachable_code_elimination
> > pkg/vm/test/transformations/vm_constant_evaluator
> >
> > Issue: https://github.com/dart-lang/sdk/issues/50473
> > Issue: https://github.com/dart-lang/sdk/issues/31969
> > Change-Id: Ie290d2f1f469326238d66c3d9631f8e696685ff0
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332760
> > Commit-Queue: Tess Strickland <sstrickl@google.com>
> > Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> > Reviewed-by: Alexander Markov <alexmarkov@google.com>
>
> TEST=pkg/vm/test/transformations/unreachable_code_elimination
> pkg/vm/test/transformations/vm_constant_evaluator
>
> Issue: https://github.com/dart-lang/sdk/issues/50473
> Issue: https://github.com/dart-lang/sdk/issues/31969
> Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try
> Change-Id: I557ca933808012e670e306f2d880221a0d7dd670
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334224
> Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Commit-Queue: Tess Strickland <sstrickl@google.com>
Issue: https://github.com/dart-lang/sdk/issues/50473
Issue: https://github.com/dart-lang/sdk/issues/31969
Change-Id: I56373c7a6feac76e23c1800ae83eb013c5856cba
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335820
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Currently we don't get any failures from trying to format erroneous code
because we ignore formatting errors if there is an experimental feature
enabled, and the "inline class" experimental feature is always
forcefully enabled in testing.
With that experiment getting enabled
(https://dart-review.googlesource.com/c/sdk/+/335062) tests will start
failing because nothing stops us from formatting the erroneous code (and
nothing asks us to allow failures when we try).
This CL instead gives the test access to the needed information (i.e. if
there were parse errors or not), and won't try for format the code if
there is.
Change-Id: I2664cc544a9def9fad3058f6c80c130b8b6b6b4c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335448
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds id-testing support to dartdevc and uses it to add a
scope_test for the DartScope created for expression compilation.
Change-Id: I861092e17807190880bd20e4e39e012fbf0cbe53
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334220
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
stringref target won't be used any time soon (probably ever). To help
with build times and avoid keeping it updated remove it for now.
Change-Id: I0df33b7ab2e19bae5090e8ea32ea6a3dc3751652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334881
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
After switching over to NNBD, variance inference started failing because
we no longer used variance to subtype match.
This CL adds a null-aware subtype matching fn for the current algorithm.
Bug: https://github.com/dart-lang/sdk/issues/43419
Change-Id: Ifecc58a7537c0656f089cc3f8aca7fd4289be6d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334721
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This is a reland of commit 92bf76d9e8
In the original CL, the changes to the UCE assumed all
SwitchStatements were exhaustive. Now if a SwitchStatement isn't
explicitly or implicitly (via a default case) exhaustive and no case
matches the tested constant, the SwitchStatement is properly removed.
In addition, if a guaranteed to match case is found, more than one
cases remain (thus the SwitchStatement is not removed or replaced with
the single case's body), and the default case is removed, then the
resulting SwitchStatement is marked as explicitly exhaustive, as this
serves as a signal to backends that they do not need to handle the
possibility of no case matching in the absence of a default case.
Original change's description:
> [pkg/vm] Handle switch statements in unreachable code eliminator.
>
> Namely, if the tested expression for a switch statement is constant,
> then we can remove any constant cases where the constants differ,
> and if all but a single case is removed, we can replace the switch
> with the case body.
>
> If constant functions are not enabled, then getters annotated with
> @pragma("vm:platform-const") are still evaluated with the constant
> function evaluation machinery, but only those and no others (including
> any functions called within an annotated getter). This way, functions
> can be annotated with @pragma("vm:platform-const") without having to
> rewrite them to be a single returned expression.
>
> TEST=pkg/vm/test/transformations/unreachable_code_elimination
> pkg/vm/test/transformations/vm_constant_evaluator
>
> Issue: https://github.com/dart-lang/sdk/issues/50473
> Issue: https://github.com/dart-lang/sdk/issues/31969
> Change-Id: Ie290d2f1f469326238d66c3d9631f8e696685ff0
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332760
> Commit-Queue: Tess Strickland <sstrickl@google.com>
> Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TEST=pkg/vm/test/transformations/unreachable_code_elimination
pkg/vm/test/transformations/vm_constant_evaluator
Issue: https://github.com/dart-lang/sdk/issues/50473
Issue: https://github.com/dart-lang/sdk/issues/31969
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-mac-release-arm64-try
Change-Id: I557ca933808012e670e306f2d880221a0d7dd670
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334224
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
With a aot snapshot generated before this CL like this:
```
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot \
pkg/front_end/tool/_fasta/compile.dart
```
and then moved to `pkg/front_end/tool/_fasta/compile.org`,
then benchmarks run like
```
rm /path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart.dill ; \
rm pkg/front_end/tool/_fasta/compile.aot ; \
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot \
pkg/front_end/tool/_fasta/compile.dart && \
out/ReleaseX64/dart pkg/front_end/tool/benchmarker.dart \
--iterations=50 \
--snapshot=pkg/front_end/tool/_fasta/compile.org \
--snapshot=pkg/front_end/tool/_fasta/compile.aot \
--arguments=/path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart \
--filesize=/path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart.dill
```
(The other checkout is at 8b01baab71)
I get this:
```
Generated: [...]/pkg/front_end/tool/_fasta/compile.aot
Will now run 50 iterations with 2 snapshots.
......................................................................................................
Comparing snapshot 1 with snapshot 2
msec task-clock:u: -1.9077% +/- 0.5801% (-74.85 +/- 22.76)
page-faults:u: -2.6477% +/- 0.0391% (-2579.42 +/- 38.12)
cycles:u: -2.0459% +/- 0.6018% (-324680453.54 +/- 95498561.25)
instructions:u: -1.4202% +/- 0.0003% (-286466291.62 +/- 55229.41)
branch-misses:u: -3.0746% +/- 2.3469% (-1904933.80 +/- 1454106.83)
seconds time elapsed: -1.9144% +/- 0.5791% (-0.08 +/- 0.02)
seconds user: -1.8955% +/- 0.6479% (-0.07 +/- 0.02)
Scavenge( new space) goes from 56 to 55
Notice combined GC time goes from 948 ms to 925 ms (notice only 1 run each).
```
So `instructions:u` being the most stable says a reduction of 1.42%,
time is in that range too (-1.9077% +/- 0.5801%), although in both
cases some of it is likely the number of new space GCs going from
56 to 55.
Change-Id: I0422af966f1902c50caa366cc2ad2cd7553c06d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333501
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This reverts commit 92bf76d9e8.
Reason for revert: broken tests on AOT trybots
Original change's description:
> [pkg/vm] Handle switch statements in unreachable code eliminator.
>
> Namely, if the tested expression for a switch statement is constant,
> then we can remove any constant cases where the constants differ,
> and if all but a single case is removed, we can replace the switch
> with the case body.
>
> If constant functions are not enabled, then getters annotated with
> @pragma("vm:platform-const") are still evaluated with the constant
> function evaluation machinery, but only those and no others (including
> any functions called within an annotated getter). This way, functions
> can be annotated with @pragma("vm:platform-const") without having to
> rewrite them to be a single returned expression.
>
> TEST=pkg/vm/test/transformations/unreachable_code_elimination
> pkg/vm/test/transformations/vm_constant_evaluator
>
> Issue: https://github.com/dart-lang/sdk/issues/50473
> Issue: https://github.com/dart-lang/sdk/issues/31969
> Change-Id: Ie290d2f1f469326238d66c3d9631f8e696685ff0
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332760
> Commit-Queue: Tess Strickland <sstrickl@google.com>
> Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
Issue: https://github.com/dart-lang/sdk/issues/50473
Issue: https://github.com/dart-lang/sdk/issues/31969
Change-Id: I4340874793da19ce892a19bcf0542c24e0ee65d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334600
Commit-Queue: Siva Annamalai <asiva@google.com>
Auto-Submit: Tess Strickland <sstrickl@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Namely, if the tested expression for a switch statement is constant,
then we can remove any constant cases where the constants differ,
and if all but a single case is removed, we can replace the switch
with the case body.
If constant functions are not enabled, then getters annotated with
@pragma("vm:platform-const") are still evaluated with the constant
function evaluation machinery, but only those and no others (including
any functions called within an annotated getter). This way, functions
can be annotated with @pragma("vm:platform-const") without having to
rewrite them to be a single returned expression.
TEST=pkg/vm/test/transformations/unreachable_code_elimination
pkg/vm/test/transformations/vm_constant_evaluator
Issue: https://github.com/dart-lang/sdk/issues/50473
Issue: https://github.com/dart-lang/sdk/issues/31969
Change-Id: Ie290d2f1f469326238d66c3d9631f8e696685ff0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332760
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Instead of hard-coding a single Token name, find all subtypes of Token
and use that when searching for leaks.
We allow one instance of SyntheticToken because that's used in
`dummyToken`.
We fix the printing of retaining paths for fields.
Change-Id: Ic4d629ca08cae2307d4a550fb8b274f978c49b36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333823
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This prepares for adding id-test support in ddc.
Change-Id: I96d35b06e5e32f464cd487dc852ec114064afc9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334161
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This updates the handling of member access on extension type receivers
to use the added `nonTypeVariableBound` and the `hasNonObjectMemberAccess`
properties.
The `nonTypeVariableBound` replaces the `resolveTypeParameterType`,
updated to taking the nullablity into account when going through
type variable bounds.
Change-Id: Ia2eb115c208350cdf011948177b15ebbc984fcac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333540
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Because of the special language rules (int +/-/* int = int),
static type for binary int operations can be more precise than
inferred result type (in case of dart2wasm, int binary operations
are declared as external methods returning num).
So, for dart2wasm it is useful to narrow result of a call by its
static type, if it is different from return type of the call target.
Also, this change fixes an incorrect static type which is
created during dart2wasm async* transformation.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/int_operations_dart2wasm.dart
Fixes https://github.com/dart-lang/sdk/issues/53921
Change-Id: Id6a5a2cffac47918c4e92f996267bf7fae713416
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333580
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
The Dart2JS team has agreed that this mode of compilation is no longer worth investing in at this time and its existence adds some overhead to other feature work so it is worth fully removing. In the future we may revisit this mode of compilation. Below is some more context for any future exploration in this space.
What didn't work with modular analysis:
- current modular analysis was computing impacts, which were dense (50% of the size of kernel)
- using it moved work to a modular phase, and cut Phase1 in half however end-to-end time was not better
- data overhead was very high
- it made it much harder to maintain invariants throughout the pipeline: the data is tightly coupled with the kernel AST, making it hard to make late modifications to the AST.
How to potentially make it better:
- make the data much more sparse
- make the data more independent from the kernel AST so that transformations are not breaking
- reduce the critical path in a more substantial way.
Note: We retain and ignore the commandline flags used for modular analysis in order to avoid breaking build pipelines that were passing them. We may remove these at a later date.
Change-Id: If574ce2358280ab5fedd89c62665328601e72e22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333360
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Now that some basic support has landed internally, this will help to keep language versions more consistent for targets using macros, which will make SDK rolls easier.
Change-Id: Ifb9bb3def161edb3974cfc68271daad8a12707b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333200
Auto-Submit: Jake Macdonald <jakemac@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
The changes calls to getInterfaceTypeAsInstanceOfClass (et al.) to
getTypeAsInstanceOf to ensure that we take extension types into account.
Change-Id: I7d732cdae8494002b44561cb02c49d58dd0ba67b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332920
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds the functionality to ClassMember that enables us to
fully compute the ExtensionTypeAccessTarget.
Change-Id: I62dd5e24f664c2edd70c2fe794f66595cc017173
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332427
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
Expressions missing offsets were:
- LogicalExpression
- ConditionalExpression
- Not
- BlockExpression
- Instantiation
- TypedefTearOff*
* I'm not sure how TypedefTearOff is actually being used, I don't see reference to it in the VM runtime. Unless the CFE lowers it before the VM gets it.
I also added a test on `binary.md` that ensures all expressions include a file offset in their serialized format. This can be expanded to statements if offsets are added to the remaining statement nodes without offsets.
TEST=Added binary_md_git_test.dart to ensure all expressions contain offset data going forward.
Change-Id: Ieaf80545f388b209f76be44db86ef07e80c8ad66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331540
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This uses the allowed_experiments.json to opt package:web and
dart:js_interop in to the inline-class experiment (the extension
types feature) for early access and development.
Change-Id: Ieb828b654f2320b147a3c48bbb4a142da1c18380
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332421
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@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>
TEST=Existing tests covers.
Change-Id: I161eefdc28c74f63ba1ee926800a01eea03d9930
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This add support for inherited combined member signatures, both from
source and from dill.
Change-Id: I163f2b30c3242ba98692d7e9b52ef93fd0d6a903
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332201
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This add a common sealed superclass TypeDeclarationType for
ExtensionType and InterfaceType and uses it to add a common
asInstanceOf method to ClassHierarchy.
Change-Id: I7294e41069b063305c3bd4e384ff90614a3936a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331981
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
This flag used to be used for field promotion (to ensure that lowered
late fields are promotable, provided that they are private and final
and don't have a name that conflicts with something else
non-promotable). However, as of
https://dart-review.googlesource.com/c/sdk/+/330168, the logic for
determining when a Procedure is promotable now operates solely by
checking for all the conditions that prevent promotability. Lowered
late fields are now promotable because there is no reason for them not
to be.
Change-Id: I15982acef6fe8c46334fb859306bca1417a2ca64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331207
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@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>
This create a stub for combined member signatures from multiple
inherited non-extension type members and adds these to the
extension type declaration.
A sealed [TypeDeclaration] superclass is added to [Class] and
[ExtensionTypeDeclaration] to support accessing the enclosing type
declaration from a [Member].
TEST=existing
Change-Id: Ic01535d27a14187d37b00868e7e90fe73558b051
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331181
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
When a field is declared in a mixin, the front end creates a synthetic
getter in the mixin application class that gets the value of the mixed
in field. So if a piece of code accesses the mixed in field through
the mixin application class rather than through the mixin directly,
the resolved member is the synthetic getter rather than a field.
In order to ensure that the field remains promotable even if it is
accessed through the mixin application, the logic in
`OperationsCfe.isPropertyPromotable` needs to be changed so that it
doesn't treat these synthetic getters as non-promotable. The old logic
was essentially this:
1. If the property is not private, it's not promotable.
2. Otherwise, if the property is listed in
`FieldNonPromotabilityInfo.fieldNameInfo`, it's not
promotable. (This happens either if the property is not promotable
for an intrinsic reason, such as being a non-final field or a
concrete getter, or if it has the same name as a non-promotable
property elsewhere in the library).
3. Otherwise, if the property is a getter that was lowered from an
abstract field, it's promotable.
4. Otherwise, if the property is a getter that was lowered from a late
field, it's promotable.
5. Otherwise, the property isn't promotable. (This was intended to
cover the case where the property is an abstract getter
declaration).
(Although conditions 3 and 4 were tested first, since they are more
efficient to test).
It turns out that once conditions 1-2 have been ruled out, the
property must have been declared as a method (which is being torn
off), a private abstract getter, or a (possibly abstract) non-external
private final field. Of these three possibilities, only the last is
promotable. So this can be simplified to:
(conditions 1-2 as above)
3. Otherwise, if the property is a method tear-off, it's not promotable.
4. Otherwise, if the property is an abstract getter, it's not promotable.
5. Otherwise, the property is promotable.
This makes the logic easier to follow, since conditions 1-4 are now
all reasons for non-promotability (rather than a mix of promotability
and non-promotability reasons). It also conveniently addresses the
problem with fields accessed through mixin applications, since they
aren't excluded by any of conditions 1-4.
(We still test conditions 3 and 4 first, since they are more efficient
to test.)
Fixes#53742.
Fixes#53617.
Fixes#53436.
Change-Id: I64df269c2a4a0714f9be239d832b61f4fb6a1a43
Bug: https://github.com/dart-lang/sdk/issues/53742
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330168
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds the representation field of an extension type declaration
as an abstract getter in the ExtensionTypeDeclaraiton marking it as
a ProcedureStubKind.RepresentationField
These are never used as interface targets and are therefore skipped
in the type flow analysis.
TEST=existing
Change-Id: Ie645e63e0995a31895e985a2025dccb1476d16bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330782
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This CL reorganizes our collection of kernel transformations into
"modular" and "global" ones. Modular (phase 0a) transformations are
those that can be run on each library before we have "linked" the full
program AST. Global (phase 0b) transformations are those that are run
over the full program AST.
Although we colloquially refer to multiple transformations of each kind,
there is actually a single modular (resp. global) `Transformer`, which
merges all the required transformations into a single AST pass.
Change-Id: I8f53cba6fc9a8aab106188ec3597ab194dd0cde0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330170
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Bug:https://github.com/dart-lang/sdk/issues/53161
Change-Id: I3f13af3cb852b3656341922b9656ec91fc413eed
Tested: documentation + unit test only
CoreLibraryReviewExempt: Only adds documentation and adds a unit test to verify existing behavior
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323426
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The front end handles mixin applications by synthesizing new fields
and procedures in the mixin application class to reflect the fields
and procedures from the mixin.
In order to ensure that the appropriate "why not promoted" context
messages are created for these synthesized fields and procedures,
entries need to be created for them in the
`FieldNonPromotabilityInfo.individualPropertyReasons` map.
Note that the source locations for these synthesized fields correspond
to the declaration of the mixin application rather than the original
field or procedure; to find the original field or procedure we use
`Procedure.stubTarget`.
Change-Id: Ib20d2514cb5aad8f95b93d26ad0e3917f1613db3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330246
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds a list of `Procedure`s to `ExtensionTypeDeclaration`. This is
meant to model representation fields and combined member signatures
computed from inherited non-extension type members.
These are not meant to be handled by the backends. The combined
member signature can be the interface target of an `InstanceInvocation`
expression but will always have a `.memberSignatureOrigin` value from
one of the original class members.
TEST=existing
Change-Id: I87768ed75a3c7126b0a30f8ccf06e46678c56db6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330301
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Unreleased experiments have no language version even though we pretend
they have the current language version. However, it's problematic to
mention the current language version in the error messages as the errors
go into the expectation files. It's a problem that we need to update an
unknowable amount of files whenever we bump the version, so it's much
better to omit the current language version from these error messages.
This change is part of the effort to make it possible to easily bump
tools/VERSION without unexpected issues whenever tests have to have
their pinned language versions updated as well.
Bug: b/30474526
Change-Id: Ia58b6ae002000511cea98ed83d256505deb986dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330108
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL passes the offset and uri of the file (here called a script uri
as opposed to a library uri, the two will be different if we're in a
part) when doing expression compilation.
This CL only passes the data, but doesn't actually use it.
Future CL(s) will use this data to calculate the static type of
available variables which is needed for an upcomming feature.
TEST=Existing tests.
CoreLibraryReviewExempt: Not changing SDK APIs.
Change-Id: I67ead461ab4bb9341424e693946f3e4afe35ce92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329322
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously the nominal variable builders were created in all cases and
then converted to structural if that was required. It induced some
unnecessary type substitutions and complicated the logic behind the
builders. This CL introduces NominalVariableBuilder and
StructuralVariableBuilder as two possible subclasses of
TypeVariableBuilderBase, and the appropriate builders are created from
start.
This is a follow-up to
https://dart-review.googlesource.com/c/sdk/+/312264
Change-Id: I4e40de158201462dcef96b75445b8f179e1f75b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330081
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The nullability of ExtensionType is affected by the representation type.
Change-Id: I2eb0aa7ee26caf97c2bc9c2bdec58369f5b598f8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329920
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This renames ExtensionType.typeErasure and adds it to DartType. This also fixes the extension type erasure for when extension types are used in the arguments of an extension type.
DartType.extensionTypeErasure can be used by backends to easily
access the type without extension types for any type.
TEST=pkg/kernel/test/extension_type_erasure_test.dart
Change-Id: Ia49d273ed85111e3ae822720860a3e0be5ea0252
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329960
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This uses `token_leak_test.dart` to check that we can compile dart2js
without leaking tokens.
Change-Id: I78a419d722a4b017f1bc1e77933f8f54b4cff175
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330061
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This builds a model of the extension type members and checks for
member conflicts.
Change-Id: Ia7dd4250184bed6f6da5e2dd05652fdf1d65c7dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329903
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This avoids leaking Token through EnumConstantInfo.argumentsBeginToken
and allows us to verify that no leaks occur when compiling the sdk.
Change-Id: I0168471fbc6609147c671204d119d161833e7c5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329904
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This changes ConstructorReferenceBuilder.name to use TypeName, thereby
avoiding the leak of Token through Identifier.
Change-Id: I7f84830dda97ebaa51a5a6c44cfda232e0c03174
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329901
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
These are handled through the body builder, and the MetadataBuilder
where left unhandled, leading to leaking of their tokens.
Change-Id: I16cd47bf4c7027f7a306782510e12b0100e1087a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329900
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Please prefer not to revert this change. Any tests that fail are release
blockers and need to be approved and urgently fixed forward. Dart 3.2
has already been cut and the version number must be updated. It is
acceptable for rolls to be blocked until the release blockers have been
resolved as P0 issues.
Remove needless version number comment from experimental_features to
remove duplicated information and simplify version updates.
Update dartdoc to a version that supports 3.3.
Change-Id: I1a19aa86e185c99e61374665f18cf24c498935a5
Tested: CQ
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329588
Commit-Queue: Slava Egorov <vegorov@google.com>
Auto-Submit: Jonas Termansen <sortie@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reverts commit 81aaf6c6c4.
Reason for revert: regression in G3: b/303734572
Original change's description:
> Bump version to 3.3.
>
> Remove needless version number comment from experimental_features to
> remove duplicated information and simplify version updates.
>
> Tested: CQ
> Change-Id: I864bfc44070136406e95fdaf4d83f491b2c95943
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329460
> Reviewed-by: Alexander Thomas <athom@google.com>
Change-Id: Ie7dca3106345ee7949ccd13ab4765998926c0abc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329603
Commit-Queue: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
